Slots apache qui saturent

[ams51]

Bonjour,

mon problème est simple. Depuis hier je vois dans mes stats des pics dans le nombre de slots apaches. En fait j'arrive à saturation ce qui ralenti considérablement mon serveur.

Ce matin c'est pire que tout car ce pic a duré lontemps.

à votre avis d'ou peut provenir le problème et quelle solution envisager ?

[Dan]

Salut Arnaud,

Je viens de regarder dans ton crontab, et je n'ai rien trouvé qui démarre à cette heure là.

As-tu fait des manips particulières, et la charge Apache est-elle revenue elle-même à la normale ?

Les seules requêtes mysql dépassant la limite de 4 secondes pour tomber dans le slow_query.log sont celles de phpmyVisit... mais rien de très surprenant à cela.

Tu as aussi dans tes mrtg une explosion du CPU utilisé à cette heure...

Aurais-tu des requêtes Apache particulière sur ton serveur ?

Il semble que mog_gzip ait fait des siennes, tous les matins vers la même heure...

Je le désactive pour 24H, histoire d'en avoir le coeur net.

Dan

<edit: je vois aussi que tu as apporté pas mal de modifications dans le fichier httpd.conf, principalement au niveau des modules... il y a une raison ? >

[ams51]

je n'ai rien fait depuis longtemps.

La charge Apache remonte vite, le serveur est de nouveau lent après un reboot soft.

comprend pas

[ams51]

<edit: je vois aussi que tu as apporté pas mal de modifications dans le fichier httpd.conf, principalement au niveau des modules... il y a une raison ? >

<{POST_SNAPBACK}>

j'ai rien modifié !?

[Dan]

Cela doit être le fichier httpd.conf de l'ancien serveur, sur lequel tu avais apporté des modifications.

Mais je ne vois pas l'intérêt de faire un "clear modules" suivi d'un rechargement de tous les modules en séquence, alors qu'ils sont compilés par défaut

Dan

[ams51]

J'ai fait ça moi !? j'ai rarement touché le httpd.conf (à part pour jouer sur maxclients, keepalive...).

J'ai un peu regardé les guides d'OVH entre autre http://guides.ovh.net/MachineSurchargeeApache1/

En gras ce sont mes commentaires :

je met leurs commandes avec mes résultats :

# ps auxw | grep httpd | wc -l

252

# netstat -tanp | grep ESTABLISHED | grep http | wc -l

269

On va voir s'il n'y a pas une ip qui revient trop souvent.

# netstat -tanp | grep ESTABLISHED | grep http | awk {'print $5'} | sort -n

là j'ai des listes d'IP identiques assez longues

Peut-etre une attaque en synflood ?

# netstat -tanp | grep "httpd" | grep -v ESTABLISHED

là je ne sais pas interpreter ce qu'il affiche

[Dan]

La meilleure manière de voir si tu as souvent la même IP qui revient est de lancer:

tail -f /var/log/httpd/mataf-access_log | cut -f1 -d' '

Eventuellement en variant le nom du log.

Tu as effectivement quelques IP qui semblent revenir souvent.. peut-être une aspiration de site en cours ?

Dan

[Dan]

Lance:

tail -f /var/log/httpd/adserver.webdesigner-fr.com-access_log | cut -f1 -d' '

Et regarde ce fichier log... C'est normal ?

[ams51]

tail -f /var/log/httpd/mataf-access_log | cut -f1 -d' '

<{POST_SNAPBACK}>

ouch... j'ai lancé cette commande et elle n'en finie plus de me donner des IP

peut-être une aspiration de site en cours ?

<{POST_SNAPBACK}>

C'est ce que je crains. je vais mettre un filtre.

[ams51]

Lance:

tail -f /var/log/httpd/adserver.webdesigner-fr.com-access_log | cut -f1 -d' '

Et regarde ce fichier log... C'est normal ?

<{POST_SNAPBACK}>

Je ne vois rien d'anormal mais il y a des milliers d'IP qui défilent sans que je puisse les arreter !

[ams51]

J'ai mis un script pour éviter les abus des aspirateurs. On verra si ça fonctionne.

En attendant la charge est retombée aussi vite qu'elle est montée.

[Dan]

