PDF de programación - Mejorando la Performance en Sistemas Linux/Unix

Mejorando la Performance en Sistemas Linux/Unix

Diego Bravo E.

9 de Octubre de 2005

Tabla de contenidos

1. Introducción................................................................................................................2
2. Higiene.........................................................................................................................2
3. Configuración de la Memoria RAM.......................................................................4
4. Análisis CPU-I/O .......................................................................................................7
A. Ejercitador de memoria..........................................................................................13

Se proporciona una metodología práctica para mejorar la performance de sis-
temas Linux, la cual puede ser aplicable a variantes Unix.
Cualquier sugestión o corrección, favor escribir a diego_bravo_estrada at yahoo dot
com1.

1. Introducción

Este es un texto breve con algunas sugestiones acerca de cómo mejorar la perfor-
mance de un sistema Linux (o Unix.) No pretende cubrir el material que se detalla
en los libros correspondientes, sino tan solo ser una primera aproximación para
quien tiene interés en el particular y desea una explicación rápida.
Se propone la siguiente metodología secuencial para mejorar la performance:

1. Eliminar los factores negativos que deterioran la performance (higiene)
2. Analizar y reconfigurar la memoria de ser necesario
3. Analizar y reconfigurar la relación %CPU vs %I/O

1.1. Autoría y Copyright

documento

tiene

(c)

copyright

2006 Diego

Este
Estrada
<diegobravoestrada en hotmail>. Se otorga permiso para copiar, distribuir y/o
modificar este documento bajo los términos de la "GNU Free Documentation
License, Version 1.2", excepto en lo mencionado en el siguiente párrafo. Esta
licencia puede obtenerse en: http://www.gnu.org/licenses/fdl.txt
Si se desea crear un trabajo derivado o publicar este documento para cualquier
propósito, apreciaría que se me contacte primero a fin de tener la oportunidad de
proporcionar una versión más reciente. De no ser esto posible, la última versión
debería estar disponible en el sitio web GatoGringo.com.3

Bravo

2. Higiene

Asumiendo que nuestro sistema puede mejorar su performance (en la mayoría
ocurre así), lo primero es corregir ciertos problemas típicos. En particular:

• Eliminar procesos "pesados" inútiles
• Re-escribir procesos "pesados" útiles

Llamaremos "pesado" a un proceso que torna lento al sistema. Esto ocurre co-
munmente porque aquél consume muchos recursos de procesamiento (mucho
CPU) o consume mucha memoria.

2.1. Consumo excesivo de CPU de un proceso
Muchas veces un proceso que está fuera de control (por un error en su progra-
mación) entra en loops ilimitados que consumen inutilmente el CPU; en otros
casos, esto ocurre de manera "normal" durante la ejecución de un proceso fre-
cuente4. Más allá de analizar el por qué ocurre esto (que es más responsabilidad
del programador), preocupémonos por detectarlo. Para esto, la manera más sen-
cilla quizá sea emplear el comando:

# ps axu

(Consúltese el manual de ps para una explicación de sus opciones.) En particular,
estamos interesados en la columna que reza "%CPU". Esta columna proporciona
2

Mejorando la Performance en Sistemas Linux/Unix

el porcentaje que representa el tiempo de CPU consumido por el proceso respecto
al tiempo total de su ejecución.
El siguiente programa se ejecuta durante 20 segundos. Los 10 primeros el pro-
ceso no consume CPU, y luego inicia un loop sin descanso hasta que transcurran
otros 10 segundos. Más abajo se muestra el monitoreo del mismo en diversos
momentos para un sistema sin carga:

#include <stdio.h>
#include <unistd.h>
#include <time.h>

#define DELAY 10

main()
{
volatile int z;
time_t t;

/* dormir DELAY segundos */
sleep(DELAY);

/* loop infinito durante DELAY segundos */
t=time(NULL);
for(z=0;;z++)
if(time(NULL)>=t+DELAY)
break;
return 0;
}

Ejemplo de uso5:

PID %CPU %MEM

$ ./sleep_and_run &
[1] 1194
$ ps axu|head -1
USER
$ ps axu|grep sleep_and_ru[n]
diego 1141 0.0 0.0
$ ps axu|grep sleep_and_ru[n]
diego 1141 0.0 0.0
$ ps axu|grep sleep_and_ru[n]
diego 1141 31.6 0.0
$ ps axu|grep sleep_and_ru[n]
diego 1141 49.8 0.0
$ ps axu|grep sleep_and_ru[n]
diego 1141 51.2 0.0
$ ps axu|grep sleep_and_ru[n]
$

1376

1376

1376

VSZ

1376

1376

RSS STAT START

TIME COMMAND

252 S

22:01

0:00 ./sleep_and_run

252 S

22:01

0:00 ./sleep_and_run

256 R

22:01

0:02 ./sleep_and_run

256 R

22:02

0:05 ./sleep_and_run

256 R

22:01

0:06 ./sleep_and_run

