[Py-MAD] Propuesta de charla: memory leaks

Jesus Cea jcea at jcea.es
Wed Nov 27 01:44:04 CET 2013


-----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-----


More information about the Madrid mailing list