<div dir="ltr"><div class="gmail_default" style="font-family:"courier new",monospace">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:</div><div class="gmail_default" style="font-family:"courier new",monospace"><br></div><div class="gmail_default" style="font-family:"courier new",monospace">NOTICE:tm:timer_routine: time spent: 0.780s now at 75%+ capacity, inuse_transactions: 11070<br>NOTICE:tm:utimer_routine: time spent: 0.680s now at 75%+ capacity, inuse_transactions: 11070</div><div class="gmail_default" style="font-family:"courier new",monospace"><br></div><div class="gmail_default" style="font-family:"courier new",monospace">I'll come back to the core dumps if I ever get a clean core file.</div><div class="gmail_default" style="font-family:"courier new",monospace"><br></div><div class="gmail_default" style="font-family:"courier new",monospace">Richard Revels</div><div class="gmail_default" style="font-family:"courier new",monospace"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, Jun 24, 2025 at 12:52 PM Richard Revels <<a href="mailto:rrevels@bandwidth.com">rrevels@bandwidth.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Greetings,<br>I have started having issues with some proxies running opensips 3.2.19 and some others running 3.4.12<br>With approximately 230 cps and 7300 dialogs the proxy starts emitting log messages like<br><br>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<br>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<br>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<br>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<br>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<br>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<br>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<br>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<br>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<br>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<br><br><br>The cpu usage on the threads goes from 3% - 11% depending on thread to 30% across the board.<br><br>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.<br><br>So,<br><br>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<br><br>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?<br><br>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<br><br>Thank you in advance for any guidance you can give me on troubleshooting this issue.<br>Richard Revels</div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><span><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><br></p></span></div></div></div></div></div></div></div>
</blockquote></div></div>