Red Hat: ajuste de rendimiento de un servidor que no puede parar

Qué vas a conseguir

Saber, con datos, por qué un servidor Red Hat va lento y qué cambiar sin empeorar nada. En un hospital estos servidores suelen ser el motor de integración que mueve los mensajes HL7 entre la historia clínica y el laboratorio, el servidor de la aplicación de farmacia o el que recibe las imágenes de radiología: si van lentos, un resultado tarda en llegar a la planta. Por eso aquí no se prueba en producción ni se reinicia a media mañana; se mide, se compara y se cambia una cosa cada vez, con su cambio aprobado.

Antes de empezar

• Acceso con sudo al servidor y el nombre del responsable de la aplicación que corre en él.
• Saber qué es "normal": sin una línea base, cualquier número parece alto.
• El proveedor de la aplicación localizado: muchos certifican solo ciertos parámetros del sistema y no aceptan ajustes por su cuenta.
• La ventana de cambios del hospital y el criterio de urgencia para un cambio fuera de ella.

1. La línea base con sysstat

sysstat guarda cada diez minutos CPU, memoria, disco y red. Es lo que te permite comparar hoy con ayer a la misma hora.

›sudo dnf install -y sysstat›sudo systemctl enable --now sysstat›systemctl list-timers 'sysstat*' --no-pagerNEXT                        LEFT     UNITWed 2026-10-28 10:40:00 CET 6min     sysstat-collect.timerThu 2026-10-29 00:07:00 CET 13h      sysstat-summary.timer›ls /var/log/sa/sa26  sa27  sa28

Actívalo en todos los servidores críticos desde el primer día, junto con la monitorización (guía de Grafana). Los datos de la semana anterior al incidente valen más que cualquier ajuste.

2. Leer el servidor: top, vmstat, iostat y sar

La carga (load average) en Linux incluye procesos esperando disco: una carga alta con la CPU ociosa apunta al almacenamiento, no al procesador.

3. Lo que puedes ajustar

Perfiles de tuned. tuned-adm active dice el perfil activo y tuned-adm recommend el sugerido. En una VM lo normal es virtual-guest; en físico, throughput-performance. Muchos proveedores piden uno concreto, y ese manda.

Memoria y swap. free -h y vmstat dicen si hay swap en uso activo (si/so), que es lo que duele, no el swap ocupado de hace días. vm.swappiness se cambia en un fichero de /etc/sysctl.d/ y solo si el proveedor lo indica; si falta memoria, la solución es memoria.

Planificador de E/S. cat /sys/block/sdb/queue/scheduler muestra el activo entre corchetes. En RHEL 9 los discos de VM y NVMe suelen ir con none o mq-deadline; el perfil de tuned ya lo fija, así que cámbialo en el perfil y no a mano.

Sistemas de ficheros. df -h y también df -i: un /var sin inodos libres falla igual que uno lleno. XFS es el estándar en RHEL; el montaje por defecto (relatime) basta casi siempre.

Límites. Para un servicio de systemd, los límites de /etc/security/limits.d/ no aplican: se ponen con LimitNOFILE= en un drop-in (systemctl edit motor-hl7). systemctl show motor-hl7 -p LimitNOFILE dice el valor real. El síntoma típico es Too many open files en el log de la aplicación.

journald. journalctl --disk-usage dice cuánto ocupa. Limítalo con SystemMaxUse= en /etc/systemd/journald.conf para que un servicio que escribe sin parar no llene /var.

4. El ticket: "el servidor va lento desde esta mañana"

Miércoles, 9:15. El laboratorio avisa de que los resultados tardan veinte minutos en verse en la historia clínica. El motor de integración está en srv-hl7-01.

1. ¿Qué ha cambiado? dnf history (paquetes), last reboot, journalctl --since today -p err y el registro de cambios del hospital.
2. Ahora mismo: vmstat y iostat para ver si es CPU, memoria o disco.
3. Comparar con ayer a la misma hora con sar, y buscar el proceso.

›iostat -xz 2 2# columnas recortadasDevice   r/s     w/s     r_await  w_await  aqu-sz  %utilsdb      812.0   96.5    41.20    38.70    37.10   99.1›sar -d -p -f /var/log/sa/sa27 -s 09:00:00 -e 09:30:00 | grep -E 'DEV|sdb'09:00:00   DEV       tps     ...  await  %util09:10:00   sdb       102.4   ...  1.40   12.309:20:00   sdb       98.7    ...  1.60   13.1›pidstat -d 2 1Time      UID   PID    kB_rd/s   kB_wr/s  kB_ccwr/s iodelay  Command09:17:42  0     48213  98304.0   0.0      0.0       180      rsync09:17:42  987   2210   120.0     3410.0   0.0       96       java

El disco de datos (sdb) está saturado, cuando ayer a la misma hora estaba al 12 %. El proceso es un rsync de una copia que alguien ha movido de las 3:00 a las 7:00. Se para la tarea con el responsable de la copia, se devuelve a su hora y los mensajes en cola se procesan en minutos. Ningún parámetro del kernel lo habría arreglado.

1. Cierra el ticket con la causa y la medida: se documenta en el cambio que la copia tiene una hora fija y quién debe aprobar moverla.

5. Lo que revisas cada mes

• Que sysstat sigue recogiendo en todos los servidores críticos.
• El crecimiento de /var, de los datos y del journal.
• El perfil de tuned de cada servidor frente al que pide su proveedor.
• Las horas de copias, antivirus y tareas programadas: que ninguna coincide con picos de actividad asistencial.

Siguientes pasos

• La guía de Red Hat Enterprise Linux del Nivel 2 cubre la administración básica del sistema.
• La guía de Ansible permite aplicar el mismo perfil y los mismos límites a todos los servidores.
• La guía de Grafana convierte la línea base en paneles que ve todo el equipo.
• La guía de Linux integrado con AD explica el acceso nominal de los técnicos a estos servidores.

¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.