Hi Daniel! thx for the reply too!
Richard was correct about hash table (I tried a couple of experiments)
So it i not a Leak in bug point of view but behavior that gives growing hash of rtpengine module

If I looking at the kamcmd rtpengine.get_hash_total with watch every second - I see it growing
Also if I disabling rtpengine_<> calling -I see shmem is not growing at all

So for now question only how to reset/not use/drop hash table for the rtpengine modue

ср, 2 янв. 2019 г. в 17:32, Daniel-Constantin Mierla <miconda@gmail.com>:
Hello,

to see the source of the leak in shared memory, the best is to generate usage summary.

First set memlog lower than debug parameter, you can do in the kamailio.cfg or via rpc:

kamcmd cfg.set_now_int core memlog 1

The above sets memlog to 1, so choose a value lower than what you have for debug.

The generate the summary via rpc:

kamcmd corex.shm_summary

Look in syslog for printed messages related to use of shared memory.

Cheers,
Daniel


On Wed, Jan 2, 2019 at 2:45 PM Richard Fuchs <rfuchs@sipwise.com> wrote:
On 02/01/2019 07.45, Yuriy Gorlichenko wrote:
> Hi!
> Happy new year to all!!!
>
> Look like I am first in this year wit hthe questions in this list :-).
>
> I'm using stateless kamailio and RTPengnine to build some kind of the
> stateless cluster
> I found that kamailio keeps some data  in the SHMEM in case of using
> RTPengine module even if it is not a rtpengine_manage function but
> offer/answer/delete
>
> In this case if INVITE (offer) handled by 1-st kamailio in my cluster,
> and BYE/CANCEL handled by second kamailio in the cluster - 1-st
> kamailio (which has been used for offer) will hase kinda internal
> "memory leak" (in SHMEM it never decrased)
>
> At the rtpengine module source I found some transation dependencies
> for the rtpengine_manage function but did not find for the
> offer/answer/delete
> I supposed these 3 functions just sending requests to the rtpnegine
> with keys and not storing anything
>
> So my question - is it possible to use RTPengine module in stateless
> way to avoid internal "memory leak" because in my scenario I have big
> chance never receive  BYE/CANCEL on the machine that started handle
> particular call


This is probably the module-internal hash table that is used to make
sure that signalling relating to the same call is always sent to the
same rtpengine instance. This hash table does have a configurable
timeout value (`hash_table_tout`, defaults to 1 hour), which makes it
possible to still use it in a way you've described. However, from the
code it's my understanding that timed out hash table entries are only
deleted when they're encountered during processing, so it's not entirely
deterministic that old entries are always deleted after they've timed
out. The RPC command `rtpengine.get_hash_total` can be used to inspect
the current size of the hash table.

Cheers


_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


--
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users