On Fri, Sep 26, 2008 at 7:20 AM, Benny Prijono <bennylp at pjsip.org> wrote: > On Thu, Sep 25, 2008 at 11:11 AM, Gang Liu <gangban.lau at gmail.com> wrote: > >> hi benny, >> I redid test carefully today. The result still was strange. The memory >> wouldn't be released back to OS even after long time waiting. >> Below are some data I collected. Next time I will try to use valgrind to >> look what's happening of heap. My program using pjsip has the same issue. >> But valgrind didn't find memory leak of my program. >> >> > > I think this could be attributed to couple of things. When I run sipp > against pjsua, I notice that after a while there are few CONFIRMED calls in > pjsua, eventhough sipp has been paused for sometime. Although this is not > right, I don't think this alone explains the huge memory being used. > > The second thing, and I think this is the most probably cause of the > symptom, is probably memory caching by libc. You can search for this topic > on the net. With pjsip, all heap memory (except the heap allocated by third > party library such as speex, libsrtp, or portaudio) are allocated from the > caching pool, and with pjsua you can see the list of memory blocks used by > the caching pool with "dd" command. In my case, although the "dd" shows low > memory usage by the caching pool, the actual memory usage observed by "top" > is still high, so the caching must be done by something outside pjlib. > Yes, I already tried "dd" command before. And I also dump pjsip-perf pools. The dump info also show memory usage is low. But if I run the test all the day at more higher cps , pjsip-perf almost use 1.5G RAM and cause my linux run into memory swapping. So it is interested what's the reason. I will get back when I try valgrind. regards, Gang > > Cheers > Benny > > > > >> 1, ####### pjsip compile ######### >> I copy config_site_sample.h to config_site.h. And then I define >> PJ_CONFIG_MAXIMUM_SPEED at that file, change >> PJ_IOQUEUE_MAX_HANDLES to 1000. I also set CACHING_POOL_SIZE to zero of >> pjsip-perf.c >> ./configure;make dep;make >> >> 2, ####### sipp as caller, pjsip-perf as callee, 200 cps ############ >> >> sipp -sf uac_rr.xml -p 5061 -l 50000 -r 200 -d 6000 -m 1000000 -s 2 >> 192.168.0.233:25060 >> >> -bash-3.00$ ./pjsip-perf-i686-pc-linux-gnu --method=INVITE >> --local-port=25060 --trying --ringing >> PJSIP Performance Measurement Tool v0.9.0-release >> (c)2006 pjsip.org >> pjsip-perf started in server-mode >> Receiving requests on the following URIs: >> sip:0 at 192.168.0.233:25060 for stateless handling >> sip:1 at 192.168.0.233:25060 for stateful handling >> sip:2 at 192.168.0.233:25060 for call handling >> INVITE with non-matching user part will be handled call-statefully >> Press <ENTER> to quit >> Total(rate): stateless:0 (0/s), statefull:0 (0/s), call:13.3K (199/s) >> >> memory when test running >> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND >> 23676 gang 18 0 156m 141m 1700 S 0.0 7.0 0:00.04 >> pjsip-perf-i686 >> >> memory when 1 hour after 1 million calls finished >> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND >> 23676 gang 18 0 154m 140m 1700 S 0.0 6.9 0:00.24 >> pjsip-perf-i686 >> >> -bash-3.00$ ./pjsip-perf-i686-pc-linux-gnu --method=INVITE >> --local-port=25060 --trying --ringing >> PJSIP Performance Measurement Tool v0.9.0-release >> (c)2006 pjsip.org >> pjsip-perf started in server-mode >> Receiving requests on the following URIs: >> sip:0 at 192.168.0.233:25060 for stateless handling >> sip:1 at 192.168.0.233:25060 for stateful handling >> sip:2 at 192.168.0.233:25060 for call handling >> INVITE with non-matching user part will be handled call-statefully >> Press <ENTER> to quit >> Total(rate): stateless:0 (0/s), statefull:0 (0/s), call:1.00M (0/s) >> 17:23:59.857 pjsip-perf.c Peak memory size: 151MB >> -bash-3.00$ >> >> >> 3, ############ repeat the same test, but at 800 cps. ################# >> >> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND >> 23827 gang 18 0 521m 506m 1700 S 0.0 25.0 2:42.07 >> pjsip-perf-i686 >> >> OS: >> -bash-3.00$ cat /etc/redhat-release >> CentOS release 4.7 (Final) >> >> GCC: >> -bash-3.00$ gcc -v >> Using built-in specs. >> Target: i686-pc-linux-gnu >> Configured with: ./configure >> Thread model: posix >> gcc version 4.1.1 >> >> PJSIP: >> pjproject-0.9.0 release >> >> >> >> On Mon, Sep 22, 2008 at 7:31 AM, Benny Prijono <bennylp at pjsip.org> wrote: >> >>> On Fri, Sep 12, 2008 at 6:58 AM, Gang Liu <gangban.lau at gmail.com> wrote: >>> >>>> I know pjsip-perf is configured to cache up to 256 MB of memory. >>>> >>>> But real memory is much higher than this. >>>> >>>> >>> I don't think that's peculiar . If the application needs more memory, >>> then more memory will be allocated. >>> >>> >>> On Fri, Sep 12, 2008 at 1:20 PM, Gang Liu <gangban.lau at gmail.com> wrote: >>> >>>> Hi, >>>> I found the memory size after all call finished is mostly the >>>> same as calling. >>>> >>>> >>> >>> Bear in mind that it may take up to 32 seconds before SIP >>> calls/transactions are destroyed even after they're disconnected/completed. >>> >>> -benny >>> >>> >>> >>>> pjsip-pref is as a uas, sipp as a uac. >>>> >>>> >>>> Is it normal? >>>> >>>> 23047 gang 18 0 310m 296m 1492 S 0 14.6 0:00.02 >>>> pjsip-perf-i686 >>>> 23048 gang 15 0 310m 296m 1492 S 0 14.6 0:37.56 >>>> pjsip-perf-i686 >>>> regards, >>>> Gang >>>> >>> >>> >>>> _______________________________________________ >>>> Visit our blog: http://blog.pjsip.org >>>> >>>> pjsip mailing list >>>> pjsip at lists.pjsip.org >>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >>>> >>>> >>> >>> _______________________________________________ >>> Visit our blog: http://blog.pjsip.org >>> >>> pjsip mailing list >>> pjsip at lists.pjsip.org >>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >>> >>> >> >> _______________________________________________ >> Visit our blog: http://blog.pjsip.org >> >> pjsip mailing list >> pjsip at lists.pjsip.org >> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >> >> > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080926/12a69b01/attachment-0001.html>
