Pruebas de estrés en sistemas GNU/Linux
A raíz de las vulnerabilidades detectadas en la inmensa mayoría de procesadores, ya sabéis, los casos de Meltdown y Spectre; los departamentos de sistemas estamos hasta arriba de trabajo. Una de las pruebas habituales es comparar el rendimiento de la CPU antes y después del parcheado. Una herramienta clásica de los sistemas UNIX y like-UNIX, es ‘stress’
Pruebas de estrés en GNU/Linux, OpenBSD y FreeBSD
Con la herramienta ‘stress’ podemos realizar diferentes pruebas, que generan gran carga y puede ayudarnos a revisar la salud de los equipos. Como por ejemplo el estrés de la CPU, la memoria, la entrada y salida (I/O) o del disco.
¿Cómo funciona stress?
Básicamente se encarga de crear una cantidad dada de carga a la CPU, la memoria, E / S y tensión de disco. Está escrita en C y es software libre, utiliza una licencia GPLv2
Instalación en GNU/Linux y *BSD
El primer sistema operativo donde los he probado es con CentOS 7. Para poder utilizarlo debemos tener habilitado el repositorios EPEL
yum install -y epel-release
yum install -y stress
En sistemas con paquetería APT, esto es, basados en Debian, como por ejemplo Ubuntu, ya lo tenemos disponible en los repositorios principales, sólo debemos escribir:
apt -y install stress
En lo que respecta al SUSE y OpenSUSE, también lo tenemos disponible en los repositorios principales:
zypper install stress
Si tenemos algún problema con la instalación podemos consultar este enlace.
En lo que respecta a Arch, podemos utilizar una excelente guía que me he encontrado por Internet, llamada «Stress Test«
Llegando al campo de las distros *BSD, en la primera de todas, esto es, en FreeBSD, la instalación sería como sigue:
pkg install stress#opkg install sysutils/stress
Por último, en lo que respecta a la instalación, el OpenBSD, sería:
export PKG_PATH=http://ftp.usa.openbsd.org/pub/OpenBSD/`uname -r`/packages/`arch -s`
pkg_add stress
Manos a la obra
Una vez instalado veamos su funcionamiento:
stress [parámetros]
Los parámetros más comunes son:
- -c o –cpu N : Crea un número dado de hilos de trabajo en sqrt()
- -i o –io N : Crea un número dado de hilos de trabajo en sync()
- -m o –vm N : Crear un número dado de hilos de trabajo en malloc/free()
- -t 10s : Tiempo de espera
- -v : Modo en detalle (verbose)
Un ejemplo:
[root@servcacti ~]# uptime
15:32:39 up 2:03, 2 users, load average: 1,59, 0,57, 0,23
[root@servcacti ~]# stress -c 8 -i 4 -m 2 -t 20s
stress: info: [3585] dispatching hogs: 8 cpu, 4 io, 2 vm, 0 hdd
stress: info: [3585] successful run completed in 20s
[root@servcacti ~]# uptime
15:33:11 up 2:03, 2 users, load average: 3,74, 1,18, 0,45
[root@servcacti ~]#
De manera gráfica podemos ver su impacto, en otro de los servidores que tengo por casa, aplicando justo los mismos parámetros, pero esta vez hasta 60 segundos:
[root@test ~]# stress -c 8 -i 4 -m 2 -t 60s
stress: info: [6064] dispatching hogs: 8 cpu, 4 io, 2 vm, 0 hdd
stress: info: [6064] successful run completed in 60s
[root@test ~]# uptime
15:39:11 up 47 days, 4:39, 1 user, load average: 8,16, 3,55, 1,42
Visualmente queda más claro:
Espero que os sea útil en algún momento, nos vamos leyendo.
Fuente principal | linux.die.net
Ya se como hacer esta prueba pues soy un novato junior 😉
¿Has encontrado mucha bajada de rendimiento con los parches?
Buenas colega,
En su día me pasé varias semanas realizando estas pruebas estrés en varios servidores físicos. Y en todos el rendimiento de la CPU era peor tras aplicar los parches que mitigaban Meltdown y Spectre. En los hosts virtuales no se no notaba apenas cambio, ya que lo hay que parchear son los ESX, en el caso de VMWARE.
Saludos