Debugging memory leaks

[Steve Simmons]

Giorgos Tzampanakis <giorgos.tzampanakis at gmail.com> wrote:

>On 2013-06-13, dieter wrote:
>
>>> ...  Anyway, my real question is how to go about debugging memory
>leak
>>> problems in Python, particularly for a long running server process
>>> written with Twisted. I'm not sure how to use heapy or guppy, and
>>> objgraph doesn't tell me enough to locate the problem.
>>
>> Analysing memory leaks is really difficult: huge amounts of data is
>> involved and usually, it is almost impossible to determine which of
>the
>> mentioned objects are leaked and which are rightfully in use.  In
>> addition, long running Python processes usually have degrading memory
>> use - due to memory fragmentation. There is nothing you can do
>against
>> this.
>>
>> Therefore: if the leak seems to be small, it may be much more
>advicable
>> to restart your process periodically (during times where a restart
>does
>> not hurt much) rather than try to find (and fix) the leaks. Only when
>> the leak is large enough that it would force you to too frequent
>> restarts, a deeper analysis may be advicable (large leaks are easier
>to
>> locate as well).
>
>
>Am I the only one who thinks this is terrible advice?
>
>-- 
>Real (i.e. statistical) tennis and snooker player rankings and ratings:
>http://www.statsfair.com/ 
>-- 
>http://mail.python.org/mailman/listinfo/python-list

No you are not alone.  Ignoring a bug is only sensible if you absolutely understand what is going wrong - and by the time you understand the problem that well, you probably have enough understanding to fix it.  If tools are available (as the OP knows), then learn them and use them to find/fix the bug. 
Steve S

Sent from a Galaxy far far away
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20130613/589e2ab2/attachment.html>