En esta guía, analizaremos las principales causas de la alta carga en un servidor virtual y cómo solucionarlas.

Por ejemplo, al abrir un sitio web alojado en el servidor, se observan grandes retrasos y una ejecución lenta de los comandos en la consola.

1. Verificar la carga

Por ejemplo, si el servidor tiene 6 núcleos de CPU, la carga máxima (Load Average, LA) será 6 (1 equivale al 100 % de un núcleo).

En nuestro ejemplo, para verificar estos valores, utilizamos el comando:

top

En la captura de pantalla, vemos que este valor está significativamente superado, lo que indica una carga muy alta en la máquina virtual.

Por lo tanto, la razón del rendimiento lento del servidor es un exceso considerable de carga. En nuestro ejemplo, también vemos los procesos que están generando esta carga; tienen el estado (R) - (Run - procesos activos).

En el apartado COMMAND, podemos ver el comando que consume la mayor cantidad de recursos. En nuestro ejemplo, se trata de scripts PHP.

También presta atención al parámetro Tasks, que muestra el número de procesos en la máquina virtual: 752, de los cuales 40 están en estado activo.

Como ejemplo de funcionamiento normal de un sitio con 700 visitantes únicos al día y alrededor de 21,000 al mes, con una configuración de servidor similar, su carga sería: LA - 0.41, Tasks - 51 (2 en ejecución).

Es bastante evidente que el servidor está siendo objeto de un ataque de flood o DOS, o bien se están ejecutando scripts para enviar spam o usar el servidor como proxy para atacar otros recursos.

2. Solución

A menudo, trabajar eficazmente en la consola cuando la carga es alta resulta complicado. Dado que en nuestro caso son los servicios web, detengámoslos:

service nginx stop
service apache2 stop

En algunos casos, estos comandos pueden tardar en ejecutarse, por lo que es mejor finalizar el proceso manualmente.

Identifica el PID de los procesos activos y termínalos con el siguiente comando (donde pid es el ID del proceso):

kill -9 pid

Si el comando top tarda en arrancar o se ralentiza, utiliza ps aux con un filtro por nombre de proceso:

ps aux | grep nginx

Después de finalizar estos procesos, la carga debería volver a la normalidad. Luego, puedes revisar el archivo de registro de accesos para detectar solicitudes repetidas y averiguar la ubicación del script, utilizando el comando tail y un filtro grep:

tail -f /var/log/nginx/access.log

¡Atención! Es posible que tengas una ruta y un nombre de archivo de registro diferentes.

A continuación, elimina los scripts maliciosos, que tendrán una fecha de creación distinta a la de los archivos principales. Esto se puede observar usando un gestor de archivos como mc.

2.1 Búsqueda alternativa del script que genera una alta carga

Si el servidor responde a tus comandos con un retraso manejable, puedes identificar el nombre del archivo del script usando el comando (donde pid es el ID del proceso PHP):

lsof -p pid

Elimina los archivos maliciosos y la carga del servidor debería disminuir.

La presencia de archivos maliciosos no es obligatoria en casos de ataques DOS o DDOS. En este caso, necesitarás implementar medidas de protección, más información aquí: Protección del servidor web contra ataques Flood.

Este escenario es más probable si en el servidor se utilizan CMS populares que no han sido actualizados durante mucho tiempo.