[SR-Users] rtimer execution period - round two

Hi Daniel, I wanted to go back to this thread for a minute: http://lists.sip-router.org/pipermail/sr-users/2012-June/073663.html Sorry that I didn't reply to the thread; I no longer have the last message. In your reply, you said: However, I am seeing some behaviour that is rather different. Roughly, I have a single rtimer task that runs every 3 seconds and consumes an mqueue full of accounting events. The rtimer request route looks like something this: route[ACCT_WRITER] { while(mq_fetch("acct_write")) { # Some stuff to write $mqv(...) values to PostgreSQL. ... sql_query("ca", "SELECT * FROM acct_event_proc(...)"); ... mq_pv_free("account_write"); } } And the rtimer task is parameterised thusly: modparam("rtimer", "timer", "name=acct_write;interval=3;mode=1") modparam("rtimer", "exec", "timer=acct_write;route=ACCT_WRITER") And the mqueue: modparam("mqueue", "mqueue", "name=acct_write") I have a stored procedure - let's call it acct_event_proc() - that is invoked from within the rtimer task. When I looked at the live query activity from Kamailio to Postgres by doing a packet capture on loopback, like this: tcpdump -i any -A -s 0 -tttt -n 'tcp port 5432' | grep acct_event_proc What I saw was some events being written for about ~3 seconds and then the process would stop. Then, after about half a second, it would burst again for 3 seconds, then stop again. And so on and so forth. When I lowered the interval to 1 second, it got faster and more responsive, and would push more events through in one interval. But still, it appeared to be a limited "burst" of SELECT calls punctuated by 1 second of silence. When I checked out branch 3.3 and lowered the interval to 50000u, it got even faster, almost real-time enough to keep up. Still, I did not really know what was happening, so I added an MI command to HEAD to check mqueue size live: http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=commit;h=41f771… (I think it would be quite useful anyhow, as there is no runtime mqueue info available right now.) Using it, I confirmed my impression: the bigger the rtimer interval, the larger the queue grows, and the slower the events seem to be written overall. The shorter the rtimer interval, the faster they are dequeued, and the smaller the mqueue is overall, in the course of normal call processing. Thus, my impression is that the execution time of the rtimer task is bounded by the interval, and that the core kills the forked rtimer task currently running prior to starting another one. Can you shed some light? Thanks! -- Alex -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/