Dans ce guide, nous allons examiner les principales causes de la forte charge sur un serveur virtuel et comment les résoudre.

Par exemple, lors de l'ouverture d'un site hébergé sur le serveur, on observe des retards importants et une exécution lente des commandes dans la console.

1. Vérifions la charge

Par exemple, avec un processeur de 6 cœurs, la charge maximale (Load Average - LA) sera de 6. (1 correspond à 100 % d'un cœur).

Dans notre exemple, pour vérifier ces indicateurs, nous utilisons la commande :

top

Sur la capture d'écran, nous voyons que cet indicateur est largement dépassé, ce qui indique une très forte charge sur la machine virtuelle.

Ainsi, la raison du fonctionnement lent du serveur est une surcharge importante. Dans notre exemple, nous voyons également les processus qui créent cette charge. Ils ont le statut (R) - (Run - processus actifs).

Dans la colonne COMMAND, nous voyons la commande qui consomme le plus de ressources. Dans notre exemple, il s'agit de scripts PHP.

Notez également le paramètre Tasks, qui montre le nombre de processus sur la machine virtuelle : 752, dont 40 sont actifs.

À titre d'exemple, un site avec 700 visiteurs uniques par jour et environ 21 000 visiteurs par mois, avec une configuration similaire du serveur, aurait une charge de : LA - 0,41, Tasks - 51 (2 en cours d'exécution).

Il est plus ou moins évident que le serveur est soumis à un flood ou à une attaque DOS. Il est également possible que des scripts soient exécutés pour envoyer du spam ou pour utiliser le serveur comme proxy pour attaquer d'autres ressources.

2. Solution

Il est souvent difficile de travailler efficacement dans la console lorsque la charge est élevée. Comme dans notre cas, ce sont des services web. Arrêtons-les :

service nginx stop
service apache2 stop

Dans certains cas, ces commandes peuvent prendre du temps à s'exécuter, il est donc préférable de forcer l'arrêt du processus.

Recherchez le PID des processus actifs et terminez-les en utilisant la commande suivante (où pid est l'ID du processus) :

kill -9 pid

Si la commande top met du temps à démarrer ou ralentit, utilisez ps aux avec un filtre par nom de processus :

ps aux | grep nginx

Une fois ces processus terminés, la charge devrait revenir à la normale. Ensuite, vous pouvez consulter le fichier de log des accès pour détecter les requêtes similaires et trouver le chemin vers le script. Par exemple, avec la commande tail et un filtre grep :

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

Attention ! Vous pouvez avoir un chemin et un nom de fichier de log différents.

Ensuite, supprimez les scripts malveillants. Leur date de création sera également différente de celle des fichiers principaux. Cela peut être vu en utilisant un gestionnaire de fichiers comme mc.

2.1 Recherche alternative du script générant une forte charge

Si le serveur répond à vos commandes avec un léger retard (tolérable), vous pouvez connaître le nom du fichier du script en utilisant la commande suivante (où pid est l'ID du processus PHP) :

lsof -p pid

Supprimez les fichiers malveillants et la charge du serveur devrait diminuer.

La présence de fichiers malveillants n'est pas nécessairement liée à une attaque DOS ou DDOS. Dans ce cas, vous devrez mettre en place une protection. Nous avons décrit cela plus en détail ici : Protection du serveur web contre les attaques de Flood

Ce scénario est plus probable si le serveur utilise des CMS populaires qui n'ont pas été mis à jour depuis longtemps.