[Py-MAD] Propuesta de charla: memory leaks

Wed Nov 27 10:09:47 CET 2013

Jesús,

  ¿Tiene algún tipo de relación con peticiones o demás? Un truco que usan
los servidores web, que es utilísimo (hay que configurarlo, claro), es el
reiniciar cada uno de los trabajadores pasados X número de peticiones. Así,
si hay alguna fuga de memoria, no llega a desmadrarse, y, sobre todo,
minimizas o eliminas el problema si está en producción y tienes que
dedicarte  mirar por donde pierdes memoria, que suele ser bastante largo.

  Puedes monitorizar la memoria que usa el proceso y, si pasa de X (o si
es, p.ej. mayor que el doble que la que tenía cuando empezó), pues provocas
un reinicio. Y al menos no tienes que estar preocupado con eso.
  Otra posibilidad es reiniciar con un cron, que igual es más sencillo,
pero ahí dependes de saber controlar bien cuándo debe hacerse.

  Vale, es poner un parche y no es "la solución", pero por lo menos hace
que te puedas tomar con tranquilidad el buscar el problema... Hemos tenido
nosotros recientemente un problema del estilo y pudimos minimizar el
impacto que tenía, sobre todo el coste de estar echando un ojo a las
gráficas de memoria de los servidores y pedirle a la gente de operaciones
que reiniciase todo de vez en cuando...

    Jaime

---
Check my blog!
http://wrongsideofmemphis.wordpress.com

2013/11/27 lasizoillo <lasizoillo at gmail.com>

> Para el tipo 2 de memory leaks veo totalmente posible el formato taller.
> Todo el mundo quiere conocer la solución, pero nadie tiene una forma
> explicable de llevar a cabo la tarea -> aprendizaje colectivo.
>
>
> El 27 de noviembre de 2013 01:44, Jesus Cea <jcea at jcea.es> escribió:
>
> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 26/11/13 19:05, lasizoillo wrote:
>> > Aunque igual el tema del memory leak es más amplio y se quiere
>> > hablar de hacer un perfilado de uso de memoria en partes de código.
>> > Que no sería un memory leak, pero te deja hecha mierda* la ram
>> > igualmente. ¿Entraría esto también como tema de la charla o sería
>> > este el objetivo de la charla? Pregunto porque soy un poco empanado
>> > y no muchas veces no me entero de qué estamos hablando.
>>
>> Yo veo dos tipos de "memory leak":
>>
>> 1. Memoria que queda inaccesible por algún bug en una extensión. Osea,
>> una extensión que hace "malloc" o similar y se pierde su referencia,
>> así que esa memoria "desaparece". Este es el caso que comenta
>> Lasizoillo. Entiendo que este caso es "fácil" (puf), si se cuenta con
>> la herramienta apropiada. valgrind ayuda, o se puede abusar un poco de
>> DTrace. En Python puro no debería ocurrir, pero una extensión puede
>> tener bugs.
>>
>> 2. Una función crea objetos que no se liberan en ningún sitio, porque
>> "alguien" mantiene una referencia a ella. Técnicamente esa memoria es
>> "liberable" si se localiza y se rompe esa referencia. El problema es
>> identificar qué objetos son los que nos están causando problemas.
>> Sobre todo cuando son builtins, porque una cosa es ver que el número
>> de objetos "persona" crece sin cesar y otra vez que lo que crecen son
>> "str". En el primer caso normalmente está claro quien crea estos
>> objetos, mientras que los segundos se crean por todas partes.
>> Distinguir los verdaderamente "leak" de los que no son, dónde se
>> generan y QUIEN TIENE LA RESPONSABILIDAD de liberarlos, es complicado.
>> A veces es muy fácil, otras veces es difícil, y otras es la búsqueda
>> de una aguja en un millón de pajares.
>>
>> Un ejemplo de problema de este tipo es una función que usa un mogollón
>> de memoria, que se queda "enganchada" si se levanta una excepción y no
>> aparece por ningún sitio ni se libera hasta que salta otra excepción
>> en algún otro sitio, o se hace un "sys.exc_clear()".
>>
>> Otro caso de "memory leak":
>>
>> """
>> def a(x,defecto={}) :
>>    defecto[x]="Lo necesitamos para otras cosas"
>>    (aquí un montón de operaciones)
>> """
>>
>> Para esto no hay herramientas que vayan más allá de dejarte navegar
>> por el grafo de objetos, que puede ser enorme. Yo suelo usar un
>> decorador que me da la memoria usada antes y después de llamar a una
>> función, para ir acotando el problema. Pero a veces no es "tan fácil",
>> si quien genera los objetos y quien debe destruirlos son responsables
>> diferentes.
>>
>> En fin, es un tema largo y con muchos flecos, y no quiero dar la
>> charla por aquí :-).
>>
>> Por ejemplo, ahora mismo me enfrento a un programa complicado que está
>> "perdiendo" 90 MB de memoria al día. No parece mucho hasta que os digo
>> que ese programa funciona en una raspberri PI, y debería funcionar
>> 24x7, así que el problema es gordo. Se va progresando en la
>> investigación, pero muy muy lentamente. Ya he descartado muchísimo
>> código del programa y sus plugins. El problema está en el generador de
>> plantillas, pero no el problema no ocurre en Cheetah, sino en el
>> código que tiene alrededor. Acabará cayendo y será una gilipollez,
>> pero mientras tanto tengo que reiniciar la Raspberri cada par de días.
>>
>> - --
>> Jesús Cea Avión                         _/_/      _/_/_/        _/_/_/
>> jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
>> Twitter: @jcea                        _/_/    _/_/          _/_/_/_/_/
>> jabber / xmpp:jcea at jabber.org  _/_/  _/_/    _/_/          _/_/  _/_/
>> "Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
>> "My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
>> "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.15 (GNU/Linux)
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iQCVAwUBUpVAVJlgi5GaxT1NAQIxEgP/eqICtr6Um22huT1QnNdozs1tkmoY4Bck
>> 7QqhkgQ6zurxO4MS77Pz4Mobu47GhlbzXtni8Hh1s6TAg2WxnqpmDxKBw4NQ5LBc
>> FQ8K4/XCWsMzSM/0m3GgzjKGapYCvhDX1yksKhXaJe/lqDGlP67/0Vg/FBh6I6we
>> +xsMkLUVknI=
>> =9/7Z
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> Madrid mailing list
>> Madrid at lists.es.python.org
>> https://lists.es.python.org/listinfo/madrid
>>
>
>
> _______________________________________________
> Madrid mailing list
> Madrid at lists.es.python.org
> https://lists.es.python.org/listinfo/madrid
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.es.python.org/pipermail/madrid/attachments/20131127/0e5a88f3/attachment.html>