Supervisión de recursos del servidor y ajuste del rendimiento

¿Qué significa realmente «rendimiento» en un servidor dedicado?

En un VPS, estás limitado por los límites flexibles establecidos por el hipervisor. Los servidores dedicados se ejecutan directamente en el hardware, por lo que tu límite de rendimiento es real. Eso equivale a la RAM física, los núcleos de CPU reales y el rendimiento de E/S de tus NVMe . Esa es una ventaja significativa, pero también significa que cuando alcanzas un límite, estás alcanzando el hardware real, no un regulador artificial.

Esa distinción es importante para la estrategia de supervisión. En una infraestructura compartida o virtualizada, un pico en el uso de la CPU puede significar que un vecino está robando recursos. En un servidor dedicado, un pico significa que tu carga de trabajo realmente exige más que antes. Ambos casos requieren atención, pero por diferentes razones.

Métricas clave que hay que seguir

Utilización de la CPU y promedio de carga

El porcentaje de CPU por sí solo ofrece una visión incompleta. Un servidor de 8 núcleos al 90 % de CPU podría funcionar bien si todos los núcleos estuvieran ejecutando tareas. Las señales de problema son:

• La carga media supera significativamente el número de núcleos: un servidor AMD EPYC 4545P de 16 núcleos con una carga media de más de 40 en un minuto significa que los procesos están haciendo cola para obtener tiempo de CPU, no solo utilizándolo. Compruébalos con uptime o cat /proc/loadavg.
• Esperas de CPU (wa) en la salida superior: un porcentaje alto de esperas de E/S significa que los procesos están bloqueados esperando lecturas o escrituras en el disco. La CPU está realmente inactiva, pero no está ocurriendo nada útil.
• Robo de tiempo en invitados virtualizados: No es relevante en bare metal; si observas robo de tiempo en un servidor «dedicado», en realidad estás en una infraestructura virtualizada.

Presión de memoria

El agotamiento de la RAM es la causa más frecuente de caídas repentinas de los servidores. Las métricas que vale la pena vigilar son:

• Memoria disponible (no memoria libre): Linux almacena de forma agresiva los datos del disco en la RAM. free -m muestra la memoria «libre» como muy baja en servidores en buen estado. La columna «disponible» es la que importa, ya que refleja la cantidad de RAM que el núcleo puede recuperar bajo demanda.
• Uso del intercambio: el uso del intercambio no es necesariamente un problema, pero el aumento de la utilización del intercambio bajo una carga normal es una señal de alarma. Una vez que las aplicaciones comienzan a leer/escribir en el intercambio, la latencia se dispara drásticamente.
• Eventos OOM killer: Comprueba /var/log/kern.log o dmesg | grep -i oom. Si el kernel está eliminando procesos para recuperar memoria, tienes un problema de capacidad.

El servidor dedicado Extreme de InMotion incluye 192 GB de RAM DDR5 ECC. Esto proporciona suficiente margen para que la mayoría de las cargas de trabajo no alcancen el límite máximo, incluso con un almacenamiento en caché agresivo. El componente ECC también es importante: los errores de memoria que podrían corromper silenciosamente los datos en el hardware de consumo se detectan y corrigen automáticamente.

E/S de disco

NVMe han transformado el rendimiento de los discos, pero incluso NVMe convertirse en un cuello de botella en cargas de trabajo con gran volumen de escritura. Métricas clave:

• iowait: En iostat -x 1, la columna %await muestra el tiempo medio por solicitud de E/S en milisegundos. Por debajo de 5 ms es un valor adecuado para NVMe. Por encima de 20 ms con una carga normal indica saturación o un fallo en la unidad.
• Profundidad de la cola: iostat -x 1 también muestra avgqu-sz. Los valores sostenidos por encima de 1-2 en una NVMe suelen indicar que el disco no puede seguir el ritmo de la tasa de E/S.
• Relación entre lectura y escritura: las cargas de trabajo con un uso intensivo de escritura desgastan más rápidamente los SSD y pueden saturar los búferes de escritura. Comprender la combinación de lectura y escritura te permite definir tanto la estrategia de almacenamiento en caché como la configuración del almacenamiento.

Rendimiento de la red y pérdida de paquetes

• Utilización del ancho de banda: utiliza iftop o nethogs para ver el uso del ancho de banda por conexión y por proceso en tiempo real.
• Retransmisiones TCP: netstat -s | grep retransmit. Un aumento en el recuento indica pérdida de paquetes entre el servidor y los clientes o la infraestructura ascendente.
• Estados de conexión: ss -s muestra el recuento de conexiones por estado. Un gran número de conexiones CLOSE_WAIT indica que el código de la aplicación no está cerrando las conexiones correctamente.

Opciones de supervisión de la pila

Netdata

Netdata es la forma más rápida de obtener métricas en tiempo real, por segundo, en un servidor Linux con una sobrecarga de configuración mínima. La instalación predeterminada del agente extrae inmediatamente las métricas de CPU, memoria, disco y red, y la granularidad por segundo capta los picos que los sistemas de supervisión con promedio por minuto pasan por alto por completo. Funciona cómodamente en servidores de producción con menos del 1 % de sobrecarga de CPU en la mayoría de las configuraciones.

Para los servidores dedicados gestionados por equipos técnicos, la exportación de métricas Prometheus de Netdata facilita la introducción de datos en los paneles de control Grafana existentes.

Prometheus + Grafana

