Saturacion de memória RAM

[David Ballester]

MUY BIEN, Mauricio, así da gusto.

Tan solo algún matiz ( FYI ) que comento entre líneas



El mié, 14-05-2008 a las 08:40 -0400, Mauricio José Adonis Carrasco
escribió:


> 1) Lo primero debes de diferenciar entre memoria residente o
> "cacheada"(termino de mi cosecha). Si haces un free en consola lo podrás
>  ver. La gestion de la memoria la hace el kernel y me creo que tu no
> puedes hacer nada. Lo ideal es tener la memoria 100% usada.Ahora bien,

Linux es muy amigable en lo que se refiere a parametrización. Como
sabrás puedes interactuar con él y modificar la forma que se comporta en
varias áreas mediante el pseu filesystem /proc. El conjunto de
algoritmos que gestiona la memoria se agrupa dentro del apartado vm
( virtual memory, unix en primera instancia 'conoce' la memoria como un
todo: RAM + SWAP, cuando hablamos de gestión de memoria tendremos en
cuenta tanto la RAM como la SWAP accesible por el kernel ) y podemos
parametrizar muchos aspectos de la gestión que realiza el kernel de la
virtual memory

un ls -l /proc/sys/vm

te dará una idea de que podemos 'tunear' respecto a la vm. Google te
informará sobre cada 'parámetro' ( ls -l /proc/sys/vm ).

> si es usada 100% como residente en tu uso habitual, significa que
> necesitas comprarte un modulo más de memoria ya que los programas que
> utilizas te lo comen todo con su uso minimo. SI la memoria está
> cacheada. No te preocupare porque el sistema ya se encargará de
> liberarla cuando nuevos procesos la pidan, digamos que es memoria usada
> para mejorar la eficiencia pero que el sistema la cachesin que sea
> necesario, mientras tanto no deberiás preocuparte.
> 

Son datos usados alguna vez y que mientras no sea necesaria la memoria
se mantienen ahí 'por si acaso' se necesitan otra vez. Se recicla el
espacio según el algoritmo LRU ( Last Recently Used, o sea, lo que hace
más tiempo que no se ha usado ). También hay que tener en cuenta que el
contenido puede quedar inválido. En resumen, hay mucha actividad tan
solo en el manejo de memoria

(...)
> 3) Básicamente, el kernel cachea en memoria todo lo que puede
> (generalmente son libs compartidas). ¿Por qué hace esto? Muy sencillo,
> lo hace porque los discos duros son un cuello de botella atroz (es la
> parte de la informática que menos ha avanzado en toda la historia de la
> informática).
> 

Depende del hardware y de la aplicación. En 'informatica doméstica' te
doy la razón, en otros escenarios no :)

Actualmente estoy trabajando con cabinas de discos de fibra y varios
gigas de RAM en la cabina como 'cache', obteniendo un ratio de lectura a
disco ( técnicamente varios discos ) por debajo del milisegundo por cada
I/O, leyendo varios Ks por I/O.

Junta eso a sistemas datawarehouse y tendrás un escenario donde nos es
más practico leer de disco procesar y desechar, en vez de mantener una
copia de lo leído en memoria

(...)
> 
> La mala noticia es que ese tamaño de datos de cada dispositivo,
> aplicación, sistema de ficheros, ... es distinto, por eso el rendimiento
> de un sistema informático es malo. ¿Se puede llegar a estandarizar? No
> poruqe por ejemplo una BBDD generalmente tendrá muchos IOPS pequeños
> mientras que una aplicación multimedia tendrá menos IOPS, pero
> escribe/lee datos en bloques muy grandes.
> 

Todo depende. 
Sistemas datawarehouse grandes lecturas en una I/O, a lo que te refieres
tu (..BBDD generalmente tendrá muchos IOPS pequeños... es al típico
acceso a dato concreto vía índice. Eso no siempre es bueno. 


> Es decir, hace falta un almacén temporal de datos. Básicamente, un
> ordenador funciona como UPS o FedEx o DHL o SEUR o cualquiera de esas
> compañías: llega un paquete, lo almacenan temporalmente en un hangar y
> cuando tienen XXX número de paquetes que van a al mismo destino ... los
> envían. El hangar sería el buffer.
> 

Se puede hacer by-pass del buffer usando dispositivos en modo caracter
( los llamados - y condenados a desaparecer - raw devices ), o
programando las aplicaciones para hacer uso de DIRECT_IO




D.