[SR-Users] Out of memory in UB 210: OOM killed process 12261 (kamailio) score 0 vm:1614768kB, rss:280200kB, swap:131408kB

Jurijs Ivolga jurijs.ivolga at gmail.com
Fri Oct 21 11:22:44 CEST 2016


Hi Daniel,

After 8 days there is still small memory leak, 200MB of Ram wasn't freed
during this 8 days, please check diagram below.

1) Is this something usual?
2) Memory leak seems very small, maybe I should never worry about this?
What you think?

[image: Inline image 2]

Thank
you!

With kind regards,

Jurijs

On Wed, Oct 12, 2016 at 4:47 PM, Daniel-Constantin Mierla <miconda at gmail.com
> wrote:

> Hello,
>
> thanks -- coming in my mind now, xcap_client should use also the curl
> library.
> Cheers,
> Daniel
>
>
> On 12/10/16 15:35, Jurijs Ivolga wrote:
>
> Hi Daniel,
>
> I will test couple more days and later I will try to add some comments to
> utils, http_client & HTTP_ASYNC_CLIENT(not sure if there any other modules
> which use curl, but I will check) modules when I will be 200% sure that
> issue is gone.
>
> With kind regards,
>
> Jurijs
>
> On Wed, Oct 12, 2016 at 4:30 PM, Daniel-Constantin Mierla <
> miconda at gmail.com> wrote:
>
>> Hello,
>>
>> ok, so that was...
>>
>> Maybe it would be good to add a note to the docs of the module about this
>> issue so people become aware of it. I guess the other http_* modules are
>> affected. Pull requests or other suggestions are welcome, of course!
>>
>> Cheers,
>> Daniel
>>
>> On 12/10/16 15:04, Jurijs Ivolga wrote:
>>
>> Hi Daniel,
>>
>> Thank you a lot, it looks that issue is solved, after updating libcurl.
>>
>> I was using following manual for updating libcurl, in case if somebody
>> will have same issue.
>>
>> https://www.digitalocean.com/community/questions/how-to-upgr
>> ade-curl-in-centos6
>>
>> With kind regards,
>>
>> Jurijs
>>
>> On Tue, Oct 11, 2016 at 2:43 PM, Jurijs Ivolga <jurijs.ivolga at gmail.com>
>> wrote:
>>
>>> Hi Daniel,
>>>
>>> You are correct we are using heavily http_query.
>>>
>>> I found following bug report:
>>>
>>> https://bugs.centos.org/view.php?id=9391
>>>
>>> I will try to update to libcurl 7.44 and check if this help.
>>>
>>> Thank you a lot Daniel!
>>>
>>> With kind regards,
>>>
>>> Jurijs
>>>
>>> On Tue, Oct 11, 2016 at 10:55 AM, Daniel-Constantin Mierla <
>>> miconda at gmail.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> from the logs, it seems to be related to curl library, I see many
>>>> reports like:
>>>>
>>>> ==16459== 189,318 bytes in 167 blocks are possibly lost in loss record
>>>> 681 of 683
>>>> ==16459==    at 0x4C26FEF: calloc (vg_replace_malloc.c:711)
>>>> ==16459==    by 0x104BB699: ??? (in /usr/lib64/libnsspem.so)
>>>> ==16459==    by 0x104AA537: ??? (in /usr/lib64/libnsspem.so)
>>>> ==16459==    by 0x104AB81E: ??? (in /usr/lib64/libnsspem.so)
>>>> ==16459==    by 0x104B0B88: ??? (in /usr/lib64/libnsspem.so)
>>>> ==16459==    by 0x104B77E1: ??? (in /usr/lib64/libnsspem.so)
>>>> ==16459==    by 0xB71ABC9: ??? (in /usr/lib64/libnss3.so)
>>>> ==16459==    by 0xB71AE62: PK11_CreateGenericObject (in
>>>> /usr/lib64/libnss3.so)
>>>> ==16459==    by 0xA0674DF: ??? (in /usr/lib64/libcurl.so.4.1.1)
>>>> ==16459==    by 0xA067666: ??? (in /usr/lib64/libcurl.so.4.1.1)
>>>> ==16459==    by 0xA069141: ??? (in /usr/lib64/libcurl.so.4.1.1)
>>>> ==16459==    by 0xA0601C4: Curl_ssl_connect (in
>>>> /usr/lib64/libcurl.so.4.1.1)
>>>>
>>>> That's like almost 200KB lost in this report.
>>>>
>>>> From the list of the modules, I see you have utils and I guess you use
>>>> http query function from there, is it?
>>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>>> On 10/10/16 12:06, Jurijs Ivolga wrote:
>>>>
>>>> Hi Daniel,
>>>>
>>>> I left valgrind running for little while, not sure if this will be
>>>> enough.
>>>>
>>>> Please find attached log file.
>>>>
>>>> Thank you a lot for your help!
>>>>
>>>> With kind regards,
>>>>
>>>> Jurijs
>>>>
>>>> On Fri, Oct 7, 2016 at 7:15 PM, Daniel-Constantin Mierla <
>>>> miconda at gmail.com> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> that's the way it was done for older versions of kamailio.
>>>>>
>>>>> In master and 4.4 the memory debugging is turned on and it is
>>>>> reflected by the presence of DBG_SR_MEMORY in the output of 'kamailio -v'.
>>>>>
>>>>> Anyhow, what you reported is not a leak inside kamailio memory
>>>>> manager, but a leak of using system memory, so it is not affected by
>>>>> DBG_SR_MEMORY and cannot be troubleshooted using the mechanisms for pkg and
>>>>> shm managers.
>>>>>
>>>>> Cheers,
>>>>> Daniel
>>>>>
>>>>>
>>>> --
>>>> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>>> Kamailio Advanced Training, Berlin, Oct 24-26, 2016 - http://www.asipto.com
>>>>
>>>> --
>> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>> Kamailio Advanced Training, Berlin, Oct 24-26, 2016 - http://www.asipto.com
>>
>> --
> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Berlin, Oct 24-26, 2016 - http://www.asipto.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20161021/1a222f90/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kamailio.png
Type: image/png
Size: 57488 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20161021/1a222f90/attachment.png>


More information about the sr-users mailing list