LinuxParty

Aprende a comprobar el procesador, la memoria RAM, los discos, el sistema de archivos, el RAID y la conexión de red de un servidor dedicado utilizando herramientas de Linux

Cuando un servidor comienza a reiniciarse, bloquearse o generar errores de entrada y salida, no siempre resulta sencillo determinar si el origen está en el sistema operativo, una aplicación o un componente físico.

Linux incluye numerosas herramientas para comprobar el procesador, la memoria RAM, las unidades de almacenamiento y la red. En esta guía veremos cómo utilizarlas desde un sistema de rescate o una distribución arrancada desde un dispositivo externo.

Antes de comenzar

Las pruebas intensivas pueden provocar una caída si el equipo tiene un componente defectuoso. También consumen una gran cantidad de CPU, memoria y recursos de almacenamiento.

Antes de empezar es recomendable:

• Disponer de una copia de seguridad actualizada.
• Detener los servicios y máquinas virtuales importantes.
• Programar una ventana de mantenimiento.
• Anotar los errores y las horas en las que se producen.
• Acceder mediante una consola remota, si está disponible.
• Arrancar un sistema de rescate cuando sea necesario desmontar las particiones.

También conviene revisar primero los mensajes recientes del núcleo:

dmesg -T | less

Para buscar errores relacionados con el hardware:

dmesg -T | grep -iE 'error|fail|critical|mce|edac|ecc|ata|nvme|i/o'

En distribuciones con systemd podemos consultar los mensajes del arranque actual:

journalctl -k -b -p warning

Estos registros pueden revelar errores de memoria ECC, problemas NVMe, sectores defectuosos, fallos del bus SATA o eventos de comprobación de la máquina.

Identificar el hardware instalado

Antes de ejecutar las pruebas debemos conocer los componentes del servidor.

Para mostrar información del procesador:

lscpu

Para consultar la memoria disponible:

free -h

Para identificar discos, particiones y puntos de montaje:

lsblk -o NAME,MODEL,SERIAL,SIZE,TYPE,FSTYPE,MOUNTPOINTS

Para obtener un inventario general del hardware:

sudo lshw -short

Los dispositivos PCI pueden consultarse con:

lspci

Si alguna de estas herramientas no está instalada, podremos añadirla desde los repositorios de la distribución.

En Debian y Ubuntu:

sudo apt update
sudo apt install stress-ng memtester smartmontools hdparm lm-sensors lshw

En Fedora, Rocky Linux o AlmaLinux:

sudo dnf install stress-ng memtester smartmontools hdparm lm_sensors lshw

Comprobar el procesador con stress-ng

stress-ng permite someter el procesador y otros subsistemas a una carga controlada. No es una herramienta de medición del rendimiento, sino una utilidad para localizar inestabilidad, sobrecalentamiento y errores que aparecen bajo carga.

Podemos detectar el número de procesadores lógicos y ejecutar una prueba de cinco minutos:

(No ejecutar en producción.
Recomendable detener previamente los servicios importantes o hacerlo en modo mantenimiento)

CPU_WORKERS=$(nproc)
sudo stress-ng --cpu "$CPU_WORKERS" --timeout 5m --metrics-brief --verify

La opción --verify activa comprobaciones adicionales en las pruebas que las admiten.

Durante el proceso conviene observar los mensajes del núcleo desde otra sesión:

sudo journalctl -kf

También podemos vigilar las temperaturas. Primero detectamos los sensores:

sudo sensors-detect

Después mostramos sus lecturas:

watch -n 2 sensors

Una temperatura excesiva, errores de cálculo, bloqueos o reinicios inesperados pueden indicar problemas de refrigeración, alimentación, placa base o procesador.

Para una prueba combinada de CPU y memoria:

(No ejecutar en producción. 
Recomendable detener previamente los servicios importantes o hacerlo en modo mantenimiento)

sudo stress-ng \
  --cpu "$(nproc)" \
  --vm 2 \
  --vm-bytes 70% \
  --timeout 10m \
  --metrics-brief \
  --verify

No conviene ejecutar estas pruebas en un servidor de producción que atiende servicios críticos, ya que utilizarán gran parte de los recursos disponibles.