La commande "tail -f" (avec le -f pour "force" ne s'arrête qu'avec un <CTRL>-C

Normal qu'lle continue si tu la laisses tourner, c'est le but

Dan

[ams51]

ok merci ! j'avais presque tout essayé (echap, q, coup de pied sur l'écran...) mais pas ctrl-c

J'ai déjà deux IP bannies pour abus (plus de 25 pages vues par minute)

[Dan]

Assures-toi de ne pas bannir Yahoo ou Google.

Et mets des MaxHits un peu plus réalistes dans toutes les fonctions MRTG qui donnent des valeurs farfelues

Dan

[ams51]

En fait normalement les bots ne doivent pas être dégagé avec ce script mais...

Cette nuit j'ai banni googlebot

J'ai donc ajouté un bout de code :

//Ajout : Vérification des IP des robots http://www.iplists.com/
$adip=$_SERVER['REMOTE_ADDR'];
$pos = strpos($adip, '.', 3); 
$debip=substr($adip,0,$pos); // les 2 premiers parametres de l'IP

$isrobot= ( ($debip=="209.185") || ($debip=="64.209") || ($debip=="64.68") || ($debip=="66.249") || ...etc... );

if ($isrobot) {
	$limitPV=60;
}else{
	$limitPV=25;
}

J'ai une alerte email lorsque une IP est bannie et lorsqu'un bot depasse 25 pages vues par minute.

Si je vois qu'un bot depasse 60 pages vues par minute je remonterai la limite.

[Dan]

Salut Arnaud,

Plutôt que de faire des tests d'IP, utilise le UserAgent. Ce sera beaucoup plus rapide.

Le test IP est bien évidemment l'arme nécessaire pour le cloaking, mais dans le cas présent il est bien trop lourd.

C'est celui-ci qui fait que RobotStats est un "CPU Hog" vu le nombre d'adresses IP considérées.

La majorité des personnes utilisant des aspirateurs ne pensent pas à changer le UserAgent, donc un simple test sur les plus courants permettra d'éviter 90% de ces malveillants.

Une alternative est d'utiliser mod_throttle, paramétré à 60 ou 80 hits par période de 10 secondes. Cela marche très bien sur le serveur du Hub.

[ams51]

J'ai changé le test et mis le user agent.

Je faisais le test sur moins de 10 classes d'IP, je ne pense pas que ce soit gourmant en ressource.

[ams51]

Le script fonctionne relativement bien vu que je bloque au moins 3 ou 4 IP par jour. Certains essayent de se connecter à 200 ou 300 pages différentes dans la même minute.

Pour éviter les grosses erreurs je nettoie la base des IP bannie chaque nuit.

[AvenueDuWeb]

Une alternative est d'utiliser mod_throttle, paramétré à 60 ou 80 hits par période de 10 secondes. Cela marche très bien sur le serveur du Hub.

<{POST_SNAPBACK}>

C'est marrant parce que je l'ai installé y'a quelque temps et j'ai la même config (70 toutes les 10 secondes). C'est ce que j'ai trouvé de mieux en tatonnant, car dès qu'il y a des galeries d'images en dessous ça commence à être juste, et au dessus ça n'a plus beaucoup d'intérêt. Je trouve également que cela marche relativement bien. @+

[Dan]

Disons qu'avec le paramétrage à 80 cela bloque les aspirateurs, mais pas les visiteurs.

A part ceux qui n'utilisent pas le cache du navigateur.

Une page type du Hub fait tout de même beaucoup d'éléments (hits). En fait, cette page-ci fait 54 hits ... et 100 000 pages/jour ca fait du bruit sur le serveur

[ams51]

Je reviens pour conclure. Le filtre est (très) efficace, je n'ai plus de pb depuis la seconde ou je l'ai installé.

J'ai parfois 1500 tentatives de connections à l'heure pendant 2 ou 3 heures et quelques pics à 5 ou 6 connections par seconde pendant quelques minutes.

Je le recommande http://www.1001bd.com/stop_aspirateurs/

[Anonymus]

Un autre script, qui bloque très bien les aspirateurs : http://www.webmaster-hub.com/publication/article49.html

De plus, il n'utilise pas de bases de données.