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
sudoal 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 sysstatsudo systemctl enable --now sysstatsystemctl 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.timerls /var/log/sa/sa26 sa27 sa28Actí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
| Herramienta | Qué miras | Señal de problema |
|---|---|---|
top | Carga, procesos que más CPU o memoria usan, wa | wa alto: la CPU espera al disco |
vmstat 2 5 | r (cola de CPU), si/so (swap), wa | r mayor que núcleos de forma sostenida, si/so distintos de cero |
iostat -xz 2 3 | r_await, w_await, aqu-sz, %util por disco | Esperas de decenas de ms en un disco que antes daba pocos |
sar | Lo mismo, pero en el pasado | El cambio entre ayer y hoy |
pidstat -d 2 | Qué proceso lee o escribe | El culpable con nombre |
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.
- ¿Qué ha cambiado?
dnf history(paquetes),last reboot,journalctl --since today -p erry el registro de cambios del hospital. - Ahora mismo:
vmstatyiostatpara ver si es CPU, memoria o disco. - 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.1sar -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.1pidstat -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 javaEl 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.
- 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
sysstatsigue 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.
What you'll get
Knowing, with data, why a Red Hat server is slow and what to change without making anything worse. In a hospital these servers are often the integration engine moving HL7 messages between the health record and the laboratory, the pharmacy application server or the one receiving radiology images: if they slow down, a result takes longer to reach the ward. That's why you don't experiment in production or reboot mid-morning here; you measure, compare and change one thing at a time, with its change approved.
Before you start
sudoaccess to the server and the name of the owner of the application that runs on it.- Knowing what "normal" is: without a baseline, any number looks high.
- The application vendor's contact: many certify only certain system parameters and won't accept tuning done on your own.
- The hospital's change window and the urgency criterion for a change outside it.
1. The baseline with sysstat
sysstat records CPU, memory, disk and network every ten minutes. It is what lets you compare today with yesterday at the same time.
sudo dnf install -y sysstatsudo systemctl enable --now sysstatsystemctl 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.timerls /var/log/sa/sa26 sa27 sa28Enable it on every critical server from day one, together with monitoring (Grafana guide). Data from the week before the incident is worth more than any tuning.
2. Reading the server: top, vmstat, iostat and sar
| Tool | What you look at | Sign of trouble |
|---|---|---|
top | Load, processes using most CPU or memory, wa | High wa: the CPU is waiting for disk |
vmstat 2 5 | r (CPU queue), si/so (swap), wa | r above the core count for a sustained time, non-zero si/so |
iostat -xz 2 3 | r_await, w_await, aqu-sz, %util per disk | Waits of tens of ms on a disk that used to give a few |
sar | The same, but in the past | The change between yesterday and today |
pidstat -d 2 | Which process reads or writes | The culprit by name |
Load average on Linux includes processes waiting for disk: high load with an idle CPU points at storage, not the processor.
3. What you can tune
tuned profiles. tuned-adm active shows the active profile and tuned-adm recommend the suggested one. On a VM the usual one is virtual-guest; on physical hardware, throughput-performance. Many vendors require a specific one, and that one wins.
Memory and swap. free -h and vmstat tell you whether swap is in active use (si/so), which is what hurts, not swap filled days ago. vm.swappiness is changed in a file under /etc/sysctl.d/ and only if the vendor says so; if memory is short, the fix is memory.
I/O scheduler. cat /sys/block/sdb/queue/scheduler shows the active one in brackets. On RHEL 9, VM and NVMe disks usually run none or mq-deadline; the tuned profile already sets it, so change it in the profile, not by hand.
File systems. df -h and also df -i: a /var with no free inodes fails just like a full one. XFS is the RHEL standard; the default mount (relatime) is almost always enough.
Limits. For a systemd service, the limits in /etc/security/limits.d/ don't apply: they go in a drop-in with LimitNOFILE= (systemctl edit hl7-engine). systemctl show hl7-engine -p LimitNOFILE gives the real value. The typical symptom is Too many open files in the application log.
journald. journalctl --disk-usage shows how much it uses. Cap it with SystemMaxUse= in /etc/systemd/journald.conf so a service that never stops writing can't fill /var.
4. The ticket: "the server has been slow since this morning"
Wednesday, 9:15. The laboratory reports that results take twenty minutes to show in the health record. The integration engine runs on srv-hl7-01.
- What changed?
dnf history(packages),last reboot,journalctl --since today -p errand the hospital's change log. - Right now:
vmstatandiostatto see whether it is CPU, memory or disk. - Compare with yesterday at the same time with
sar, and find the process.
iostat -xz 2 2# columns trimmedDevice r/s w/s r_await w_await aqu-sz %utilsdb 812.0 96.5 41.20 38.70 37.10 99.1sar -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.1pidstat -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 javaThe data disk (sdb) is saturated, when yesterday at the same time it was at 12 %. The process is an rsync from a backup job someone moved from 3:00 to 7:00. The job is stopped with the backup owner, put back at its time, and the queued messages are processed in minutes. No kernel parameter would have fixed it.
- Close the ticket with the cause and the action: the change record notes that the backup has a fixed time and who must approve moving it.
5. What you review each month
- That
sysstatis still collecting on every critical server. - The growth of
/var, of the data and of the journal. - Each server's tuned profile against the one its vendor requires.
- The times of backups, antivirus scans and scheduled tasks: that none overlaps with peaks of clinical activity.
Next steps
- The Level 2 Red Hat Enterprise Linux guide covers basic system administration.
- The Ansible guide lets you apply the same profile and limits to every server.
- The Grafana guide turns the baseline into dashboards the whole team can see.
- The Linux integrated with AD guide explains named access for technicians to these servers.
Is something missing, or different in your environment? Get in touch and I'll fix it.
Tech Career Lab · newsletter
¿Te ha servido? Cada dos semanas envío una idea práctica para perfiles IT: LinkedIn, proyectos, networking y procesos de selección.Found this useful? Every two weeks I send one practical idea for IT professionals: LinkedIn, projects, networking and hiring processes.
Apúntate y llévate las 33 ideasSign up and get the 33 ideas →