Analizar la memoria RAM

Los fallos de memoria pueden provocar síntomas muy variados: bloqueos, procesos que terminan sin explicación, archivos dañados, errores del núcleo y reinicios aleatorios.

Una primera comprobación puede realizarse desde Linux con memtester. Para probar, por ejemplo, 4 GB durante una pasada:

(No ejecutar en producción. 
Recomendable detener previamente los servicios importantes o hacerlo en modo mantenimiento)

sudo memtester 4G 1

Debemos ajustar la cantidad para no ocupar toda la memoria disponible. Puede calcularse una cifra dejando aproximadamente 1 GB libre:

(No ejecutar en producción. 
Recomendable detener previamente los servicios importantes o hacerlo en modo mantenimiento)

RAM_MB=$(awk '$1=="MemAvailable:" {printf "%d", $2/1024-1024}' /proc/meminfo)
sudo memtester "${RAM_MB}M" 1

Antes de ejecutarlo, hay que comprobar que el resultado de RAM_MB sea positivo y razonable:

echo "$RAM_MB"

memtester solo puede analizar la memoria que el sistema operativo consigue reservar. Para una comprobación más completa es preferible arrancar Memtest86+ desde GRUB, una imagen ISO o una memoria USB.

Memtest86+ se ejecuta fuera del sistema operativo y puede examinar una proporción mayor de la RAM. Lo recomendable es completar varias pasadas, especialmente cuando los errores aparecen de forma intermitente.

Si se detectan errores y el servidor tiene varios módulos, el procedimiento habitual consiste en probarlos por separado o intercambiar sus posiciones. En sistemas con memoria ECC también debemos revisar los registros EDAC:

dmesg -T | grep -iE 'edac|ecc|corrected|uncorrected'

Los errores corregidos repetitivos no deben ignorarse. Aunque el sistema continúe funcionando, pueden anticipar el deterioro de un módulo.

Comprobar discos SATA, SAS y NVMe

smartctl, incluido en el paquete Smartmontools, permite consultar la información SMART registrada por las unidades.

Primero identificamos los discos:

lsblk -d -o NAME,MODEL,SERIAL,SIZE,TRAN

Para consultar un disco SATA:

sudo smartctl -a /dev/sda

Para una unidad NVMe:

sudo smartctl -a /dev/nvme0

En discos SATA conviene prestar atención a valores como:

• Sectores reasignados.
• Sectores pendientes.
• Sectores no corregibles.
• Errores de interfaz.
• Temperatura.
• Horas de funcionamiento.
• Registro de errores SMART.

En unidades NVMe debemos revisar especialmente:

• Critical Warning.
• Media and Data Integrity Errors.
• Error Information Log Entries.
• Temperatura.
• Porcentaje de vida consumida.
• Cantidad de repuestos disponibles.

Podemos iniciar una prueba corta:

Las autopruebas SMART pueden ejecutarse con la unidad montada. La prueba extendida puede afectar al rendimiento, por lo que conviene iniciarla durante una franja de poca actividad. Si el disco ya presenta errores, realiza primero una copia de seguridad. Bajo tu responsabilidad.

(No ejecutar en producción. 
Recomendable detener previamente los servicios importantes o hacerlo en modo mantenimiento)

sudo smartctl -t short /dev/sda

O una prueba extendida:

(No ejecutar en producción. 
Recomendable detener previamente los servicios importantes o hacerlo en modo mantenimiento)

sudo smartctl -t long /dev/sda

El propio comando indicará cuánto tiempo necesita la unidad. La prueba continúa internamente, por lo que no hay que mantener abierta la terminal.

Cuando haya terminado, consultaremos el resultado:

sudo smartctl -l selftest /dev/sda

En una unidad NVMe podemos iniciar una autoprueba corta con:

(No ejecutar en producción. 
Recomendable detener previamente los servicios importantes o hacerlo en modo mantenimiento)

sudo smartctl -t short /dev/nvme0

Y consultar toda su información posteriormente:

sudo smartctl -a /dev/nvme0

SMART resulta muy útil, pero un estado general correcto no garantiza que la unidad esté completamente sana. Debemos valorar conjuntamente los atributos, los registros del núcleo y los errores del sistema de archivos.

