[pyar] Caches - Uso y desperdicio de RAM vs. CPU

Juan Pablo Scaletti juanpablo en jpscaletti.com
Lun Mar 23 11:18:14 ART 2015


Lo preguntas por curiosidad académica o por que necesitas usar un caché?

Si es lo segundo, ya es un problema resuelto: Usa Redis o Memcached (yo me inclinaría por un Redis bien configurado).

Si es lo primero, la RAM libre es lo que se mide (hasta el máximo disponible o un límite que le pongas).
El que cosa borras cuando te quedas sin memoria es el tema: Memcached usa un algoritmo simple de borrar lo que no s ha usado últimamente.
El de Redis puede tiene otras optimizaciones que puedes leer aquí: http://redis.io/topics/lru-cache <http://redis.io/topics/lru-cache>



> On Mar 23, 2015, at 8:50 AM, Andres Riancho <andres.riancho en gmail.com> wrote:
> 
> Lista,
> 
>    Ayer pensaba un rato sobre caches, uso de memoria y CPU, y más que
> nada en el potencial desperdicio de los mismos. Me gustaria saber su
> opinion sobre este tema.
> 
>    Supongamos que tengo un LRU cache en el cual almaceno en memoria
> resultados de operaciones que llevan mucho esfuerzo de CPU en
> calcular. Entonces lo que obtengo es una reducción de uso de CPU en mi
> software a costa de un uso incrementado de memoria.
> 
>    En todos los casos que vi estos caches tienen un maximo numero de
> elementos a recordar, removiendo en base a algun algoritmo uno de los
> elementos cuando se quiere guardar el proximo. Además si tengo 10 como
> numero maximo de items en el cache la mejora en mi software estará
> limitada a lo que pueda proveer ese "pequeño" cache, mientras que si
> lo incremento a 100 la mejora en CPU será incrementada (*).
> 
>    Determinar cual es el numero maximo de items en el cache parece
> ser una decision importante que afecta performance de manera directa.
> Un numero elevado y puede ser que consuma tanta RAM que el OS empiece
> a utilizar swap y todo pase a ser mas lento, un numero reducido y el
> cache puede ser totalmente inutil. O si se setea un numero intermedio,
> pero el software se ejecuta en un servidor con 16GB de RAM, entonces
> el cache esta desaprovechando recursos que bien podría consumir.
> 
>    Despues de tanta introducción mis preguntas son:
> 
>        - Tiene sentido controlar el tamaño del cache en base a los
> recursos disponibles en el sistema? Como medirían los mismos? Medirían
> % RAM libre? Quizás con el modulo psutil?
> 
>        - Reducir el tamaño del cache puede prevenir el uso de swap,
> lo que sería beneficioso en casos donde el software se ejecuta en
> entornos con recursos reducidos, correcto?
> 
>        - Incrementar el tamaño del cache cuando existen recursos
> disponibles hara que el software utilice más memoria. Un usuario que
> monitoree el proceso podría facilmente creer que tiene un memory leak,
> o que es muy "agresivo" en cuanto al uso de RAM. Quizás en este caso
> deberia haber documentación/configuración por parte del usuario del
> máximo hasta donde puede crecer?
> 
>    Gracias!
> 
> (*) No siempre, depende de que se guarda, como se usa lo que se guarda, etc.
> 
> PD: Como seguramente saben esta pregunta esta relacionada con w3af ,
> pero la hago de manera generica porque aplica a muchos otros casos
> tambien. En w3af el codigo relacionado con la pregunta esta en
> parser_cache.py [0]
> 
> [0] https://github.com/andresriancho/w3af/blob/master/w3af/core/data/parsers/parser_cache.py
> 
> Saludos,
> -- 
> Andrés Riancho
> Project Leader at w3af - http://w3af.org/
> Web Application Attack and Audit Framework
> Twitter: @w3af
> GPG: 0x93C344F3
> _______________________________________________
> pyar mailing list pyar en python.org.ar
> http://listas.python.org.ar/listinfo/pyar
> 
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
> 
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de Argentina - http://www.usla.org.ar

------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20150323/c90cb72c/attachment-0001.html>


More information about the pyar mailing list