Para algunos SysAdmin siempre está la pregunta. ¿Cual es el punto de quiebre de nuestros servidores?, hasta donde podemos estresarlo, sin que el servidor entre en pánico.
Aunque la idea de este post no es realmente el colocar de rodillas al sistema operativo, con Stress, podemos generar tanta carga de trabajo, que hasta los pinguinos del polo norte griten Linux.
Con esta herramienta ligera y sencilla de utilizar, las grandes cargas de trabajo son fáciles de provocar.
El proceso de instalaciòn es muy sencillo en distribuciones basadas en Debian. Con solo ejecutar el comando
sudo apt-get install stress
También podemos descargarlo y proceder a compilarlo/instalarlo.
tar zxvf stress-1.0.4.tar.gz cd stress-1.0.4 ./configure make sudo make install
Antes de ejecutarlo, debemos conocer con que recursos cuenta nuestro servidor, para poder medir la prueba:
- Memoria RAM:
free -m total used free shared buffers cached Mem: 1982 594 1388 72 8 227 -/+ buffers/cache: 359 1623 Swap: 3017 938 2079
- Numero de CPU y velocidad (informacion resumida del CPU):
Modelo y Velocidad del CPU
cat /proc/cpuinfo | grep "model name"
model name : Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz
model name : Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz
Numero de Procesadores
grep processor /proc/cpuinfo | wc -l 2
Ahora ya, con esta información, podemos planear nuestra prueba de estrés, no sin antes mirar las opciones que presenta la herramienta
stress --help Usage: stress [OPTION [ARG]] ... -?, --help show this help statement --version show version statement -v, --verbose be verbose -q, --quiet be quiet -n, --dry-run show what would have been done -t, --timeout N timeout after N seconds --backoff N wait factor of N microseconds before work starts -c, --cpu N spawn N workers spinning on sqrt() -i, --io N spawn N workers spinning on sync() -m, --vm N spawn N workers spinning on malloc()/free() --vm-bytes B malloc B bytes per vm worker (default is 256MB) --vm-stride B touch a byte every B bytes (default is 4096) --vm-hang N sleep N secs before free (default none, 0 is inf) --vm-keep redirty memory instead of freeing and reallocating -d, --hdd N spawn N workers spinning on write()/unlink() --hdd-bytes B write B bytes per hdd worker (default is 1GB)
Podemos probar con los siguientes parámetros:
stress -c 4 -i 4 -m 6 --vm-bytes 256M -t 20s --verbose stress: info: [14224] dispatching hogs: 4 cpu, 4 io, 6 vm, 0 hdd stress: dbug: [14224] using backoff sleep of 42000us stress: dbug: [14224] setting timeout to 20s stress: dbug: [14224] hogcpu worker 4 [14225] forked stress: dbug: [14224] hogio worker 4 [14226] forked stress: dbug: [14224] hogvm worker 6 [14227] forked stress: dbug: [14224] using backoff sleep of 33000us
Descripcion de lo ejecutado: Se enviaron 8 procesos intensivos en cada CPU, 4 procesos de entrada y salida, y 6 procesos directos a la memoria RAM , cada uno de 256Mb , durante un tiempo de 20 segundos
Si solo queremos estresar la memoria, podemos ejecutar el comando de la siguiente manera:
stress -m 4 -t 20s
Para validar la carga del sistema, podemos combinar par de comandos en otra terminal y poder ver la carga de trabajo:
watch uptime
Mientras el que se estrese sea el server y no el BOFH. Todo bien.
Gracias por este nuevo aporte Anger!
Muy interesante colega. Lo probaré. Saludos!
Eso tengo que probarlo, un día de estos de navidad en que los servidores no estén muy saturados 😛 Aunque la pregunta del principio siempre será difícil de responder, al menos como quieren los jefes que se responda.
Pues habrá que darles el mal rato a los servidores ARM que uso para ver cómo se portan.
Gran aporte.