31 May
2011
31 May
'11
3:52 p.m.
Hi all,
Recently I met the following problem with kamailio acc table. We are using
kamailio for calls dispatching to a couple of rtp gateways and for call
statistics acc is used (with mysql). I tried to delete some old entries from
acc table and for this time mysql "show processes" showed a lot of entries
like " kamailio | Query | 0 | System lock | insert
into acc
(method,from_tag,to_tag,callid,sip_code,sip_reason,start_time,src_addr,dst_addr,src_
|". I think that meant that kamailio could not write to the acc table for
the time the data were being deleted.
And it also did not forward INVITE requests further.
Does that mean that if kamailio does not manage to write acc record for any
reason it does not forward that INVITE/200ok?
Best Regards,
Kate
31 May
31 May
3:53 p.m.
On 05/31/2011 09:52 AM, Borin wrote:
Does that mean that if kamailio does not manage to
write acc record for
any reason it does not forward that INVITE/200ok?
It should forward the requests. But SIP worker threads doing the
forwarding will block on database requests that block due to locks, so
there might be delay.
--
Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
3:54 p.m.
On 05/31/2011 09:53 AM, Alex Balashov wrote:
On 05/31/2011 09:52 AM, Borin wrote:
Also, there is a relatively small number of SIP worker threads. If all
of them block on database operations, further requests may not be
processed in time.
--
Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
Does that mean that if kamailio does not manage
to write acc record for
any reason it does not forward that INVITE/200ok?
It should forward the requests. But SIP worker threads doing the
forwarding will block on database requests that block due to locks, so
there might be delay.
4:15 p.m.
Thanks Alex,
that is a big Problem for us. We have usually about 300 calls running
through kamailio at the same time..and kamailio does not process all of them
while DELETE procedure is running. Probably could you recommend how to deal
with this? we still need to remove some old data from the table time to time
and need services not to be interrupted. Later I will put an index on the
time column in acc, that should help to reduce the time for executing a
query. But probably is there another solution?
On Tue, May 31, 2011 at 3:54 PM, Alex Balashov <abalashov(a)evaristesys.com>wrote;wrote:
On 05/31/2011 09:53 AM, Alex Balashov wrote:
On 05/31/2011 09:52 AM, Borin wrote:
Does that mean that if kamailio does not manage to write acc record for
Also, there is a relatively small number of SIP worker threads. If all of
them block on database operations, further requests may not be processed in
time.
--
Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
any reason it does not forward that
INVITE/200ok?
It should forward the requests. But SIP worker threads doing the
forwarding will block on database requests that block due to locks, so
there might be delay.
4:20 p.m.
On 05/31/2011 10:15 AM, Borin wrote:
Thanks Alex,
that is a big Problem for us. We have usually about 300 calls running
through kamailio at the same time..and kamailio does not process all of
them while DELETE procedure is running. Probably could you recommend
how to deal with this? we still need to remove some old data from the
table time to time and need services not to be interrupted. Later I will
put an index on the time column in acc, that should help to reduce the
time for executing a query. But probably is there another solution?
Under normal circumstances, these queries should not take a non-trivial
amount of time to run or present blocking issues. Either there are I/O
issues on the server, the overall database load is too high for other
reasons, or there are serious schema/indexing issues (most probably)
that need to be addressed.
I would profile your queries and see what is going on.
More academically:
It is possible to make CDR logging asynchronous, but not using acc.
Our platform has a custom CDR logging to a custom database schema that
uses rtimer and mqueue. The rtimer module is like a cron daemon for
Kamailio; it provides the ability to schedule a recurring task at
periodic intervals. The mqueue module provides a thread-safe queue that
can be accessed by, among other things, a periodically scheduled rtimer
job. So, we have worker threads enqueue CDR data into mqueue and it is
consumed by a periodic rtimer task every few seconds and sweeped into
the database. As a result, it does not block any SIP worker threads on
CDR-related database calls.
Of course, this doesn't make sense for database calls whose result is
needed for further call processing.
Cheers,
-- Alex
--
Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
4951
days inactive
4951
days old
4 comments
2 participants
participants (2)
-
Alex Balashov -
Borin