[Py-MAD] Propuesta de charla: memory leaks

[lasizoillo]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.es.python.org/pipermail/madrid/attachments/20131127/6e6bba23/attachment-0001.html>