PROJET AUTOBLOG


Korben

source: Korben

⇐ retour index

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

mardi 10 septembre 2013 à 12:39

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

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 Comment trouver quelle page provoque une augmentation du CPU de votre serveur

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 Comment trouver quelle page provoque une augmentation du CPU de votre serveur

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.