Aller au contenu
Korben, roi d’internet, logo bébé avec des lunettes en mode thug life

Comment trouver quelle page provoque une augmentation du CPU de votre serveur

Mon serveur faisait des piques au niveau CPU avec MySQL sans que je puisse déterminer avec précision quel était le problème.

J’imaginais qu’un bot bombardait une page bien précise qui faisait tourner MySQL. Du coup, j’ai cherché comment déterminer la source du problème et voici comment j’ai fait.

J’ai installé ce paquet

En passant, si vous cherchez un hébergeur web français au top, je vous conseille de jeter un œil à l’Offre Unique de o2switch. C’est puissant, illimité, et le rapport qualité-prix est imbattable pour se lancer ! (Lien partenaire)

sudo apt-get install sysstat

Ce qui m’a permis d’avoir le soft SAR qui permet de mesure la charge serveur. J’ai ouvert une première console et j’y ai entré la commande suivante :

sar -q 1

Ce qu’on va observer, c’est la colonne ldavg-1… Laissez tourner ce truc…

enorme

Au départ, c’était énorme chez moi. Donc j’ai stoppé tous les process MySQL, Apache, Nginx. J’ai attendu que la charge baisse puis j’ai relancé tout ça…

Ensuite, j’ai patienté en observant SAR. La charge stagnait autour de 10, puis d’un coup, ça s’est mis à monter progressivement.

charge

18, 31, 44…etc.

En regardant l’heure, ça a démarré vers 12h00…. Donc j’ai décidé de voir combien de requêtes j’avais reçues entre 12h00 et 12h01. Voici la commande :

egrep « 10/Sep/2013:12:00|10/Sep/2013:12:01 » /var/log/apache2/korben/access.log | wc -l

Bingo ! 1215 requêtes sur 1 minute. C’est beaucoup, mais Apache le supporte sans difficulté. Ce qui coince chez moi, c’est MySQL. Allons voir quelles requêtes sont faites à Apache durant ce laps de temps…

Pour cela, il faut entrer la commande suivante :

egrep « 10/Sep/2013:12:00|10/Sep/2013:12:01″ /var/log/apache2/korben.info/access.log | cut -d » -f2 | awk ‘{print $1  »  » $2}’ | cut -d? -f1 | sort | uniq -c | sort -n | sed ‘s/[ ]*//’

Cela sortira classé par GET ou par POST, les pages appelées durant ce laps de temps d’une minute… Voici les 2 plus gros de cette liste.

317 GET /feed
329 GET /wp-content/plugins/s2member/s2member-o.php

Quand j’ai vu /feed, mon cerveau a fait tilt… En effet, j’avais retiré par erreur cette page de la mise en cache, ce qui fait qu’à chaque fois que les agrégateurs RSS venaient taper sur mon serveur, ils se faisaient remouliner une page entière de contenu (mon flux RSS est complet), torturant par la même occasion mon serveur MySQL.

J’ai corrigé le problème et maintenant tout roule. Bon, faut que je creuse le côté s2member car ce n’est pas non plus très propre à ce niveau, mais maintenant je suis déjà un peu plus serein et mon serveur respire mieux.

J’ai conscience que cette explication s’applique à mon cas particulier, mais je pense que vous pouvez reprendre à votre compte certaines des commandes expliquées dans votre article pour mener vous aussi l’enquête.


Les articles du moment