[OpenSIPS-Users] Quest to find memory leak

[Răzvan Crainea]

Hi, John!

The traces you showed me are incomplete: they do not have all the memory 
chunks allocated, thus I can't say wether something is wrong or not.
As I said earlier, it is normal for opensips to use extra memory every 
call. But after a while, this should stabilize. After a while might mean 
more than 1000k calls. As long as you never reach the upper limit of the 
memory, you can't conclude that there is a memory leak. Even then, 
you're limit might be too low for the kind of traffic you are doing, so 
it still might not be a memory leak. But only then it is worth to 
investigate.
When we investigate, we need all the data (i.e. the entire trace of the 
memory dump).
So please try to send as many calls as possilble, and if this issue 
still persists, make a pkg memory dump when the server is in idle mode 
and send it over.

Best regards,

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com

On 03/08/2017 11:26 AM, John Nash wrote:
> any suggestion for me?..should i try to crash opensips by sending many 
> calls?
>
> On Tue, Mar 7, 2017 at 4:54 PM, John Nash <john.nash778 at gmail.com 
> <mailto:john.nash778 at gmail.com>> wrote:
>
>     version: opensips 2.1.5 (x86_64/linux)
>     flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC,
>     DBG_QM_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
>     ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN
>     16, MAX_URI_SIZE 1024, BUF_SIZE 65535
>     poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
>     git revision: 39b19dd
>     main.c compiled on 19:27:59 Mar  5 2017 with gcc 4.4.7
>
>     memory stabilizing in time? Or it is continously decreasing?
>     Yes, that's how you should make the dump.
>
>     Best regards,
>
>     Răzvan Crainea
>     OpenSIPS Solutions
>     www.opensips-solutions.com <http://www.opensips-solutions.com>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20170308/e265f488/attachment.html>