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