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. 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080926/4eaaf848/attachment.html>
