[SR-Users] kamailio 4.4.1 DROUTING module memory leak ?
Uri Shacked
ushacked at gmail.com
Fri Jan 12 09:24:46 CET 2018
Daniel,
It seems to keep on growing after calls traffic increased.:-(
On production after dr_timer.c was changed and kamailio installed again,
Thanks,
Uri
On Fri, Jan 12, 2018 at 7:33 AM, Uri Shacked <ushacked at gmail.com> wrote:
> Ok,
> Installed on production at midnight.
> After 7 hours with very small traffic the ac_get_maxval keeps on growing.
> At startup count = 6 size = 120 bytes
> After 7 hours with no more than 1000 calls, cout = 3756 size = 124144.
>
> I have a feeling is still leaks.
>
> בתאריך 11 בינו׳ 2018 20:02, "Uri Shacked" <ushacked at gmail.com> כתב:
>
> installed.
>> hard to get enough traffic on test.
>> will deploy today, and have results on sunday.
>>
>> On Thu, Jan 11, 2018 at 4:08 PM, Daniel-Constantin Mierla <
>> miconda at gmail.com> wrote:
>>
>>>
>>>
>>> On 11.01.18 13:04, Uri Shacked wrote:
>>>
>>> Thanks.
>>> installed OK on my test environment.
>>>
>>>
>>> Only installed or also tested a bit and all looks fine so far?
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>> will install in 2 days on my production and keep you posted.
>>>
>>>
>>> On Thu, Jan 11, 2018 at 1:21 PM, Daniel-Constantin Mierla <
>>> miconda at gmail.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> can you try with the patch from this commit:
>>>>
>>>> - https://github.com/kamailio/kamailio/commit/e0f95ea7fc691f97
>>>> 6564b07436848673c633195d
>>>>
>>>> The memset() is optional, more for long term safety, the if block at
>>>> the end of the function is relevant.
>>>>
>>>> In 4.4, the file to change is modules/drouting/dr_time.c instead of
>>>> src/modules/drouting/dr_time.c.
>>>>
>>>> If all is fine, then I will backport it.
>>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>>> On 11.01.18 11:57, Uri Shacked wrote:
>>>>
>>>> Hi,
>>>> I have some kind of memory growth (leak?).
>>>> kamailio 4.4.1.
>>>> started with 64M for shmem, had a crash after 5 days of traffic.
>>>> increased shmem to 128, but still memory grows everyday.
>>>> when traffic load decrease, the memory growth stops but memory stays on
>>>> the same level. when traffic increase again,used memory continue to grows
>>>> again.
>>>>
>>>> I started kamailio now with the "-x qm" option to debug shmem.
>>>> every half hour i dump the status of it.
>>>>
>>>> there are several modules that the memory size is increasing (some of
>>>> them are obvious).
>>>>
>>>> but, one is very strange.... DROUTING
>>>>
>>>> I am using drouting module for each call on my kamailio.
>>>> the DB tables are very small, and there is no reloads.
>>>>
>>>> only one time used in my script :
>>>> ..
>>>> ...
>>>> subst_user('/(.*)/$avp(xxx)/');
>>>> if(!do_routing("$avp(yyyy)")){
>>>> xlog...somthing;
>>>> return(-1)
>>>> }
>>>> ..
>>>> ....
>>>>
>>>> the shmem that is rapidly growing and does not make sense is:
>>>> "from drouting: dr_time.c: ac_get_maxval(219)"
>>>>
>>>> seems that when i used mem_join =1, the growth was smaller, but still
>>>> significant.
>>>> now i use mem_join = 0, it seems rapidly increasing...
>>>>
>>>> I have more information from the logs, will send it if necessary (it is
>>>> just a lot...)
>>>>
>>>>
>>>> any ideas ?
>>>> cheers,
>>>> Uri
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Kamailio (SER) - Users Mailing Listsr-users at lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>>
>>>> --
>>>> Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda
>>>> Kamailio Advanced Training - March 5-7, 2018, Berlin - www.asipto.com
>>>> Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
>>>>
>>>>
>>>
>>> --
>>> Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda
>>> Kamailio Advanced Training - March 5-7, 2018, Berlin - www.asipto.com
>>> Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20180112/f0b23246/attachment-0001.html>
More information about the sr-users
mailing list