[reSIProcate] [repro-devel] memory issues with repro/resip?

[Byron Campen]

	Linux doesn't reclaim memory given to a process until that memory is  
needed by some other process. So, when load drops dramatically, the  
memory is going to stay constant. Also, it takes repro 3 minutes to  
reach a memory steady-state (with Timer C enabled). If the memory  
footprint is still increasing after three minutes of constant (and  
reasonable) load, then you have probably found a leak.

	As for pinpointing memory leaks with valgrind, I have found the  
massif tool immensely useful. Just run valgrind --tool=massif ./repro  
for a little while (10 min or so) under load, and when you kill it,  
it will output a .ps and a .txt file describing the memory usage over  
time. If there is a leak, this will find it (unless it is caused by a  
threading problem, in which case the leak won't happen since valgrind  
serializes all execution).

Best regards,
Byron Campen

> Hi,
> I have downloaded the latest SVN tree and ran a simple load scenario
> against repro sending 10 INVITES /sec - each one being rejected by  
> repro
> with a 480 (I did not define a next hop). The memory used by repro  
> keeps
> growing. If I stop the load the memory is not released. If I then  
> re-run
> the same load memory grows more. Valgrind did not produce anything
> useful.
>
> Are there known issues? Any hints how this can be further  
> investigated?
> Could it be that some transaction state is not cleaned up? (Although
> stats report all 0's for TU summary)
>
> Thanks,
> Brocha
>
> _______________________________________________
> repro-devel mailing list
> repro-devel at list.resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/repro-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070326/5fe1a854/attachment.bin>