[sr-dev] [kamailio/kamailio] 100% CPU usage after NTP date update (#2046)

Daniel-Constantin Mierla notifications at github.com
Thu Aug 29 19:18:31 CEST 2019


Iiirc from older discussions, here is about the timer trying to catch up to the new current time by executing the timer callbacks for each timer step in between.

There were proposals to skip executing timer callbacks for intermediate timer steps, but not sure if something was done. In such case there can be other side effects as some callbacks are no longer executed when it should - e.g., timer to retransmit the requests in active transactions, which should be done in 0.5, 1, 2, 4 seconds steps, if time jumps too much in the future and those timer callbacks are not executed, then some side effects can happen, like transaction left unexpired in memory (leak).

But then executing each timer step (iirc, it is like every 0.1sec) quickly in a raw without sleep to fill a long interval like 2 years it's going to use a lot of CPU.

I am fine if someone comes with some solution/improvement here, eventually controlled by a core parameter. Otherwise can be be seen as a bug either way:
  * avoid high CPU - skip callbacks execution for intermediate steps, but some other potential ugly side effects
  * have high CPU with callbacks execution for intermediate steps, but then maybe other processing gets delayed or not even proper handling of sip traffic

Over all, I consider this not to be a bug, but more an enhancement nice to have, because having the time jumping a long interval to the future is not a normal operation mode. If someone has root access can use gdb and change values in memory for kamailio to create infinite loops or other bad things.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2046#issuecomment-526280672
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20190829/57eca59d/attachment-0001.html>


More information about the sr-dev mailing list