[...]KAPEJOD.ORG » Blog Archive » Mass deployment of SIP phones[...]…

What i am observing with 1.8 is that the memory usage is increasing slowly while the number of channels (and call setups) is constant. The other side is a number verification dialer which is configured to use 1000 channels and 100 call attempts per second.

I totally agree that a higher memory usage after the test does not automatically qualify as a memory leak. I do see this for my sofia-sip-based number verification dialer, too. The memory usage after the test almost stays at the level of the peak call volume, but so far it pushed 500M+ calls without the memory usage increasing.

However, I’m not sure you can classify this behavior as a ‘memory leak’. Do you have snapshots of the memory usage of the process throughout the test, after the peak simultaneous call volume was reached? If the memory usage continues to climb even if the simultaneous call volume stays the same (or drops), then that’s a leak. If the memory usage grows with the call volume and then stays relatively static as long as the call volume doesn’t increase… that’s not a leak, it’s just normal behavior. When Asterisk requests memory from the C library’s heap, the heap allocator will request memory from the kernel, and the process’ memory size will grow. If Asterisk later releases that memory, it is released back to the heap, but *never* released back to the kernel… and thus the kernel’s view of the process’ memory size stays the same, even though most of the memory is unused.

After your test is complete, and Asterisk is idle, it’s completely possible for the kernel to still think it is using 50% more memory than when Asterisk was started, even though that memory is not being actively used. In order to determine whether there is a leak or not, you’d have to inspect the amount of *heap* memory that is actually in use at that point, not how large the heap is.