Roger Jordan Blog

3.- La memoria.

Hoy en día los servidores cuentan con gigas y gigas de RAM, comparado con hace unos años su coste se ha abaratado sustancialmente. En mi humilde opinión esto no ha repercutido en una mejora sustancial del rendimiento, ya que las aplicaciones actuales son auténticas devoradoras de recursos. Debido a esto no es extraño encontrarse en una situación donde la memoria física se haya terminado y el sistema se vea forzado a swapear.

Nuestro objetivo

Como suele ser habitual una pérdida de performance debido a escasez de memoria suele ser debido a que una aplicación se ha salido de su patrón de carga habitual. Así deberemos centrar nuestro análisis en localizar el/los pid/s responsables.

Reconociendo el estado de falta de memoria.

El Usuario

En general percibirá una perdida de velocidad en sus aplicaciones, en casos realmente extremos puede ser que no pueda lanzar nuevos comandos y obtenga un mensaje indicando que no hay memoria suficiente para hacer un fork.

Los síntomas

Prtconf

Un primer paso sencillo es ver la cantidad de memoria física que hay instalada en el sistema, para ello usaremos el comando #prtconf.

root@box # prtconf | more System Configuration: Sun Microsystems sun4u Memory size: 32768 Megabytes

Vmstat

La columna sr de la salida del vmstat indica el número de veces que se ha ejecutado el page scanner durante la muestra.

El proceso se activa cuando queda menos de 1/64 de la memoria física libre disponible, es decir, cualquier valor superior a 0 significa que andamos francamente escasos de memoria, si el valor es sostenido durante varias muestras implica que la situación es realmente grave. La ejecución del page scanner supone un gasto notable de CPU por lo que en casos realmente extremos puede ser que el equipo esté prácticamente dedicando todos sus recursos a liberar memoria.

La columna free es el total de memoria libre disponible, se obtiene de la suma de la Free (cachelist) y la Free (freelist).

root@box # vmstat 5 kthr memory page disk faults cpu r b w swap free re mf pi po fr de sr 2m m0 m1 m2 in sy cs us sy id 1 0 0 42157120 7573496 585 2219 1920 7 9 0 6 44 2 1 1 19612 34991 12905 42 15 43 0 0 0 41882080 7348816 546 2233 2175 0 0 0 0 35 0 0 0 12435 29385 6561 32 9 59 0 0 0 41882512 7344728 584 2393 2162 0 0 0 0 36 20 19 19 10922 32580 7231 28 9 63 0 0 0 41884936 7342656 628 2809 2174 0 0 0 0 35 0 0 0 11673 43611 8204 31 9 60 [...]

mdb

Con mdb podemos obtener una estadística de la memoria según el uso que se la esté dando:

root@box # mdb -k Loading modules: [ unix krtld genunix dtrace specfs ufs ssd fcp fctl ipc md ip s ctp usba random emlxs nca ptm sd nfs sppp crypto logindmux cpc fcip isp ] ::memstat Page Summary Pages MB %Tot ------------ ---------------- ---------------- ---- Kernel 371610 2903 9% Anon 2406527 18800 58% Exec and libs 22685 177 1% Page cache 460896 3600 11% Free (cachelist) 811777 6342 19% Free (freelist) 105288 822 3% Total 4178783 32646 Physical 4111653 32122

El total de memoria libre disponible es la suma de la Free (cachelist) y la Free (freelist). Este valor es le que presenta la columna free del vmstat.

La Free (freelist) es la memoria libre que nunca ha sido usada.
La Free (cachelist) es memoria que ha sido usada y aun contiene datos validos pero en caso de necesidad pueden ser sobrescritos, de esta manera si los mismos datos son necesitados antes de haber sido sobrescritos no hace falta volverlos a traer a la memoria fisica.

Quien está consumiendo toda la memoria.

Hay que tener en cuenta que el proceso que más ocupa en memoria no tiene porque ser el que esté creando el problema si su tamaño se mantiene constante.

Pongamos un ejemplo tonto, En nuestro sistema tenemos un total de 8 gigas, tenemos 3 procesos, A consume 3G, B 3G y C 1G. Si el proceso C tiene un funcionamiento anómalo y su consumo se dispara su tamaño máximo será de 2 G, es decir seguirá siendo el más pequeño pero sin embargo será el responsable de los problemas de performance.

Prstat

La salida del prstat nos indica el tamaño de cada proceso en memoria, sin embargo es engañoso. Si varios procesos utilizan las mismas libreri´as, ejecutables, etc solo hay una copia cargada en memoria, sin embargo se tienen en cuenta al mostrar el tamaño total que ocupa el proceso.

root@box # prtconf | more System Configuration: Sun Microsystems sun4u Memory size: 32768 Megabytes root@box # prstat PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 16197 oracle 16G 16G cpu1 20 0 11:41:50 6,9% oracle/15 4209 oracle 16G 16G cpu16 10 0 0:58:48 6,3% oracle/11 27821 oracle 16G 16G sleep 10 0 0:06:32 4,0% oracle/1 15582 oracle 16G 16G cpu0 0 0 0:00:09 3,9% oracle/1 28194 oracle 16G 16G cpu2 33 0 11:27:39 2,1% oracle/13 9776 oracle 16G 16G sleep 59 0 5:39:50 1,8% oracle/13 [...]

Si sumamos el tamaño de todos los procesos oracle nos da un valor superior a la memoria instalada en el equipo. Por ello el prstat NO es una buena herramienta para determinar que proceso es el responsable del agotamiento de la memoria.

Dtrace

Un buen indicativo de consumo de memoria es el número de minor faults que está generando un proceso, un número de minor faults indica que el proceso está reclamando más memoria.

Para localizar estos procesos tenemos que hechar mano de dtrace, por suerte podemos usar los scripts del Dtrace Tool Kit que nos simplificará la vida. En concreto el script minfbypid.d.

root@box # ./minfbypid.d Tracing... Hit Ctrl-C to end. ^C PID CMD MINFAULTS 7313 oracle 2 13591 sleep 2 [...] 13626 init.cssd 86 4209 oracle 364

Conclusión

Después de estas comprobaciones deberemos tener claro si tenemos problemas de memoria y en este caso una pequeña lista de pid que merece la atención analizar detenidamente, en artículos posteriores veremos como hacer un análisis detallado de estos procesos.

Por favor envía cualquier comentario a roger.jordan gmail com