Thanks for the reply. On Mon, Jan 19, 2009 at 5:07 AM, Gang Liu <gangban.lau at gmail.com> wrote: > 1, memory pool implementation of pjlib is good solution to avoid linux > memory fragmentation. > > 2, make sure your program code don't have memory leak. make sure your > program code will release dialog, tsx, tdata, rdata, timer after call > disconnected. > use pjsip_endpt_dump() to dump after your load test or real world use Definitely no memory leak in my code. I don't make any runtime allocations, and as I say, I've made sure every pj_pool_create() has a pj_pool_release(). All created dialogs, tsx, tdata, rdata are destroyed. I've been working on this for days and I can find no leaks anywhere. It only happens during a certain kind of call load (ie, random but not high speed call activity), but not if things are done orderly. When it does happen, the memory use climbs steadily and eventually leads to a crash when allocating memory for SDP. I'll try pjsip_endpt_dump(). Maybe it will help me track down the problem! 3, When I played with pjsip-perf program, the memory will be at a level and > wouln't higher and higner if concurrent calls and cps set to a static value. > I have run 1000 cps and 48 hours at that time. pjsip-perf is 0.9.0 release > version. I can't get anywhere near 1000 cps (but the hardware is 3-4 years old). See above - when I do a normal kind of performance test, the memory usage is stable. It's only under real world load that I see the problem. Btw, I have changed pjsip_endpt_create_pool() and pjsip_endpt_release_pool() so that pools are re-used and never released. So far, I am unable to reproduce the problem, and it's looking like my theory might be correct... Although it's quite difficult to reproduce the symptoms in the first place so I need a few more days of testing to be sure. -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20090119/0c1ebe2f/attachment.html>