Revisar el rendimiento de lectura

Una comprobación sencilla con hdparm permite detectar un disco anormalmente lento:

sudo hdparm -Tt /dev/sda

Esta medición es orientativa y puede verse afectada por la caché, el controlador, el RAID y la actividad del servidor.

También podemos realizar una lectura completa sin escribir en la unidad:

(No ejecutar en producción) Hacerlo en modo mantenimiento

sudo dd if=/dev/sda of=/dev/null bs=16M status=progress

Esta operación somete el disco a una lectura secuencial y puede tardar bastante. No debemos confundirla con una prueba destructiva: en este caso los datos se leen y se descartan, pero no se escriben en el dispositivo.

Nunca debe utilizarse el disco como destino de dd sin comprender exactamente el comando, porque una orden incorrecta puede sobrescribir toda la información.

Comprobar el RAID por software

En servidores con RAID administrado mediante mdadm, podemos ver el estado general con:

cat /proc/mdstat

Para obtener los detalles de un conjunto concreto:

sudo mdadm --detail /dev/md0

Debemos comprobar que todos los dispositivos esperados estén activos y que el conjunto no aparezca degradado.

Los caracteres que muestra /proc/mdstat ayudan a identificar el estado de los discos. Por ejemplo:

[UU]

indica que dos miembros están activos. Una salida como esta:

[U_]

revela que falta uno de ellos.

Aunque el RAID aparezca operativo, debemos consultar SMART individualmente en cada disco físico. El RAID aporta redundancia, pero no sustituye la monitorización ni las copias de seguridad.

Verificar el sistema de archivos con fsck

fsck comprueba y, cuando se autoriza, repara incoherencias del sistema de archivos.

Antes de utilizarlo debemos identificar correctamente la partición:

lsblk -f

La partición debe estar desmontada:

(No ejecutar en producción) Hacerlo en modo mantenimiento

sudo umount /dev/sda2

Después podemos iniciar la comprobación:

(No ejecutar en producción) Hacerlo en modo mantenimiento

sudo fsck -f /dev/sda2

Si deseamos responder afirmativamente a todas las reparaciones propuestas:

(No ejecutar en producción) Hacerlo en modo mantenimiento

sudo fsck -fy /dev/sda2

Esta última opción modifica el sistema de archivos automáticamente y debe utilizarse con prudencia, preferiblemente después de realizar una copia de seguridad.

No debemos ejecutar fsck sobre una partición montada y en uso. Para revisar la partición raíz será necesario arrancar desde un entorno de rescate.

En sistemas XFS se utilizan herramientas específicas:

(No ejecutar en producción) Hacerlo en modo mantenimiento

sudo xfs_repair -n /dev/sda2

La opción -n efectúa una comprobación sin modificar el sistema de archivos. Para reparar realmente habrá que desmontarlo y ejecutar xfs_repair sin esa opción.

Diagnosticar la conexión de red

Una conexión lenta no implica necesariamente una avería de la tarjeta de red. El problema también puede estar en el cable, el puerto del conmutador, la negociación del enlace, la ruta o la congestión.

Primero consultamos las interfaces:

ip -br link
ip -br address

Para conocer la velocidad negociada y el estado físico del enlace:

sudo ethtool eth0

Debemos sustituir eth0 por el nombre real de la interfaz. Nos interesa comprobar especialmente:

Speed
Duplex
Link detected

Los contadores de errores pueden consultarse con:

ip -s link show eth0

Y con mayor detalle:

sudo ethtool -S eth0

Un aumento continuado de errores, paquetes descartados o fallos CRC puede apuntar a un problema del cableado, el puerto o la interfaz.

Para comprobar la latencia y las pérdidas:

ping -c 20 1.1.1.1

Una prueba de ancho de banda más fiable entre dos servidores puede realizarse con iperf3.

En el servidor receptor:

(No ejecutar en producción) Hacerlo en modo mantenimiento

iperf3 -s

En el servidor que queremos comprobar:

(No ejecutar en producción) Hacerlo en modo mantenimiento

iperf3 -c DIRECCION_IP_DEL_RECEPTOR

Para probar el sentido inverso:

