[SR-Users] rtimer execution period - round two

[Alex Balashov]

I am wondering if the execution time of a route is somehow bounded in 
action.c/run_actions().  Unfortunately, I don't enough about how it 
works to figure it out.

On 07/23/2012 08:38 PM, Alex Balashov wrote:

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