[OpenSIPS-Users] Quest to find memory leak
Răzvan Crainea
razvan at opensips.org
Thu Mar 9 07:43:56 EST 2017
Hi, John!
No, I nothing is suspicious. Definitely not from the drouting module.
Try to make two captures: one after 10 calls, another one after 20 calls.
Best regards,
Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com
On 03/09/2017 01:50 PM, John Nash wrote:
> Do you see anything suspicious in the latest mem dump?
>
> On Wed, Mar 8, 2017 at 7:20 PM, John Nash <john.nash778 at gmail.com
> <mailto:john.nash778 at gmail.com>> wrote:
>
> One more useful info. I disabled drouting functions and just
> rewrote RURI to hardcoded address keeping rest of the functions
> same and I do not see drop in private memory of that process.
>
> On Wed, Mar 8, 2017 at 4:40 PM, John Nash <john.nash778 at gmail.com
> <mailto:john.nash778 at gmail.com>> wrote:
>
> OK Here is the dump
> https://drive.google.com/open?id=0BxJKNwFalcRMX0xDUlRIa2VUdG8
> <https://drive.google.com/open?id=0BxJKNwFalcRMX0xDUlRIa2VUdG8>
>
>
> I increased syslog message rate to 500000, Made around 10 call
> attempts. Waited for some time and made sure no call is on
> server and then sent signal to dump memory to the process ID i
> suspect.
>
> On Wed, Mar 8, 2017 at 4:07 PM, Răzvan Crainea
> <razvan at opensips.org <mailto:razvan at opensips.org>> wrote:
>
> No, you should not kill any process. Simply send a SIGUSR1
> to the process you suspect.
>
> Răzvan Crainea
> OpenSIPS Solutions
> www.opensips-solutions.com <http://www.opensips-solutions.com>
>
> On 03/08/2017 12:28 PM, John Nash wrote:
>> Sorry...Should I kill only the process where i see memory
>> leak?
>>
>> On Wed, Mar 8, 2017 at 3:41 PM, Răzvan Crainea
>> <razvan at opensips.org <mailto:razvan at opensips.org>> wrote:
>>
>> use only memdump set to 1.
>>
>> Răzvan Crainea
>> OpenSIPS Solutions
>> www.opensips-solutions.com
>> <http://www.opensips-solutions.com>
>>
>> On 03/08/2017 12:11 PM, John Nash wrote:
>>> Ok i will give another try what should be the values
>>> of memdump and memlog
>>>
>>> On Wed, Mar 8, 2017 at 3:13 PM, Răzvan Crainea
>>> <razvan at opensips.org <mailto:razvan at opensips.org>>
>>> wrote:
>>>
>>> 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
>>> <http://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>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> <mailto:Users at lists.opensips.org>
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>> <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> <mailto:Users at lists.opensips.org>
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>> <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>> _______________________________________________ Users
>> mailing list Users at lists.opensips.org
>> <mailto:Users at lists.opensips.org>
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
> _______________________________________________ Users
> mailing list Users at lists.opensips.org
> <mailto:Users at lists.opensips.org>
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20170309/1f62a08b/attachment-0001.html>
More information about the Users
mailing list