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