La pila de observabilidad de código abierto estándar. Prometheus recopila métricas de los exportadores (node_exporter para métricas del sistema Linux, mysqld_exporter para MySQL, etc.) en un intervalo configurable, normalmente de 15 o 30 segundos. Grafana proporciona la capa de paneles y alertas.

Esta combinación requiere una configuración inicial mayor que Netdata, pero ofrece mucha más flexibilidad para métricas personalizadas, retención a largo plazo y visibilidad multiservidor. La mayoría de los equipos de ingeniería de producción que ejecutan más de 3-4 servidores dedicados se estandarizan en esta pila.

Monitor de recursos cPanel

Si tu servidor dedicado ejecuta cPanel, el Monitor de recursos integrado proporciona información sobre el uso de la CPU y la memoria a nivel de cuenta sin necesidad de configuración adicional. Es menos preciso que Prometheus, pero se puede utilizar de inmediato y resulta especialmente útil para identificar qué cPanel consumen recursos desproporcionados en configuraciones de revendedores o multitenant.

El paquete Premier Care de InMotion incluye supervisión proactiva por parte del equipo APS, lo que resulta especialmente útil durante el horario laboral, cuando patrones inusuales en los recursos pueden requerir la coordinación entre diagnósticos a nivel de servidor e investigaciones a nivel de aplicación.

Ajuste del rendimiento basado en lo que encuentres

Cargas de trabajo dependientes de la CPU

Si la CPU es la verdadera limitación, las opciones por orden de impacto son:

1. Profile the application: Tools like perf top or strace -c -p <pid> identify which system calls or functions consume the most CPU. Optimization at the application level almost always outperforms hardware changes.
2. Comprueba si hay tareas cron ineficientes: crontab -l y revisar /etc/cron.d/ con frecuencia revela scripts descontrolados que nunca se optimizaron porque «solo se ejecutan ocasionalmente». En los servidores modernos, «ocasionalmente» puede significar 10 segundos de 100 % de CPU cada 15 minutos.
3. Dimensionamiento del grupo de trabajadores PHP-FPM: los grupos PHP-FPM mal configurados en los servidores web suelen generar más trabajadores que la CPU disponible, lo que provoca una sobrecarga en el cambio de contexto. Haz coincidir pm.max_children con el número de núcleos de tu CPU multiplicado por un factor de concurrencia razonable (normalmente entre 2 y 4 veces para aplicaciones PHP con limitaciones de E/S).

Cargas de trabajo limitadas por la memoria

4. Redis o Memcached para el almacenamiento en caché de objetos: si tu aplicación consulta repetidamente los mismos datos en la base de datos, una caché en memoria reduce drásticamente tanto la presión sobre la memoria de la base de datos como la carga de la CPU. Las opciones de persistencia de Redis te permiten almacenar en caché de forma agresiva sin perder datos al reiniciar.
5. Ajusta innodb_buffer_pool_size de MySQL: De forma predeterminada, el búfer de InnoDB de MySQL está configurado en 128 MB, lo que resulta inútil en un servidor con más de 64 GB de RAM. Configúralo en un 70-80 % de la RAM disponible para cargas de trabajo con un uso intensivo de la base de datos. La documentación de MySQL proporciona la fórmula y las opciones de configuración.
6. Páginas enormes transparentes: en algunas cargas de trabajo, desactivar THP (echo never > /sys/kernel/mm/transparent_hugepage/enabled) reduce la latencia de la gestión de la memoria. En otras, activarlo mejora el rendimiento. Prueba con tu carga de trabajo específica.

Cargas de trabajo limitadas por E/S

7. NVMe aún no lo has hecho, cambia a NVMe : el salto de SATA SSD NVMe ofrecer un rendimiento secuencial entre 3 y 5 veces superior y una latencia significativamente menor. La actual gama de servidores dedicados de InMotion incluye NVMe .
8. Configuración RAID: RAID-1 (duplicación) proporciona redundancia sin penalizar el rendimiento de escritura, pero sin mejorar la lectura en E/S aleatorias. RAID-10 duplica tanto el rendimiento de lectura como el coste de redundancia. Adapta el nivel RAID a si necesitas aceleración de lectura, protección de escritura o ambas cosas.
9. Elección del sistema de archivos: XFS gestiona mejor los archivos grandes y las cargas de trabajo de alto rendimiento que ext4. En el caso de los servidores de bases de datos, ext4 con las opciones de montaje noatime y data=writeback reduce en gran medida la diferencia.

Establecimiento de umbrales de alerta importantes

El objetivo no es recibir una alerta cada vez que la CPU supere el 80 %. El objetivo es recibir una alerta antes de que los usuarios noten un problema.

Umbrales prácticos para las alertas de servidores dedicados:

• La carga media de la CPU supera el doble del número de núcleos durante más de 5 minutos.
• Memoria disponible por debajo del 10 % del total durante más de 10 minutos.
• La espera de E/S del disco supera los 20 ms durante más de 5 minutos.
• El uso del intercambio aumenta a cualquier ritmo durante más de 15 minutos (de forma sostenida, no un pico breve).
• Cualquier disco que muestre advertencias SMART de fallo inminente.

InMotion HostingPremier CareInMotion Hosting incluye la supervisión de servidores como parte de la capa de servicios gestionados. Para los equipos que utilizan su propia pila de supervisión, los umbrales anteriores detectan problemas reales y mantienen el nivel de alertas lo suficientemente bajo como para poder actuar.Lectura relacionada: Optimización de la latencia de red para servidores dedicados | Prácticas recomendadas para el refuerzo de servidores