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

[Alejandro Santos]

Todo gira en torno a una única idea: en general no podés predecir cuál
es el siguiente elemento a buscar en una caché (*). El peor caso de
cualquier caché es que el siguiente elemento que sacás de la caché
(para hacerle espacio a uno nuevo) sea el que vas a necesitar en el
siguiente pedido.

La solución de ingeniería es de poner todo lo que puedas en la RAM,
cruzar los dedos y prender velitas.

La heurística más popular suele ser "Locality of reference", que es la
idea que es más probable acceder a elementos que están "cerca" que
"lejos", donde "cerca" y "lejos" dependen de tu problema. Por ejemplo
si estás leyendo una matriz de números en RAM y los elementos están
físicamente distribuidos por filas, leer la matriz por filas es más
rápido que por columnas, porque el siguiente elemento es muy probable
que esté en caché de la CPU.

Pero a veces (y esto es cada vez más cierto) es más eficiente
recalcular una respuesta que leerla de una caché. El ejemplo más tonto
es sumar dos números enteros de 32 bits, es mucho más rapido pedirle a
la CPU la respuesta que guardarlos en RAM y leerlos cada vez que lo
necesitás.



(*) Si lo resolvés te ganás el Premio Turning, un millón de dólares, etc..



2015-03-23 14:50 GMT+01:00 Andres Riancho <andres.riancho en gmail.com>:
> 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



-- 
Alejandro Santos