Introduccion — Que es un prueba de Stress ?
Las pruebas de stress, son aquellas pruebas que tratan de probar o visualizar el comportamiento de un sistema gnu/linux bajo condiciones demandantes. Las pruebas de stress sobre un periodo de tiempo, permitiran darnos la confianza que realmente estamos comparando manzanas con manzanas y naranjas con naranjas.
Pero cual es la metodologia a seguir para llevar a cabo una prueba de stress sobre sistemas gnu/Linux?.
Metodologia — Evaluacion de la utilizacion de los recursos del sistema
La seleccion de pruebas adecuadas puede stresar los recursos del sistema. Cuatro areas principales del sistema gnu/Linux afectaran la respuesta y tiempo de ejecucion:
* CPU: Tiempo consumido en el procesado de daatos sobre el o los CPU(s) de una maquina.
* Memory: Tiempo consumido en lectura y escritura para y proveniente de la memoria real.
* I/O: Tiempo consumido en lectura y escritura para y proveniente de la unidad de almacenamiento.
* Networking: Tiempo consumido en lectura y escritura para y proveniente de la red.
Metodologia — Las Herramientas de los Testers
Los diseñadores de pruebas deberan conocer muy bien las siguientes dos herramientas, ya que les permitiran evaluar los niveles de utilizacion de los recursos del sistema.
* top: Una herramienta open source, cuyo proyecto es lidereado por Albert D. Cahalan, herramienta que por lo general esta incluida en la mayoria de las distribuciones linux sobre los kernels 2.4.X y 2.6.X.
* sar: Otra herramienta open source; la cual es lidereada por Sebastien Godard. Esta herramienta es tambien incluida en la mayoria de las distribuciones Linux y trabaja sobre los kernels 2.4.X y 2.6.X.
* stress: Generador de carga de trabajo (workload) para sistemas POSIX. Cargara de trabajo a la CPU(s), memoria, discos. Programa escrito en ensamblador bajo la licencia GPL.
Para evaluar la utilizacion de los recursos del sistema, se requerira multiples pruebas combinadas, que puedan alcanzar el nivel de utilizacion deseado. La Sobre-Utilizacion es siempre un objetivo de las pruebas que se aplicaran. Haciendo referencia a esto, podriamos tener el siguiente caso, escoger una combinacion de pruebas con bastante I/O que pueda llevar a la o los CPU(s) ha tener un rendimiento pobre y vice versa.
Metodologia — Las Herramientas de los Testers — Diferencias entre sar y top
La herramienta top es muy usada para determinar rapidamente cuales recursos (CPU, memory, o I/O) afecta cada prueba y que proporcion de estos es utlizada en el preciso momento en que se ejecuta la prueba. En cambio la herramienta sar es usada para la recoleccion de datos estadisticos de la utilizacion de red y tambien registrara los estados(snapshots) de la utilizacion total del sistema en cierto periodo de tiempo.
Una vez que has seleccionado una combinacion de pruebas a correr sobre tu gnu/linux, una prueba debera de ejecutarce durante cierto periodo de tiempo que sea adecuado para la evaluacion de la utilizacion del recurso. El monto de tiempo que la prueba corra sera algo muy particular de cada prueba. Asumiendo que multiples pruebas estan siendo executadas concurrentemente, El monto de tiempo debera de ser lo suficientemente largo para que todas esas pruebas se completen. La herramienta sar debera de estar corriendo durante este periodo de evaluacion. Mientras las pruebas corren sar se mantendra recolectando todos los niveles de utilizacion de todos los recursos.
El siguiente ejemplo muestra la salida referente a CPU, memoria, y utilizacion de red:
10:48:27 CPU %user %nice %system %iowait %idle 10:48:28 all 0.00 0.00 0.00 0.00 100.00 10:48:29 all 3.00 0.00 1.00 0.00 96.00 10:48:30 all 100.00 0.00 0.00 0.00 0.00 10:48:31 all 100.00 0.00 0.00 0.00 0.00 02:27:31 kbmemfree kbmemused %memused kbswpfree kbswpused %swpused 02:29:31 200948 53228 20.94 530104 0 0.00 02:31:31 199136 55040 21.65 530104 0 0.00 02:33:31 198824 55352 21.78 530104 0 0.00 02:35:31 199200 54976 21.63 530104 0 0.00 02:27:31 IFACE rxpck/s txpck/s rxbyt/s txbyt/s 02:29:31 eth0 738.79 741.66 76025.55 136941.85 02:31:31 eth0 743.30 744.97 76038.82 136907.77 02:33:31 eth0 744.80 745.02 76135.53 136901.38 02:35:31 eth0 742.35 744.34 75947.45 136864.77
Metodologia — Las Herramientas de los Testers — Recopilar datos sobre el rendimiento con sar
El programa que se ocupa de recopilar la informacion se llama sadc (system activity data collector o recolector de datos de la actividad del sistema). Obtiene su informacion, principalmente del kernel, a traves del sistema de archivos virtual en /proc. Despues guarda los datos sobre un archivo (uno por dia en /var/log/sa/sarDD, donde DD hace referencia al dia del mes). sar tambien inclulle 2 scripts que se ejecutaran con cron:
* sa1: recopila datos de forma regular.
* sa2: utlizado para crear los informes sintetizados
Un ejemplo de estos script sobre la tabla cron:
# Ejecuta la herramienta de recopilacion de datos cada 10 minutos */10 * * * * root /usr/lib/sa/sa1 1 1 # Genera un informe diario del rendimiento de los procesos a la 23:59 59 23 * * * root /usr/lib/sa/sa2 -A
Metodologia — Las Herramientas de los Testers — Creando informes para medir el rendimiento del sistema
Si los informes diarios creados por el script sa2 no son suficientes, puedes crear los tuyos propios utilizando sar. Por defecto este programa obtiene la informacion del archivo de datos del dia actual, a menos que se especifique lo contrario. Para hacer que sar obtenga los datos de un archivo en particular, utilizamos la bandera -f /var/log/sa/saDD. Puedes seleccionar multiples archivos usando varias banderas -f. Dado que muchos de los informes que crea sar tienen un tamaño considerable, puede que quieras redirigir la salida a un archivo.
Para crear un informe basico que muestre el uso de CPU y el porcentaje de tiempo gastado esperando E/S, ejecutamos sar sin ningun argumento:
01:10:00 PM CPU %user %nice %system %iowait %idle 01:20:00 PM all 7.78 0.00 3.34 20.94 67.94 01:30:00 PM all 0.75 0.00 0.46 1.71 97.08 01:40:00 PM all 0.65 0.00 0.48 1.63 97.23 01:50:00 PM all 0.96 0.00 0.74 2.10 96.19 02:00:00 PM all 0.58 0.00 0.54 1.87 97.01 02:10:00 PM all 0.80 0.00 0.60 1.27 97.33 02:20:01 PM all 0.52 0.00 0.37 1.17 97.94 02:30:00 PM all 0.49 0.00 0.27 1.18 98.06 Average: all 1.85 0.00 0.44 2.56 95.14
* Si %idle (desocupado) esta cerca de cero, la CPU entonces esta sobrecargada.
* Si el valor %iowait(espera por e/s) es grande, tus discos estan sobrecargados.
Para comprobar como se comporta el fichero de paginacion, ejecuta sar -B para obtener un informe similar al siguiente:
11:00:00 AM pgpgin/s pgpgout/s fault/s majflt/s 11:10:00 AM 8.90 34.08 0.00 0.00 11:20:00 AM 2.65 26.63 0.00 0.00 11:30:00 AM 1.91 34.92 0.00 0.00 11:40:01 AM 0.26 36.78 0.00 0.00 11:50:00 AM 0.53 32.94 0.00 0.00 12:00:00 PM 0.17 30.70 0.00 0.00 12:10:00 PM 1.22 27.89 0.00 0.00 12:20:00 PM 4.11 133.48 0.00 0.00 12:30:00 PM 0.41 31.31 0.00 0.00 Average: 130.91 27.04 0.00 0.00
Puede que el número de veces que se ha tenido que recurrir a la paginación no sea determinante, pero el que exista un alto número de fallos mayores de página (majflt/s) indica que el sistema necesita más memoria.
Para obtener estadísticas de red, utilizamos sar -n DEV. Este comando genera un informe que muestra estadísticas con los datos transmitidos y recibidos para cada interfaz de red. Veamos una versión abreviada de este informe:
11:00:00 AM IFACE rxpck/s txpck/s rxbyt/s txbyt/s 11:10:00 AM lo 0.62 0.62 35.03 35.03 11:10:00 AM eth0 29.16 36.71 4159.66 34309.79 11:10:00 AM eth1 0.00 0.00 0.00 0.00 11:20:00 AM lo 0.29 0.29 15.85 15.85 11:20:00 AM eth0 25.52 32.08 3535.10 29638.15 11:20:00 AM eth1 0.00 0.00 0.00 0.00
Para ver los errores de red, prueba con el comando sar -n EDEV
Metodologia — Las Herramientas de los Testers — Creando informes para medir el rendimiento del sistema — Informes en tiempo real
También podemos utilizar sar para ver que está pasando en este preciso momento con un componente del sistema. Si le pasamos un intervalo de tiempo (en segundos) y el número de informes a producir, podemos obtener información inmediata sobre un posible cuello de botella.
Por ejemplo, para ver el informe básico cada segundo durante los próximos 10 segundos, usaríamos sar 1 10. Cualquiera de las combinaciones de banderas anteriores se pueden ejecutar con estos parámetros para obtener resultados cercanos al tiempo real.
Metodologia — Las Herramientas de los Testers — Recopilar datos sobre el rendimiento con sar — Fugas de rendimiento (extra topic)
Fuera del tema de las pruebas de strees en linux. Si sospechas que puede existir algun problema de rendimiento con cierto programa en particular que ya le causa bastante stress a tu sistema gnu/linux, tambien puedes utilizar sadc para recopilar datos sobre ese proceso(-x), o sus hijos(-X), pero necesitaras crear tu propio script que use estas banderas.
Incluso si contamos con potencia de sobra para correr nuestras aplicaciones, sar siempre puede ser útil para registrar cambios en el volumen de trabajo a lo largo del tiempo. Para hacer esto, guardaremos los informes (sar sólo guarda siete) en un directorio diferente durante un periodo de tiempo de unas pocas semanas o un mes. Este grupo de informes pueden servir como ejemplo del volumen de trabajo normal del sistema. Se pueden comparar los siguientes informes con estos resultados previos para ver cómo cambia el volumen de trabajo con el tiempo. Podemos incluso automatizar estos informes usando python, ruby, perl.
En la gestión de grandes sistemas, las pruebas de rendimiento son importantes para predecir qué hardware actualizar y cuándo hacerlo. También nos proporciona datos con los que justificar estas actualizaciones.
Las herramientas de los testers — Provocando stress a nuetro sistema GNU/linux
Stressar un sistema no significa que le haremos un benchmark, significa que le daremos una carga especifica para cada uno de sus subsistemas (cpu,user,nice,system,irq,softirq,iowait,idle). Los siguientes screenshots fueron realizados sobre un equipo llamado rome con 8 cpu(s).
Utilizare la herramienta top (tambien lo puedes hacer con sar si asi lo deseas) y la herramienta stress para mandarle cargas de trabajo a rome.
Las herramientas de los testers — Provocando stress a nuetro sistema GNU/linux — Carga de trabajo nula
Como ya estaras viendo en este screenshot, se muestran 2 terminales, una que espera cualquier orden especifica sobre bash y la otra ejecutando top (para visualizar el modo de multiples cpu(s) precione C en top).
Actualmente el sistema se encuentra en lo que podriamos llamar un estado muy relax. Tan solo habra que dar un vistazo a %idle cuyos niveles estan muy cerca del 100%.
Las herramientas de los testers — Provocando stress a nuetro sistema GNU/linux — Carga de trabajo para los CPU(s)
Sobre este screenshot, observa como al saturar las CPU(s) de carga, %idle se acerca cada vez mas a 0% y las CPU(s) cada vez mas al 100% de su saturacion.
Aqui la app stress es lanzado con 8 procesos sqrt(), lo que significa que ejecutaran 8 multiples ciclos infinitos de raices cuadradas.
Las herramientas de los testers — Provocando stress a nuetro sistema GNU/linux — Carga de trabajo para las llamadas al sistema
En este screenshot observa como el parametro -i 4 , introduce 4 ciclos infinitos que ejecutan la llamada al sistema sync(), generando con esto carga de trabajo para el subsistema system.
Las herramientas de los testers — Provocando stress a nuetro sistema GNU/linux — Carga de trabajo para los discos
Ejecutaremos con stress una carga de escritura de 3gb para los discos, observe como se dispara el %iowait:
Una vez finalizada la carga de trabajo, observa que en el directorio donde ejecutaste la app stress se te genero un archivo ascii producto de esta carga de trabajo realizada para el disco ( un archivo ascii de 3.0 gb ).
Las herramientas de los testers — Provocando stress a nuetro sistema GNU/linux — Mas informacion sobre la app stress
El formato para correr la aplicacion stress es la siguiente:
stress [opciones [args]] ...
stress suporta las siguientes opciones:
`-?'
`--help'
Show help information.
`--version'
Show version information.
`-v'
`--verbose'
Turn up verbosity.
`-q'
`--quiet'
Turn down verbosity.
`-n'
`--dry-run'
Show what would have been done.
`-t secs'
`--timeout secs'
Time out after secs seconds.
`--backoff usecs'
Wait for factor of usecs microseconds before starting work.
`-c forks'
`--cpu forks'
Spawn forks processes each spinning on `sqrt()'.
`-i forks'
`--io forks'
Spawn forks processes each spinning on `sync()'.
`-m forks'
`--vm forks'
Spawn forks processes each spinning on `malloc()'.
`--vm-bytes bytes'
Allocate bytes number of bytes. The default is 1.
`--vm-hang'
Instruct each vm hog process to go to sleep after allocating memory. This contrasts with their normal behavior,
which is to free the memory and reallocate ad infinitum. This is useful for simulating low memory conditions on a machine.
For example, the following command allocates 256M of RAM and holds it until killed.
% stress --vm 2 --vm-bytes 128M --vm-hang
`-d forks'
`--hdd forks'
Spawn forks processes each spinning on `write()'.
`--hdd-bytes bytes'
Write bytes number of bytes. The default is 1GB.
`--hdd-noclean'
Do not unlink file(s) to which random ASCII data is written.
Nota: Sufijos pueden ser s,m,h,d,y (para tiempo) o k,m,g (para tamaño).
Conclusiones
La cantidad de carga de trabajo que puedes asignar con la app stress, es algo muy variable, ya que la app stress al permitir combinar sus diferentes opciones de carga, te permitira la ejecucion de multiples pruebas combinadas. Y gracias a las herramientas sar y top, la medicion de recursos del sistema ya sea a modo de estadistica a intervalo de tiempo (con sar) o de informacion en el momento (con top), estaran siempre a disposicion de cualquier administrador de sistema gnu/linux.
