[Py-MAD] Charla diciembre 2013: "Técnicas y herramientas para diagnosticar y solucionar 'memory leaks'"

piranna at gmail.com piranna at gmail.com
Thu Apr 3 20:29:13 CEST 2014


esta claro que hacerlo para todo es una locura precisamente por lo que
comentas, pero para los objetos python (al menos los puros) seria posible,
al fin y al cabo se localizan por su id dentro de un hash global gigante,
¿no? basicamente mi idea era que cada acceso a dicho hash se sacara de
disco si no esta y se actualizara en disco si se escribe. En un sistema
asi, excepto el runtime en C el resto podria recuperarse todo. ¿Me explico?

Send from my Samsung Galaxy Note II
El 03/04/2014 20:19, "Jesus Cea" <jcea at jcea.es> escribió:

> On 03/04/14 11:27, piranna at gmail.com wrote:
> > "PEP 445: Add new APIs to customize Python memory allocators"
> >
> > ¿Puedo definir como y donde se generan y administran los objetos
> > generados en Python? Llevo tiempo queriendo hacerme un sistema en el
> > que los objetos se guardan directamente a disco duro (algo a mitad de
> > camino entre una swap y una cache de disco, pero a nivel de objetos y
> > para toda la aplicacion de forma que se pueda continuar por donde se
> > dejo) pero siempre me he encontrado con el problema de que tendria que
> > implementarlo a nivel de malloc... :-/
>
> Lee el RFC. Se implementa a nivel de malloc.
>
> Para hacer lo que dices, yo te recomendaría un sistema de persistencia
> tipo DURUS o ZODB. Si quieres hacerlo 100% transparente, para todos los
> objetos, te vas a cagar, porque si bien puedes volcar bloques directos
> de memoria a disco, éstos contienen punteros. Punteros que tendrás que
> reescribir al cargar los datos, o forzar a que se carguen en la misma
> posición.
>
> Una opción sería implementar la memoria como un MMAP gigante (en
> sistemas 64 bits) y mapearla en una posición fija.
>
> De todas formas siempre tendrás objetos que no puedes persistir, como
> descriptores de ficheros, sockets...
>
> >
> > 2014-04-03 4:26 GMT+02:00 Jesus Cea <jcea at jcea.es>:
> >> http://www.jcea.es/artic/memory_leak/
> >>
> >> --
> >> 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
> >> _______________________________________________
> >> Madrid mailing list
> >> Madrid at lists.es.python.org
> >> https://lists.es.python.org/listinfo/madrid
> >
> >
> >
>
> --
> 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
>
>
> _______________________________________________
> 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/20140403/e19f3625/attachment.html>


More information about the Madrid mailing list