Como se aprecia, la columna %CPU empieza a crecer tras unos momentos hasta
alcanzar un valor significativo (51.2%.)
Lamentablemente, este procedimiento no detecta los procesos que de pronto
salen de control si éstos ya se han venido ejecutando durante mucho tiempo
manteniendo un consumo moderado de CPU (pues en ese caso el %CPU tardará
mucho en hacerse significativo.)6
Afortunadamente, existe otra forma muy sencilla de analizar este caso, y consiste
en verificar la columna TIME del proceso en diversos momentos. Si se aprecia el
ejemplo anterior, se observa que la columna TIME se mantiene estable (en este
caso, con 0:00) durante los primeros momentos, y luego rápidamente se incre-
menta. Esto es un indicativo claro de que el proceso está consumiendo mucho de
nuestro CPU.
En este punto, el administrador deberá matar inmediatamente al proceso, si éste
resulta ser inútil. En cambio, si el proceso cumple alguna función de utilidad en el
sistema, se deberá esperar un tiempo prudencial para que vuelva a la normalidad
(deje de consumir tanto CPU) o para que termine.

3

Mejorando la Performance en Sistemas Linux/Unix

2.2. Consumo excesivo de Memoria de un proceso
A veces asociado con lo anterior, los procesos pueden consumir demasiada
memoria por distintos motivos:

• Errores de programación, especialmente al no liberar los objetos
• La memoria física es insuficiente para la cantidad de información que se re-

quiere utilizar

Una manera rápida de saber si el sistema en su conjunto tiene carencia de memo-
ria física consiste en analizar las columnas ’si’ y ’so’ bajo ’--swap--’7:

$ vmstat 2
procs -----------memory---------- ---swap-- -----io----
bo
9
4
0

buff
0 321408 11960
0 321424 11960
0 321424 11960

cache
95300
95300
95300

r b
0 0
0 0
0 0

swpd

free

si
0
0
0

so
0
0
0

bi
36
0
0

Si los valores en las columnas mencionadas son cero (quizá con pequeñas excep-
ciones esporádicas), quiere decir que el sistema tiene suficiente memoria física
para los requerimientos DE ESTE MOMENTO. Por lo tanto, el administrador
hará bien en analizar la salidad de vmstat en diferentes momentos del día, o
cuando se ejecutan los procesos cuya lentitud nos preocupa más.
Con el fin de analizar la memoria consumida por los procesos, podemos
referirnos a las columnas %MEM y RSS de la salida nuestro conocido ’ps axu’, que
son equivalentes. RSS corresponde a la memoria que el sistema operativo ha
otorgado para el proceso, el cual se presenta como porcentaje respecto al total en
%MEM.
Siguiendo la idea, es una buena idea analizar qué procesos consumen mucha
memoria y desactivarlos si no son imprescindibles. Más abajo se explica con de-
talle qué se puede hacer si tenemos un sistema con carencia de memoria en el que
no podemos desactivar los procesos culpables.

2.3. Re-escritura de procesos pesados
No pretendo entrar al tópico de optimizar la ejecución de los programas. En mi
opinión, los buenos programadores casi siempre pueden optimizar la ejecución
de sus programas para que consuman menos CPU o Memoria, aunque no es una
tarea trivial que conlleve poco tiempo. El problema aquí no es técnico, sino de
"gerencia": el programador suele ser obligado a liberar una versión operativa que
rápidamente pasa a producción, y luego se le reasigna a otra actividad sin darle
tiempo para (ni obligarle a) que la optimice. Los jefes de IT se sorprenderían
gratamente si asignaran a sus buenos programadores exclusivamente a optimizar
las aplicaciones por algunos días.
Un aspecto imprescindible de resaltar porque resulta evidente, es el consumo
excesivo de recursos que hacen los programas desarrollados en lenguajes tipo
scripting como el Shell. Si bien es cierto que programar en el Shell (o similares)
tiene múltiples ventajas, se debe tener en cuenta que una aplicación equivalente
reescrita en lenguaje C suele ser de 10 a mil veces más veloz, y por tanto mucho
menos derrochadora de CPU y Memoria.
El shell tiene su lugar para diversas tareas administrativas y para prototipado
de cierta clase de aplicaciones, pero rara vez debería constituirse en el lenguaje
de una aplicación principal. Como se sabe, muchas veces ocurre que la falta de
tiempo o la desidia hace que la gente utilice el prototipo y postergue (para siem-
pre) el desarrollo "en serio".

4

3. Configuración de la Memoria RAM

Mejorando la Performance en Sistemas Linux/Unix

Como se indicó en la introducción, una vez que se ha aplicado las normas de
"higiene" en el sistema, tenemos dos posibilidades para mejorar aún más su per-
formance: la configuración de la memoria y la repartición CPU-I/O. Aunque am-
bos análisis se pueden hacer en paralelo, es muy conveniente hacerlos secuen-
cialmente a fin de cuantificar separadamente el impacto y simplificar las obser-
vaciones. Asimismo, es bastante recomendable empezar con la configuración de
la memoria, dado que las soluciones por este concepto son más sencillas y menos
costosas que en lo concerniente a la repartición CPU-I/O.

3.1. Sistemas sin carencia de memoria
Algunos sistemas nunca tienen absolutamente ninguna carencia de memoria.
Una forma sencilla de determinar esta situación es observando si han hecho uso
del swap. Como se aprecia en el ejemplo, el swap (en este caso de aproximada-
mente 1200 megabytes) no tiene uso HASTA ESTE MOMENTO, lo que significa
que el sistema todavía no ha tenido que recurrir al él por falta de memoria:

sys1$ /sbin/swapon -s