(No ejecutar en producción) Hacerlo en modo mantenimiento

iperf3 -c DIRECCION_IP_DEL_RECEPTOR -R

Recopilar información para solicitar una reparación

Cuando las pruebas confirmen o hagan sospechar un fallo físico, debemos conservar las evidencias.

Resulta útil guardar:

• Fecha y hora exactas de los incidentes.
• Salida de dmesg y journalctl.
• Resultado completo de smartctl.
• Registro de las autopruebas SMART.
• Errores detectados por Memtest86+ o memtester.
• Temperaturas alcanzadas durante la prueba.
• Estado del RAID.
• Modelo y número de serie del componente.
• Pasos necesarios para reproducir el fallo.

Podemos guardar algunos datos básicos en archivos:

sudo smartctl -a /dev/sda > smart-sda.txt
sudo journalctl -k -b > kernel-actual.txt
sudo lshw > inventario-hardware.txt

Un diagnóstico bien documentado facilita distinguir entre una incidencia de software y una avería física. También reduce el tiempo necesario para localizar y sustituir el componente afectado.

Fuentes y documentación técnica

• Documentación oficial de Smartmontools
• Proyecto oficial stress-ng
• Sitio oficial de Memtest86+
• Manual de iperf3

¿Es necesario arrancar Linux en modo rescate?

Depende de la prueba que vayamos a realizar. Algunas comprobaciones pueden ejecutarse con el servidor funcionando, mientras que otras necesitan detener los servicios, desmontar las particiones o arrancar desde un sistema de rescate.

Pruebas que pueden realizarse con el servidor iniciado

Estas comprobaciones no requieren desmontar los discos:

• Consultar los registros con dmesg y journalctl.
• Identificar el hardware con lscpu, lsblk, lspci y lshw.
• Consultar los datos SMART con smartctl -a.
• Iniciar autopruebas SMART cortas o extendidas.
• Comprobar el estado del RAID con cat /proc/mdstat y mdadm --detail.
• Consultar temperaturas mediante sensors.
• Revisar interfaces y contadores de red con ip y ethtool.
• Realizar pruebas de conectividad con ping e iperf3.

Aunque estas pruebas pueden ejecutarse con el sistema iniciado, algunas consumen recursos o afectan al rendimiento. Conviene realizarlas durante una franja de poca actividad.

Pruebas que requieren una ventana de mantenimiento

Las pruebas de carga con stress-ng, memtester, dd o hdparm pueden ejecutarse desde el sistema instalado, pero es recomendable detener previamente los servicios importantes.

Estas herramientas pueden utilizar intensamente el procesador, la memoria o los discos. En un servidor de producción podrían provocar lentitud, interrupciones o la finalización de procesos por falta de memoria.

Antes de ejecutarlas debemos:

• Detener máquinas virtuales y contenedores.
• Parar bases de datos y servicios críticos.
• Comprobar que existe una copia de seguridad.
• Mantener abierta una consola remota.
• Vigilar las temperaturas y los registros del núcleo.

Pruebas que deben realizarse desde un sistema de rescate

Las comprobaciones y reparaciones del sistema de archivos deben efectuarse con la partición desmontada. Esto afecta especialmente a:

fsck

y:

xfs_repair

No debemos ejecutar estas herramientas sobre una partición montada y en uso. Si queremos comprobar la partición raíz, tendremos que arrancar el servidor desde un sistema de rescate, una distribución Live o cualquier entorno externo que permita mantenerla desmontada.

Una prueba completa de la memoria con Memtest86+ también requiere reiniciar el servidor, ya que la herramienta se ejecuta fuera del sistema operativo.

Resumen rápido

• dmesg, journalctl, SMART, RAID y red: pueden comprobarse con el servidor iniciado.
• stress-ng, memtester, dd y hdparm: requieren una ventana de mantenimiento.
• fsck y xfs_repair: partición desmontada y, para la raíz, sistema de rescate.
• Memtest86+: reinicio y ejecución fuera de Linux.

Si existen dudas sobre una prueba, lo más seguro es programar una parada y ejecutarla desde un entorno de rescate. Así evitaremos que la actividad de las aplicaciones altere los resultados o que una reparación afecte a datos en uso.