<div dir="ltr">Hi Daniel! thx for the reply too!<br>Richard was correct about hash table (I tried a couple of experiments)<br>So it i not a Leak in bug point of view but behavior that gives growing hash of rtpengine module<br><br>If I looking at the kamcmd rtpengine.get_hash_total with watch every second - I see it growing<br>Also if I disabling rtpengine_<> calling -I see shmem is not growing at all<br><br>So for now question only how to reset/not use/drop hash table for the rtpengine modue</div><br><div class="gmail_quote"><div dir="ltr">ср, 2 янв. 2019 г. в 17:32, Daniel-Constantin Mierla <<a href="mailto:miconda@gmail.com">miconda@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hello,<div><br></div><div>to see the source of the leak in shared memory, the best is to generate usage summary.</div><div><br></div><div><div>First set memlog lower than debug parameter, you can do in the kamailio.cfg or via rpc:</div><div><br></div><div>kamcmd cfg.set_now_int core memlog 1</div><div><br></div><div>The above sets memlog to 1, so choose a value lower than what you have for debug.</div><div><br></div><div>The generate the summary via rpc:</div><div><br></div><div>kamcmd corex.shm_summary</div></div><div><br></div><div>Look in syslog for printed messages related to use of shared memory.</div><div><br></div><div>Cheers,</div><div>Daniel</div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 2, 2019 at 2:45 PM Richard Fuchs <<a href="mailto:rfuchs@sipwise.com" target="_blank">rfuchs@sipwise.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 02/01/2019 07.45, Yuriy Gorlichenko wrote:<br>
> Hi!<br>
> Happy new year to all!!!<br>
><br>
> Look like I am first in this year wit hthe questions in this list :-).<br>
><br>
> I'm using stateless kamailio and RTPengnine to build some kind of the <br>
> stateless cluster<br>
> I found that kamailio keeps some data  in the SHMEM in case of using <br>
> RTPengine module even if it is not a rtpengine_manage function but <br>
> offer/answer/delete<br>
><br>
> In this case if INVITE (offer) handled by 1-st kamailio in my cluster, <br>
> and BYE/CANCEL handled by second kamailio in the cluster - 1-st <br>
> kamailio (which has been used for offer) will hase kinda internal <br>
> "memory leak" (in SHMEM it never decrased)<br>
><br>
> At the rtpengine module source I found some transation dependencies <br>
> for the rtpengine_manage function but did not find for the <br>
> offer/answer/delete<br>
> I supposed these 3 functions just sending requests to the rtpnegine <br>
> with keys and not storing anything<br>
><br>
> So my question - is it possible to use RTPengine module in stateless <br>
> way to avoid internal "memory leak" because in my scenario I have big <br>
> chance never receive  BYE/CANCEL on the machine that started handle <br>
> particular call<br>
<br>
<br>
This is probably the module-internal hash table that is used to make <br>
sure that signalling relating to the same call is always sent to the <br>
same rtpengine instance. This hash table does have a configurable <br>
timeout value (`hash_table_tout`, defaults to 1 hour), which makes it <br>
possible to still use it in a way you've described. However, from the <br>
code it's my understanding that timed out hash table entries are only <br>
deleted when they're encountered during processing, so it's not entirely <br>
deterministic that old entries are always deleted after they've timed <br>
out. The RPC command `rtpengine.get_hash_total` can be used to inspect <br>
the current size of the hash table.<br>
<br>
Cheers<br>
<br>
<br>
_______________________________________________<br>
Kamailio (SER) - Users Mailing List<br>
<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_5793766379547963227gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Daniel-Constantin Mierla - <a href="http://www.asipto.com" target="_blank">http://www.asipto.com</a></div><div><a href="http://twitter.com/#!/miconda" target="_blank">http://twitter.com/#!/miconda</a> - <a href="http://www.linkedin.com/in/miconda" target="_blank">http://www.linkedin.com/in/miconda</a></div></div></div></div></div>
_______________________________________________<br>
Kamailio (SER) - Users Mailing List<br>
<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</blockquote></div>