[SR-Users] acc Locks
Alex Balashov
abalashov at evaristesys.com
Tue May 31 16:20:51 CEST 2011
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/
More information about the sr-users
mailing list