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
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.
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 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.
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.
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@evaristesys.comwrote:
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
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.
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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 -
Borin