Optimización del Rendimiento del Sistema RHEL: Guía Completa

Introducción

En este laboratorio, aprenderá a optimizar el rendimiento del sistema RHEL utilizando tuned y a gestionar las prioridades de los procesos con nice y renice. Comenzará verificando la instalación de tuned y listando los perfiles disponibles, luego observará cómo el cambio de los perfiles de tuned impacta en los parámetros del sistema.

El laboratorio le guiará a través del inicio y la monitorización de procesos intensivos en CPU, seguido del ajuste de sus prioridades utilizando nice y renice para comprender su efecto en la asignación de recursos. Finalmente, aprenderá a limpiar los procesos en ejecución, asegurando una comprensión completa del ajuste del rendimiento en RHEL.

Este es un Guided Lab, que proporciona instrucciones paso a paso para ayudarte a aprender y practicar. Sigue las instrucciones cuidadosamente para completar cada paso y obtener experiencia práctica. Los datos históricos muestran que este es un laboratorio de nivel principiante con una tasa de finalización del 91%. Ha recibido una tasa de reseñas positivas del 99% por parte de los estudiantes.

Verificar el Estado de tuned y Listar los Perfiles Disponibles

En este paso, aprenderá a verificar el estado del demonio tuned y a listar los perfiles de ajuste disponibles en su sistema RHEL. tuned es un demonio de ajuste dinámico y adaptativo del sistema que ajusta la configuración del sistema para optimizar el rendimiento para cargas de trabajo específicas. Utiliza perfiles de ajuste para aplicar un conjunto de configuraciones en todo el sistema.

Verifique que el demonio tuned se esté ejecutando.
En este entorno de contenedor, comprobaremos si el demonio tuned se está ejecutando buscando su proceso. También podemos verificar su funcionalidad comprobando si responde a los comandos.

Primero, compruebe si el proceso tuned se está ejecutando:
```
pgrep tuned
```
Si tuned se está ejecutando, este comando devolverá su ID de proceso (PID). Si no se devuelve ningún PID, puede iniciar el demonio manualmente:
```
sudo /usr/sbin/tuned &
```
Luego, verifique que se esté ejecutando:
```
pgrep tuned
```
Debería ver una salida similar a:
```
739
```
(Nota: El valor PID en su salida variará.)

Además, puede verificar que tuned es funcional comprobando si responde a las consultas de estado:
```
sudo tuned-adm active
```
Esto debería devolver el perfil actualmente activo sin errores.

Liste los perfiles de ajuste disponibles e identifique el perfil activo.
El comando tuned-adm list muestra todos los perfiles de ajuste disponibles y resalta el actualmente activo.

sudo tuned-adm list

Se le pedirá su contraseña. Observe el Current active profile en la salida.

Available profiles:
- accelerator-performance     - Throughput performance based tuning with disabled higher latency STOP states
- aws                         - Optimize for aws ec2 instances
- balanced                    - General non-specialized tuned profile
- balanced-battery            - Balanced profile biased towards power savings changes for battery
- desktop                     - Optimize for the desktop use-case
- hpc-compute                 - Optimize for HPC compute workloads
- intel-sst                   - Configure for Intel Speed Select Base Frequency
- latency-performance         - Optimize for deterministic performance at the cost of increased power consumption
- network-latency             - Optimize for deterministic performance at the cost of increased power consumption, focused on low latency network performance
- network-throughput          - Optimize for streaming network throughput, generally only necessary on older CPUs or 40G+ networks
- optimize-serial-console     - Optimize for serial console use.
- powersave                   - Optimize for low power consumption
- throughput-performance      - Broadly applicable tuning that provides excellent performance across a variety of common server workloads
- virtual-guest               - Optimize for running inside a virtual guest
- virtual-host                - Optimize for running KVM guests
Current active profile: virtual-guest

Revise la configuración del perfil virtual-guest.
El perfil virtual-guest es a menudo el predeterminado para las máquinas virtuales. Puede inspeccionar su archivo de configuración para comprender qué configuraciones aplica.

cat /usr/lib/tuned/virtual-guest/tuned.conf

Este comando muestra la configuración de tuned para el perfil virtual-guest, incluyendo los parámetros que hereda de otros perfiles.

#
## tuned configuration
#

[main]
summary=Optimize for running inside a virtual guest
include=throughput-performance

[vm]
## If a workload mostly uses anonymous memory and it hits this limit, the entire
## working set is buffered for I/O, and any more write buffering would require
## swapping, so it's time to throttle writes until I/O can catch up.  Workloads
## that mostly use file mappings may be able to use even higher values.
#
## The generator of dirty data starts writeback at this percentage (system default
## is 20%)
dirty_ratio = 30

[sysctl]
## Filesystem I/O is usually much more efficient than swapping, so try to keep
## swapping low.  It's usually safe to go even lower than this on systems with
## server-grade storage.
vm.swappiness = 30

Verifique que el parámetro vm.dirty_background_ratio se aplique.
El perfil virtual-guest incluye throughput-performance. Comprobemos un parámetro que throughput-performance normalmente establece, como vm.dirty_background_ratio. Este parámetro controla cuándo el sistema comienza a escribir páginas sucias en el disco en segundo plano.
```
sysctl vm.dirty_background_ratio
```
La salida mostrará el valor actual de este parámetro del kernel.
```
vm.dirty_background_ratio = 10
```

Cambiar el Perfil tuned y Observar los Cambios en los Parámetros del Sistema

En este paso, aprenderá a cambiar el perfil tuned activo y a observar los efectos inmediatos en los parámetros del sistema. Cambiar un perfil tuned le permite aplicar rápidamente un conjunto de optimizaciones de rendimiento adaptadas a diferentes cargas de trabajo, como tareas intensivas en rendimiento o ahorro de energía.

Cambiar el perfil de ajuste activo actual a throughput-performance.
El perfil throughput-performance está diseñado para sistemas que requieren un alto rendimiento, a menudo sacrificando algo de latencia. Normalmente optimiza para la E/S de disco y el rendimiento de la red. Utilice el comando tuned-adm profile para cambiar de perfil.
```
sudo tuned-adm profile throughput-performance
```
Se le pedirá su contraseña.
```
$ sudo tuned-adm profile throughput-performance
[sudo] password for user:
```
Confirmar el nuevo perfil activo.
Después de cambiar el perfil, es una buena práctica verificar que el nuevo perfil esté realmente activo. Puede hacerlo usando tuned-adm active.
```
sudo tuned-adm active
```
La salida ahora debería mostrar throughput-performance como el perfil activo.
```
Current active profile: throughput-performance
```
Verificar que los parámetros vm.dirty_ratio y vm.swappiness hayan cambiado.
El perfil throughput-performance modifica los parámetros del kernel relacionados con la gestión de la memoria, como vm.dirty_ratio y vm.swappiness. Aunque el perfil virtual-guest hereda de throughput-performance, cambiar directamente al perfil throughput-performance aplica los valores base sin las modificaciones específicas de virtual-guest.
- vm.dirty_ratio: Este parámetro define el porcentaje máximo de memoria del sistema que puede llenarse con páginas sucias (páginas que han sido modificadas pero aún no escritas en el disco) antes de que el sistema comience a escribirlas en el disco. Un valor más alto puede mejorar el rendimiento al permitir que se almacenen más datos en búfer en la memoria.
- vm.swappiness: Este parámetro controla con qué agresividad el kernel intercambia memoria anónima (datos de la aplicación) de la RAM al espacio de intercambio. Un valor más bajo significa que el kernel intentará mantener más datos de la aplicación en la RAM, lo que generalmente es mejor para el rendimiento.
Comprobemos sus valores actuales usando sysctl.
```
sysctl vm.dirty_ratio
sysctl vm.swappiness
```
Debería observar que los valores han cambiado de la configuración del perfil virtual-guest (dirty_ratio = 30, vm.swappiness = 30) a los valores base del perfil throughput-performance:
```
vm.dirty_ratio = 40
vm.swappiness = 10
```
(Nota: Estos valores reflejan las optimizaciones base de throughput-performance sin las modificaciones específicas de virtual-guest.)

Iniciar y Monitorear Procesos Intensivos en CPU en RHEL

En este paso, aprenderá a iniciar procesos intensivos en CPU y a monitorizar su uso de recursos. Esto es crucial para comprender cómo los procesos consumen recursos del sistema y cómo identificar cuellos de botella. Usaremos el comando sha1sum /dev/zero, que calcula continuamente la suma de comprobación SHA1 de un flujo interminable de ceros, consumiendo efectivamente ciclos de CPU.

Importante: Este ejercicio utiliza comandos que realizan sumas de comprobación interminables en un archivo de dispositivo, consumiendo intencionadamente recursos significativos de la CPU. Debe finalizar todos los procesos del ejercicio antes de salir de este ejercicio o pasar al siguiente laboratorio.

Determinar el número de núcleos de CPU en su sistema.
Comprender el número de núcleos de CPU le ayuda a decidir cuántos procesos intensivos en CPU ejecutar para utilizar completamente el sistema. Puede encontrar esta información en /proc/cpuinfo.
```
grep -c '^processor' /proc/cpuinfo
```
Este comando cuenta el número de líneas que comienzan con processor, que corresponde al número de núcleos de CPU lógicos (o procesadores virtuales).
```
2
```
(Nota: Su salida podría mostrar un número diferente de núcleos dependiendo de la configuración del sistema.)
Iniciar dos instancias del comando sha1sum /dev/zero & por cada núcleo de CPU.
Para simular un sistema con mucha carga, iniciaremos múltiples instancias de sha1sum /dev/zero &. El & al final del comando ejecuta el proceso en segundo plano, lo que le permite seguir utilizando el terminal. Por ejemplo, si tiene 2 núcleos de CPU, iniciaría 4 instancias (2 instancias/núcleo * 2 núcleos).
```
for i in $(seq 1 $(grep -c '^processor' /proc/cpuinfo | awk '{print $1 * 2}')); do sha1sum /dev/zero & done
```
Este comando calcula dinámicamente el número de procesos a iniciar en función del recuento de núcleos de su CPU.
```
[1] 1234
[2] 1235
[3] 1236
[4] 1237
```
(Nota: Los valores PID en su salida variarán del ejemplo.)
Verificar que los trabajos en segundo plano se estén ejecutando.
El comando jobs enumera todos los procesos que se ejecutan actualmente en segundo plano desde su sesión de shell.
```
jobs
```
Debería ver una lista de los procesos sha1sum que acaba de iniciar.
```
[1]   Running                 sha1sum /dev/zero &
[2]   Running                 sha1sum /dev/zero &
[3]   Running                 sha1sum /dev/zero &
[4]-  Running                 sha1sum /dev/zero &
```
Utilizar los comandos ps y pgrep para mostrar el porcentaje de uso de CPU para cada proceso sha1sum.
El comando ps informa una instantánea de los procesos actuales. Lo combinaremos con pgrep para filtrar los procesos sha1sum.
- ps -o pid,pcpu,nice,comm: Esto especifica el formato de salida: ID de proceso (pid), porcentaje de uso de CPU (pcpu), valor nice (nice) y nombre del comando (comm).
- $(pgrep sha1sum): Esta sustitución de comandos encuentra los PID de todos los procesos llamados sha1sum y los pasa como argumentos a ps.
```
ps -o pid,pcpu,nice,comm $(pgrep sha1sum)
```
Debería ver que cada proceso sha1sum consume un porcentaje significativo de CPU.
```
    PID %CPU  NI COMMAND
   5248 48.8   0 sha1sum
   5249 48.7   0 sha1sum
   5250 48.8   0 sha1sum
   5251 48.8   0 sha1sum
```
(Nota: Los valores %CPU podrían fluctuar, pero deberían ser altos, lo que indica un uso intensivo de la CPU. La columna NI muestra el valor nice.)
Finalizar todos los procesos sha1sum en ejecución y verificar que no quede ninguno.
Es crucial limpiar estos procesos intensivos en CPU antes de continuar. El comando pkill finaliza los procesos en función de su nombre.
```
pkill sha1sum
```
Ahora, verifique que no se estén ejecutando trabajos sha1sum en segundo plano.
```
jobs
```
La salida debería estar vacía, o indicar que todos los trabajos han finalizado.
```
[1]   Terminated              sha1sum /dev/zero
[2]   Terminated              sha1sum /dev/zero
[3]   Terminated              sha1sum /dev/zero
[4]-  Terminated              sha1sum /dev/zero
```
(Nota: Podría ver mensajes "Terminated", lo cual es esperado ya que los procesos se están deteniendo.)

Ajustar la Prioridad de los Procesos con nice y renice en RHEL

En este paso, aprenderá a influir en la prioridad de programación de los procesos utilizando los comandos nice y renice. El valor nice (también conocido como niceness) de un proceso indica su prioridad al programador de Linux. Un valor nice más bajo (más negativo) significa una prioridad más alta, mientras que un valor nice más alto (más positivo) significa una prioridad más baja. El rango de valores nice suele ser de -20 (prioridad más alta) a 19 (prioridad más baja), siendo 0 el valor predeterminado.

Iniciar múltiples instancias de sha1sum /dev/zero & y luego iniciar una instancia adicional con un nivel nice de 10.
Iniciaremos varios procesos sha1sum para simular un sistema ocupado. Luego, iniciaremos uno con una prioridad deliberadamente más baja (valor nice más alto) para observar el efecto.

Primero, inicie tres instancias regulares (ajuste según el recuento de núcleos de su CPU si lo desea, pero al menos tantos como procesadores virtuales para crear contención):
```
for i in {1..3}; do sha1sum /dev/zero & done
```
A continuación, inicie la cuarta instancia con un nivel nice de 10. Este proceso tendrá una prioridad más baja en comparación con los demás.
```
nice -n 10 sha1sum /dev/zero &
```
Verá una salida similar a esta, que indica los PID de los procesos en segundo plano:
```
[1] 5443
[2] 5444
[3] 5445
[4] 5446
```
(Nota: Los valores PID en su salida variarán.)
Utilizar los comandos ps y pgrep para mostrar el PID, el porcentaje de uso de CPU, el valor nice y el nombre del ejecutable para cada proceso.
Observe las columnas %CPU y NI. La instancia con el valor nice de 10 debería mostrar un porcentaje de uso de CPU más bajo que las otras instancias, ya que el programador le da menos tiempo de CPU.
```
ps -o pid,pcpu,nice,comm $(pgrep sha1sum)
```
Busque el proceso con el valor NI 10. Su %CPU debería ser notablemente más bajo que los demás.
```
    PID %CPU  NI COMMAND
   5443 56.8   0 sha1sum
   5444 58.0   0 sha1sum
   5445 56.5   0 sha1sum
   5446  6.7  10 sha1sum
```
(Nota: Los valores exactos de %CPU variarán según la carga del sistema y el recuento de núcleos, pero el proceso con nice 10 debería tener una cuota más baja.)
Utilizar el comando sudo renice para cambiar el nivel nice de uno de los procesos regulares a 5.
El comando renice le permite cambiar el valor nice de un proceso que ya se está ejecutando. Demostraremos esto cambiando uno de los procesos regulares (valor nice 0) a un valor nice de 5.

Primero, identifique el PID de uno de los procesos sha1sum que tiene un valor nice de 0 de la salida del comando ps anterior. Usemos el primero del ejemplo anterior (PID 5443).
```
sudo renice -n 5 <PID_of_regular_process>
```
Reemplace <PID_of_regular_process> con el PID real que identificó. Por ejemplo:
```
sudo renice -n 5 5443
```
Debería ver una salida que confirme el cambio de prioridad:
```
5443 (process ID) old priority 0, new priority 5
```
Repetir los comandos ps y pgrep para mostrar el porcentaje de CPU y el nivel nice.
Observe el cambio en el uso de la CPU para el proceso cuyo valor nice modificó. El proceso con el valor nice 5 ahora debería tener un uso de CPU ligeramente más bajo en comparación con los procesos con el valor nice 0, pero más alto que el proceso con el valor nice 10.
```
ps -o pid,pcpu,nice,comm $(pgrep sha1sum)
```
Debería ver que el valor NI para el proceso modificado ahora es 5, y su uso de CPU refleja su nuevo nivel de prioridad.
```
    PID %CPU  NI COMMAND
   5443 55.4   5 sha1sum
   5444 67.2   0 sha1sum
   5445 67.1   0 sha1sum
   5446  7.5  10 sha1sum
```
(Nota: Los valores exactos de %CPU variarán, pero debería observar que los procesos con valores nice más bajos (prioridad más alta) obtienen más tiempo de CPU.)

Limpiar Procesos en Ejecución

En este paso final, se asegurará de que todos los procesos en segundo plano iniciados durante el laboratorio se terminen correctamente. Este es un paso de limpieza crítico para evitar el consumo de recursos no deseado y garantizar que el entorno del laboratorio se restablezca para un uso futuro.

Utilizar el comando pkill para finalizar todos los procesos en ejecución con el patrón de nombre sha1sum.
El comando pkill es una forma eficiente de enviar una señal (por defecto, SIGTERM) a los procesos en función de su nombre. Esto detendrá todos los procesos sha1sum que inició en los pasos anteriores.
```
pkill sha1sum
```
Podría ver mensajes que indican que los procesos han sido finalizados.
```
[3]-  Terminated              sha1sum /dev/zero
[2]-  Terminated              sha1sum /dev/zero
[4]+  Terminated              nice -n 10 sha1sum /dev/zero
[1]+  Terminated              sha1sum /dev/zero
```
Verificar que no haya procesos sha1sum todavía en ejecución.
Puede usar pgrep para verificar si hay procesos sha1sum todavía activos. Si pgrep no devuelve ninguna salida, significa que no se están ejecutando tales procesos.
```
pgrep sha1sum
```
Este comando no debería devolver ninguna salida, lo que indica que todos los procesos sha1sum se han finalizado correctamente.
```
$ pgrep sha1sum
$
```

Resumen

En este laboratorio, aprendimos a gestionar y utilizar tuned para la optimización del rendimiento del sistema en RHEL. Comenzamos verificando la instalación y el estado del servicio tuned y enumerando los perfiles de ajuste disponibles, comprendiendo que tuned adapta dinámicamente la configuración del sistema para cargas de trabajo específicas utilizando estos perfiles. Luego, practicamos el inicio de sesión en un entorno servera simulado a través de SSH como el usuario labex y confirmamos la instalación del paquete tuned utilizando dnf list tuned.

El laboratorio nos guio además a través del cambio de perfiles tuned para observar su impacto en los parámetros del sistema, demostrando cómo diferentes perfiles pueden alterar el comportamiento del sistema. También obtuvimos experiencia práctica en el inicio y la monitorización de procesos intensivos en CPU, lo cual es crucial para identificar cuellos de botella en el rendimiento. Finalmente, aprendimos a ajustar las prioridades de los procesos utilizando los comandos nice y renice para gestionar la asignación de recursos de manera efectiva, y concluimos limpiando los procesos en ejecución para restaurar el sistema a su estado inicial.

Optimización del Rendimiento del Sistema en RHEL