OK..May i send you my script privately? On Thu, Mar 9, 2017 at 6:13 PM, Răzvan Crainea <raz...@opensips.org> wrote:
> 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 Solutionswww.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.nash...@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.nash...@gmail.com> wrote: >> >>> OK Here is the dump >>> 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 <raz...@opensips.org> >>> wrote: >>> >>>> No, you should not kill any process. Simply send a SIGUSR1 to the >>>> process you suspect. >>>> >>>> Răzvan Crainea >>>> OpenSIPS Solutionswww.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 <raz...@opensips.org> >>>> wrote: >>>> >>>>> use only memdump set to 1. >>>>> >>>>> Răzvan Crainea >>>>> OpenSIPS Solutionswww.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 <raz...@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 Solutionswww.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.nash...@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 Solutionswww.opensips-solutions.com >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> Users@lists.opensips.org >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>> >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Users mailing >>>>> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> >>>>> _______________________________________________ Users mailing list >>>>> Users@lists.opensips.org http://lists.opensips.org/cgi- >>>>> bin/mailman/listinfo/users >>>> >>>> _______________________________________________ >>>> Users mailing >>>> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>>> _______________________________________________ Users mailing list >>>> Users@lists.opensips.org http://lists.opensips.org/cgi- >>>> bin/mailman/listinfo/users >>> >>> _______________________________________________ > Users mailing > listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >
_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users