[OpenSIPS-Users] questions about WARNING:core:utimer_ticker

[Richard Revels]

Okay, I'm starting to get a handle on what I'm looking at now and those
timer messages appear to be related to Opensips not shutting down cleanly
rather than the segfault itself.  My question around tm timer tuning should
have been in reference to this type of message:

NOTICE:tm:timer_routine: time spent: 0.780s now at 75%+ capacity,
inuse_transactions: 11070
NOTICE:tm:utimer_routine: time spent: 0.680s now at 75%+ capacity,
inuse_transactions: 11070

I'll come back to the core dumps if I ever get a clean core file.

Richard Revels


On Tue, Jun 24, 2025 at 12:52 PM Richard Revels <rrevels at bandwidth.com>
wrote:

> Greetings,
> I have started having issues with some proxies running opensips 3.2.19 and
> some others running 3.4.12
> With approximately 230 cps and 7300 dialogs the proxy starts emitting log
> messages like
>
> Jun 24 15:42:18 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 150
> ms ago (now 3671145080 ms), delaying execution
> Jun 24 15:42:18 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 200
> ms ago (now 3671145130 ms), delaying execution
> Jun 24 15:42:18 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 300
> ms ago (now 3671145230 ms), delaying execution
> Jun 24 15:42:18 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 400
> ms ago (now 3671145330 ms), delaying execution
> Jun 24 15:42:18 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 500
> ms ago (now 3671145430 ms), delaying execution
> Jun 24 15:42:19 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 600
> ms ago (now 3671145530 ms), delaying execution
> Jun 24 15:42:19 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 700
> ms ago (now 3671145630 ms), delaying execution
> Jun 24 15:42:19 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 800
> ms ago (now 3671145730 ms), delaying execution
> Jun 24 15:42:19 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 900
> ms ago (now 3671145830 ms), delaying execution
> Jun 24 15:42:19 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:timer_ticker: timer task <tm-timer> already scheduled 1000 ms
> ago (now 3671145830 ms), delaying execution
>
>
> The cpu usage on the threads goes from 3% - 11% depending on thread to 30%
> across the board.
>
> I have been running these versions of opensips for some time now (months
> for 3.4 and years for 3.2) and do see occasional latency in db or rest
> connection responses but only recently have started having this issue.
>
> So,
>
> How are SIP calls distributed across the processing threads?  I was
> thinking it would be round robin w/ attention given to busy or not.  but it
> seems like the lower pid threads do a lot more work on these proxies
>
> What are possible causes of the timers having trouble completing tasks?
> is it cpu use, waiting on some other task to finish, combination or more?
>
> Is there tuning that can be done to have more timer handling threads?  i
> tried this with modparam("tm", "timer_partitions") which seemed to make the
> problem worse
>
> Thank you in advance for any guidance you can give me on troubleshooting
> this issue.
> Richard Revels
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20250625/154763bc/attachment-0001.html>