ams51 Posté 20 Octobre 2005 Posté 20 Octobre 2005 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 Posté 20 Octobre 2005 Posté 20 Octobre 2005 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 Posté 20 Octobre 2005 Auteur Posté 20 Octobre 2005 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 Posté 20 Octobre 2005 Auteur Posté 20 Octobre 2005 <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 Posté 20 Octobre 2005 Posté 20 Octobre 2005 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 Posté 20 Octobre 2005 Auteur Posté 20 Octobre 2005 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 Posté 20 Octobre 2005 Posté 20 Octobre 2005 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 Posté 20 Octobre 2005 Posté 20 Octobre 2005 Lance: tail -f /var/log/httpd/adserver.webdesigner-fr.com-access_log | cut -f1 -d' ' Et regarde ce fichier log... C'est normal ?
ams51 Posté 20 Octobre 2005 Auteur Posté 20 Octobre 2005 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 Posté 20 Octobre 2005 Auteur Posté 20 Octobre 2005 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 Posté 20 Octobre 2005 Auteur Posté 20 Octobre 2005 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 Posté 20 Octobre 2005 Posté 20 Octobre 2005 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 Posté 20 Octobre 2005 Auteur Posté 20 Octobre 2005 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 Posté 21 Octobre 2005 Posté 21 Octobre 2005 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 Posté 21 Octobre 2005 Auteur Posté 21 Octobre 2005 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 Posté 21 Octobre 2005 Posté 21 Octobre 2005 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 Posté 21 Octobre 2005 Auteur Posté 21 Octobre 2005 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 Posté 25 Octobre 2005 Auteur Posté 25 Octobre 2005 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 Posté 25 Octobre 2005 Posté 25 Octobre 2005 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 Posté 25 Octobre 2005 Posté 25 Octobre 2005 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 Posté 12 Novembre 2005 Auteur Posté 12 Novembre 2005 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 Posté 16 Novembre 2005 Posté 16 Novembre 2005 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.
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant