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.
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
tunedse esté ejecutando. En este entorno de contenedor, comprobaremos si el demoniotunedse está ejecutando buscando su proceso. También podemos verificar su funcionalidad comprobando si responde a los comandos.Primero, compruebe si el proceso
tunedse está ejecutando:pgrep tunedSi
tunedse 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 tunedDebería ver una salida similar a:
739(Nota: El valor PID en su salida variará.)
Además, puede verificar que
tunedes funcional comprobando si responde a las consultas de estado:sudo tuned-adm activeEsto debería devolver el perfil actualmente activo sin errores.
Liste los perfiles de ajuste disponibles e identifique el perfil activo. El comando
tuned-adm listmuestra todos los perfiles de ajuste disponibles y resalta el actualmente activo.sudo tuned-adm listSe le pedirá su contraseña. Observe el
Current active profileen 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-guestRevise la configuración del perfil
virtual-guest. El perfilvirtual-guestes 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.confEste comando muestra la configuración de
tunedpara el perfilvirtual-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 = 30Verifique que el parámetro
vm.dirty_background_ratiose aplique. El perfilvirtual-guestincluyethroughput-performance. Comprobemos un parámetro quethroughput-performancenormalmente establece, comovm.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_ratioLa 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 perfilthroughput-performanceestá 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 comandotuned-adm profilepara cambiar de perfil.sudo tuned-adm profile throughput-performanceSe 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 activeLa salida ahora debería mostrar
throughput-performancecomo el perfil activo.Current active profile: throughput-performanceVerificar que los parámetros
vm.dirty_ratioyvm.swappinesshayan cambiado. El perfilthroughput-performancemodifica los parámetros del kernel relacionados con la gestión de la memoria, comovm.dirty_ratioyvm.swappiness. Aunque el perfilvirtual-guesthereda dethroughput-performance, cambiar directamente al perfilthroughput-performanceaplica los valores base sin las modificaciones específicas devirtual-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.swappinessDeberí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 perfilthroughput-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/cpuinfoEste 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 desha1sum /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 & doneEste 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
jobsenumera todos los procesos que se ejecutan actualmente en segundo plano desde su sesión de shell.jobsDebería ver una lista de los procesos
sha1sumque 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
psypgreppara mostrar el porcentaje de uso de CPU para cada procesosha1sum. El comandopsinforma una instantánea de los procesos actuales. Lo combinaremos conpgreppara filtrar los procesossha1sum.ps -o pid,pcpu,nice,comm: Esto especifica el formato de salida: ID de proceso (pid), porcentaje de uso de CPU (pcpu), valornice(nice) y nombre del comando (comm).$(pgrep sha1sum): Esta sustitución de comandos encuentra los PID de todos los procesos llamadossha1sumy los pasa como argumentos aps.
ps -o pid,pcpu,nice,comm $(pgrep sha1sum)Debería ver que cada proceso
sha1sumconsume 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
%CPUpodrían fluctuar, pero deberían ser altos, lo que indica un uso intensivo de la CPU. La columnaNImuestra el valor nice.)Finalizar todos los procesos
sha1sumen ejecución y verificar que no quede ninguno. Es crucial limpiar estos procesos intensivos en CPU antes de continuar. El comandopkillfinaliza los procesos en función de su nombre.pkill sha1sumAhora, verifique que no se estén ejecutando trabajos
sha1sumen segundo plano.jobsLa 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 nivelnicede 10. Iniciaremos varios procesossha1sumpara simular un sistema ocupado. Luego, iniciaremos uno con una prioridad deliberadamente más baja (valornicemá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 & doneA continuación, inicie la cuarta instancia con un nivel
nicede 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
psypgreppara mostrar el PID, el porcentaje de uso de CPU, el valornicey el nombre del ejecutable para cada proceso. Observe las columnas%CPUyNI. La instancia con el valornicede 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
NI10. Su%CPUdeberí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
%CPUvariarán según la carga del sistema y el recuento de núcleos, pero el proceso connice 10debería tener una cuota más baja.)Utilizar el comando
sudo renicepara cambiar el nivelnicede uno de los procesos regulares a 5. El comandorenicele permite cambiar el valornicede 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
sha1sumque tiene un valornicede 0 de la salida del comandopsanterior. 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 5443Debería ver una salida que confirme el cambio de prioridad:
5443 (process ID) old priority 0, new priority 5Repetir los comandos
psypgreppara mostrar el porcentaje de CPU y el nivelnice. Observe el cambio en el uso de la CPU para el proceso cuyo valornicemodificó. 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
NIpara el proceso modificado ahora es5, 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
%CPUvariará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
pkillpara finalizar todos los procesos en ejecución con el patrón de nombresha1sum. El comandopkilles una forma eficiente de enviar una señal (por defecto,SIGTERM) a los procesos en función de su nombre. Esto detendrá todos los procesossha1sumque inició en los pasos anteriores.pkill sha1sumPodrí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/zeroVerificar que no haya procesos
sha1sumtodavía en ejecución. Puede usarpgreppara verificar si hay procesossha1sumtodavía activos. Sipgrepno devuelve ninguna salida, significa que no se están ejecutando tales procesos.pgrep sha1sumEste comando no debería devolver ninguna salida, lo que indica que todos los procesos
sha1sumse 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.
