[SR-Users] rtimer execution period - round two

[Alex Balashov]

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:

 > there is no timeout on the execution of that task. Of course, you
 > can start many rtimer processes to do same task, up to you,
 > via configuration parameters. A matter of how rtimer executed
 > route is built, a rtimer process may not rest (e.g., sleep) and
 > keep consuming mqueue items as long as the queue is not empty."

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=41f77159c5851bb36ad12abecc2faf58602d6935

(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/