vrobin Posté 24 Septembre 2007 Posté 24 Septembre 2007 Bonjour, Depuis vendredi, nous avons des ralentissements sur notre serveur dédié OVH. En analysant de plus près, nous avons trouvé un nombre important de processus httpd à l'état CLOSE_WAIT qui ne se termine jamais... Tous ces processus sont ouverts par l'adresse IP 66.249.66.174 qui est une adresse IP googlebot. Ce problème a commencé vendredi matin vers 1h du matin (pendant notre sauvegarde quotidienne) et dans les logs apache, ça correspond au moment où googlebot est arrivé... En redémarrant apache, ces processus disparaissent mais reviennent petit à petit... Nous devons donc redémarrer apache régulièrement pour que notre serveur continue de fonctionner correctement... Nous n'avons pas trouvé de similitude avec les cas présentés dans les guides OVH... Est-ce que quelqu'un aurait une idée pour résoudre ce problème ? Proto Recv-Q Send-Q Adresse locale Adresse distante Etat PID/Program nametcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN 6962/tcpservertcp 0 0 0.0.0.0:143 0.0.0.0:* LISTEN 19413/couriertcpdtcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 28062/httpdtcp 0 0 IP_SERVEUR:80 90.31.243.191:1499 SYN_RECV -tcp 0 0 0.0.0.0:10000 0.0.0.0:* LISTEN 32662/perltcp 0 0 IP_SERVEUR:53 0.0.0.0:* LISTEN 30015/namedtcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 30015/namedtcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 28807/ncftpdtcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 14436/sshdtcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 30015/namedtcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 8731/tcpservertcp 1 0 IP_SERVEUR:80 66.249.66.174:57066 CLOSE_WAIT 7431/httpdtcp 0 0 IP_SERVEUR:80 90.31.243.191:1206 TIME_WAIT -tcp 1 0 IP_SERVEUR:80 66.249.66.174:63473 CLOSE_WAIT 2274/httpdtcp 1 0 IP_SERVEUR:80 66.249.66.174:48369 CLOSE_WAIT 27909/httpdtcp 0 0 IP_SERVEUR:80 90.31.243.191:1205 TIME_WAIT -tcp 1 0 IP_SERVEUR:80 66.249.66.174:46530 CLOSE_WAIT 16959/httpdtcp 0 0 IP_SERVEUR:80 66.249.66.174:48581 ESTABLISHED 27871/httpdtcp 1 0 IP_SERVEUR:80 66.249.66.174:39635 CLOSE_WAIT 7182/httpdtcp 1 0 IP_SERVEUR:80 66.249.66.174:57769 CLOSE_WAIT 17784/httpdtcp 1 0 IP_SERVEUR:80 66.249.66.174:48289 CLOSE_WAIT 8875/httpdtcp 0 0 IP_SERVEUR:80 90.31.243.191:1767 TIME_WAIT -tcp 1 0 IP_SERVEUR:80 66.249.66.174:61107 CLOSE_WAIT 27270/httpdtcp 1 0 IP_SERVEUR:80 66.249.66.174:38796 CLOSE_WAIT 27704/httpdtcp 1 0 IP_SERVEUR:80 66.249.66.174:65165 CLOSE_WAIT 12289/httpdtcp 1 0 IP_SERVEUR:80 66.249.66.174:59012 CLOSE_WAIT 28901/httpdtcp 1 0 IP_SERVEUR:80 66.249.66.174:35995 CLOSE_WAIT 22518/httpdtcp 0 0 IP_SERVEUR:80 195.101.141.123:3563 TIME_WAIT -tcp 0 0 IP_SERVEUR:80 195.101.141.123:3565 ESTABLISHED 25484/httpdtcp 0 0 IP_SERVEUR:80 195.101.141.123:3564 ESTABLISHED 17110/httpdtcp 1 0 IP_SERVEUR:80 66.249.66.174:61545 CLOSE_WAIT 25139/httpdtcp 1 0 IP_SERVEUR:80 66.249.66.174:43369 CLOSE_WAIT 4730/httpdtcp 1 0 IP_SERVEUR:80 66.249.66.174:35692 CLOSE_WAIT 12422/httpdtcp 1 0 IP_SERVEUR:80 66.249.66.174:64621 CLOSE_WAIT 10336/httpdtcp 1 0 IP_SERVEUR:80 66.249.66.174:34401 CLOSE_WAIT 541/httpdtcp 1 0 IP_SERVEUR:80 66.249.66.174:57664 CLOSE_WAIT 13566/httpdtcp 1 0 IP_SERVEUR:80 66.249.66.174:34395 CLOSE_WAIT 30711/httpdtcp 0 0 IP_SERVEUR:80 195.101.141.123:2347 ESTABLISHED 12383/httpdtcp 0 0 IP_SERVEUR:80 195.101.141.123:2348 ESTABLISHED 8979/httpdtcp 1 0 IP_SERVEUR:80 66.249.66.174:64292 CLOSE_WAIT 12423/httpdtcp 1 0 IP_SERVEUR:80 66.249.66.174:43324 CLOSE_WAIT 9073/httpdtcp 0 0 IP_SERVEUR:80 195.101.141.123:1351 ESTABLISHED 30180/httpdtcp 0 0 IP_SERVEUR:80 195.101.141.123:1352 ESTABLISHED 4548/httpdtcp 1 0 IP_SERVEUR:80 66.249.66.174:60941 CLOSE_WAIT 26234/httpdtcp 1 0 IP_SERVEUR:80 66.249.66.174:50692 CLOSE_WAIT 15319/httpdtcp 1 0 IP_SERVEUR:80 66.249.66.174:55323 CLOSE_WAIT 19116/httpdtcp 1 0 IP_SERVEUR:80 66.249.66.174:55583 CLOSE_WAIT 26569/httpdudp 0 0 0.0.0.0:55690 0.0.0.0:* 30015/namedudp 0 0 IP_SERVEUR:32781 IP_SERVEUR:514 ESTABLISHED 32662/perludp 0 0 0.0.0.0:10000 0.0.0.0:* 32662/perludp 0 0 IP_SERVEUR:53 0.0.0.0:* 30015/namedudp 0 0 127.0.0.1:53 0.0.0.0:* 30015/named Merci d'avance. Valérie
Dan Posté 24 Septembre 2007 Posté 24 Septembre 2007 Que donne un "top" (10 premières lignes) sur ton serveur ? As-tu remarqué du swap ? Quelle distribution Linux tournes-tu ? As-tu IPV6 activé ?
vrobin Posté 24 Septembre 2007 Auteur Posté 24 Septembre 2007 (modifié) J'ai la release OVH 7.2. Voici le résultat de top : 92 processes: 86 sleeping, 5 running, 1 zombie, 0 stoppedCPU0 states: 99,1% user, 0,4% system, 0,0% nice, 0,0% idleCPU1 states: 100,0% user, 0,0% system, 0,0% nice, 0,0% idleMem: 1030884K av, 1010168K used, 20716K free, 0K shrd, 203388K buffSwap: 522104K av, 2820K used, 519284K free 515804K cached28901 nobody 18 0 4908 4908 4668 R 37,2 0,4 49:13 httpd29890 nobody 16 0 6712 6712 4864 R 36,2 0,6 0:08 httpd 7182 nobody 20 0 5144 5144 4800 R 34,2 0,4 38:32 httpd16959 nobody 18 0 5440 5440 4860 R 33,2 0,5 33:34 httpd12422 nobody 16 0 6604 6604 4904 R 32,3 0,6 11:10 httpd22518 nobody 9 0 7332 7332 4896 S 1,9 0,7 10:37 httpd11854 root 10 0 1044 1040 804 R 0,9 0,1 0:00 top 1 root 8 0 504 460 460 S 0,0 0,0 1:08 init 2 root 9 0 0 0 0 SW 0,0 0,0 0:00 keventd 3 root 19 19 0 0 0 SWN 0,0 0,0 0:00 ksoftirqd_CPU0 4 root 19 19 0 0 0 SWN 0,0 0,0 0:02 ksoftirqd_CPU1 5 root 9 0 0 0 0 SW 0,0 0,0 6:02 kswapd 6 root 9 0 0 0 0 SW 0,0 0,0 0:00 bdflush 7 root 9 0 0 0 0 SW 0,0 0,0 1:08 kupdated 8 root 9 0 0 0 0 SW 0,0 0,0 0:00 scsi_eh_0 IPV6 n'est pas activé : Kernel : 2.4.33grs-bipiv-ipv4-32. Pour le SWAP, y a-t-il un autre indicateur que "Swap: 522104K av" ? Autre point remarqué depuis mon 1er post : Charge CPU : 100% (même après avoir killé les processus googlebot à l'état CLOSE_WAIT) Merci d'avance ! Modifié 24 Septembre 2007 par vrobin
vrobin Posté 24 Septembre 2007 Auteur Posté 24 Septembre 2007 (modifié) Suite... La CPU est toujours à 100%... Ce sont uniquement les processus "ouverts" par googlebot qui mange toute la CPU (ceux qui apparaissent en top). Les autres processus httpd sont tout à fait normaux... Que le processus soit en close_wait ou en established, ça ne change rien en fait... On a donc carrément interdit l'accès à google pour voir et effectivement, notre CPU est redescendue à 0.xx%... Par contre, google persiste à vouloir référencer notre site : on retrouve des erreurs dans les logs apache : [Mon Sep 24 16:18:19 2007] [error] [client 66.249.66.174] client denied by server configuration: /home/toutpo/www/recherche-abc De plus, cette page n'a jamais existé !! Donc nous ne voyons pas pourquoi il cherche y accéder depuis 4 jours... Est-ce un pb de config apache ou bien est-ce dû à certains .htaccess que google n'arrive pas à interpréter ? Dans httpd.conf : <Directory /> Options Includes ExecCGI -MultiViews FollowSymLinks Indexes AllowOverride All</Directory> Les 2 htaccess qui sont sur le site : RewriteEngine onRewriteRule ^dossier-([0-9]+)-(.)*\.html$ /dossiers.php?source=$1 [L]RewriteRule ^source-([0-9]+)-(.)*\.html$ /source_web.php?source=$1 [L]RewriteRule ^cabinet-([0-9]+)-(.)*\.html$ /conseil.php?source=$1 [L]RewriteRule ^logiciel-([0-9]+)-(.)*\.html$ /logiciel.php?source=$1 [L]RewriteRule ^recherche-(.+)*\.html$ /index.php?mot_cle=$1 [L] ou RewriteEngine OnRewriteCond %{HTTP_HOST} !^www.nomdomaine.comRewriteCond %{HTTP_HOST} ^([^.]+).nomdomaine.comRewriteRule ^$ http://nomdomaine2.com/blog/%1.html [L] Modifié 24 Septembre 2007 par vrobin
Dan Posté 24 Septembre 2007 Posté 24 Septembre 2007 Pourquoi 2 .htaccess ? Dans des répertoires différents ? Lequel se trouve à la racine ? Tu devrais modifier le premier, parce qu'il convient bien pour de l'hébergement mutualisé OVH, mais est incorrect au point de vue syntaxe pour un dédié: il faut virer le / devant le second argument (à chaque ligne, si les fichiers appelés sont dans le même répertoire). Pour le swap, tu n'utilises qu'un peu plus de 2MB, donc ça va. Tu peux recompiler Apache... histoire d'être certaine que tout est correct de ce côté. Et pour le second .htaccess, pourquoi n'utilises tu pas vhost_alias à la place ?
destroyedlolo Posté 24 Septembre 2007 Posté 24 Septembre 2007 Hum, vraiment tres interessant ! Quelle est la version d'Apache que tu utilises ? Perso, j'ai le meme probleme (mais les httpd bloque ne servaient pas forcement google, ca peut etre des visiteurs normaux), mais je pensai que c'etait un bug kernel de NetBSD qui n'est pas hyper stable sur Sparc des que ca swappe. Bref, tien nous au courant.
vrobin Posté 25 Septembre 2007 Auteur Posté 25 Septembre 2007 Le verdict est tombé : le problème venait bien de mon fichier htaccess (le 1er) !! Depuis hier soir, je l'ai inactivé et notre CPU est revenue à la normale et n'a pas connu de pic ! Depuis Google a terminé ce qu'il voulait et il n'apparaît plus dans les processus... Avant de l'inactiver, je l'avais corrigé selon les conseils de Dan... Merci Dan pour cette réponse ! C'est tordu quand même que les fichiers htaccess ne fonctionnent pas de la même manière sous mutualisé et sous dédié surtout que les redirections fonctionnaient bien ! Enfin il suffit de le savoir !... Après cette correction, la CPU était remontée quand même... Grâce aux logs apache, j'ai découvert un lien qui était incorrect : "http://domaine.com/recherche-abc/abm.html" mais mon dernier slash n'aurait pas dû être là !! Forcément la règle suivante ne devait pas s'exécuter correctement : RewriteRule ^recherche-(.+)*\.html$ index.php?mot_cle=$1 [L] Du coup, google s'est mis à croire que recherche-abc était un répertoire et il s'est mis à chercher les pages http://domaine.com/recherche-abc/xxx.php qui n'existaient qu'au niveau supérieur (http://domaine.com/xxx.php). Un peu comme s'il faisait une boucle infinie... Même après avoir corrigé ce lien, la CPU restait importante. C'est à ce moment que j'ai décidé d'inactiver le htaccess... Le temps de laisser passer les choses... Là, je viens de le remettre à l'instant... RewriteEngine onRewriteRule ^dossier-([0-9]+)-(.)*\.html$ dossiers.php?source=$1 [L]RewriteRule ^source-([0-9]+)-(.)*\.html$ source_web.php?source=$1 [L]RewriteRule ^cabinet-([0-9]+)-(.)*\.html$ conseil.php?source=$1 [L]RewriteRule ^logiciel-([0-9]+)-(.)*\.html$ logiciel.php?source=$1 [L]RewriteRule ^recherche-(.+)*\.html$ index.php?mot_cle=$1 [L] Maintenant que google est parti, j'ai bien peur de ne pas voir tout de suite s'il reste des problèmes... En tout cas, je savais que l'utilisation de htaccess était sensible mais à ce point là !!! Je ne sais pas si le problème provenait de mon lien avec le slash ou s'il venait des slashs en trop dans le htaccess... Si jamais le problème réapparaît, je vous tiendrais au courant... Pour répondre à destroyedlolo, j'ai apache 1.3.37.
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant