[SR-Users] High load average

Володимир Іванець volodyaivanets at gmail.com
Mon May 25 17:56:22 CEST 2020


Hello again,

I attached a new file.

The interesting part is that Kamailio does not load the CPU at all. *Top* shows
it at the bottom. Only the "load average" value gets increased.

Thank you!

пн, 25 трав. 2020 о 16:34 Daniel-Constantin Mierla <miconda at gmail.com> пише:

> Hello,
>
> can you install the package with kamailio debugging symbols? Then take
> again the kamctl trap with two async workers, it should contain more
> details about what pieces of code run.
>
> The package should be named like kamailio-dbg...
>
> Besides that, can you also do a 'top' and see what kamailio processes
> (their PIDs) eat a lot of cpu?
>
> Cheers,
> Daniel
> On 25.05.20 11:05, Володимир Іванець wrote:
>
> Hello,
>
> Attached are two files. One for 2 Async Task Workers and one for 8
> Workers. The second one was stuck and did not complete.
>
> I should point out that the virtual machine has 2 CPU cores. Load average
> value was stable with 2 workers and was slowly increasing after adding more
> workers. * workers caused it to increase very fast.
>
> Thank you!
>
> пт, 22 трав. 2020 о 22:00 Daniel-Constantin Mierla <miconda at gmail.com>
> пише:
>
>> Hello,
>>
>> if you can, it would be interesting to get the backtrace and see what was
>> causing the load.
>>
>> Iirc, the Async Task Worker should wait on read on an internal socket, so
>> it should be no CPU used when nothing is transmitted to this type of
>> workers.
>>
>> Cheers,
>> Daniel
>> On 22.05.20 19:20, Володимир Іванець wrote:
>>
>> Hello Daniel,
>>
>> Thank you for your response.
>>
>> I run *kamctl trap* command but the procedure got stuck. Last line in
>> the generated file contained "---start 12767 -----".  12767 was an Async
>> Task Worker. Since I don't need them I just removed related configuration.
>> It must be left after the testing. This solved the problem.
>>
>> Please let me know if you are still interested in what was going on and
>> if I should restore the configuration and run *kamctl trap* again.
>>
>> Thank you very much!
>>
>> пт, 22 трав. 2020 о 19:10 Daniel-Constantin Mierla <miconda at gmail.com>
>> пише:
>>
>>> Hello,
>>>
>>> install gdb and, when the load is high, run:
>>>
>>> kamctl trap
>>>
>>> It write a file with what kamailio was doing at that moment. Send it
>>> over here on mailing list or make it available for download somewhere. We
>>> can look at it and guide further about what can be done.
>>>
>>> Cheers,
>>> Daniel
>>> On 22.05.20 16:53, Володимир Іванець wrote:
>>>
>>> Hello everyone!
>>>
>>> I'm running Kamailio version 5.3.3 on a CentOS 6. I started noticing
>>> that "load average" value increases rapidly with the start of Kamailio:
>>>
>>> # uptime
>>> 17:47:52 up 4 days, 17:47,  3 users,  load average: 7.02, 7.01, 6.02
>>>
>>> It will start to decrease immediately after Kamailio is stopped.
>>>
>>> Does anyone know what could cause this and how to troubleshoot it?
>>>
>>> Thank you!
>>>
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing Listsr-users at lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>> --
>>> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
>>> Funding: https://www.paypal.me/dcmierla
>>>
>>> --
>> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
>> Funding: https://www.paypal.me/dcmierla
>>
>> --
> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
> Funding: https://www.paypal.me/dcmierla
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200525/b5f99221/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gdb_kamailio_20200525_181421
Type: application/octet-stream
Size: 192450 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200525/b5f99221/attachment.obj>


More information about the sr-users mailing list