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