Ralentissement serveur dû à de trop nombreux CLOSE_WAIT

vrobin · 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 name
tcp		0	  0 0.0.0.0:110			 0.0.0.0:*			   LISTEN	  6962/tcpserver
tcp		0	  0 0.0.0.0:143			 0.0.0.0:*			   LISTEN	  19413/couriertcpd
tcp		0	  0 0.0.0.0:80			  0.0.0.0:*			   LISTEN	  28062/httpd
tcp		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/perl
tcp		0	  0 IP_SERVEUR:53	  0.0.0.0:*			   LISTEN	  30015/named
tcp		0	  0 127.0.0.1:53			0.0.0.0:*			   LISTEN	  30015/named
tcp		0	  0 0.0.0.0:21			  0.0.0.0:*			   LISTEN	  28807/ncftpd
tcp		0	  0 0.0.0.0:22			  0.0.0.0:*			   LISTEN	  14436/sshd
tcp		0	  0 127.0.0.1:953		   0.0.0.0:*			   LISTEN	  30015/named
tcp		0	  0 0.0.0.0:25			  0.0.0.0:*			   LISTEN	  8731/tcpserver
tcp		1	  0 IP_SERVEUR:80	  66.249.66.174:57066	 CLOSE_WAIT  7431/httpd
tcp		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/httpd
tcp		1	  0 IP_SERVEUR:80	  66.249.66.174:48369	 CLOSE_WAIT  27909/httpd
tcp		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/httpd
tcp		0	  0 IP_SERVEUR:80	  66.249.66.174:48581	 ESTABLISHED 27871/httpd
tcp		1	  0 IP_SERVEUR:80	  66.249.66.174:39635	 CLOSE_WAIT  7182/httpd
tcp		1	  0 IP_SERVEUR:80	  66.249.66.174:57769	 CLOSE_WAIT  17784/httpd
tcp		1	  0 IP_SERVEUR:80	  66.249.66.174:48289	 CLOSE_WAIT  8875/httpd
tcp		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/httpd
tcp		1	  0 IP_SERVEUR:80	  66.249.66.174:38796	 CLOSE_WAIT  27704/httpd
tcp		1	  0 IP_SERVEUR:80	  66.249.66.174:65165	 CLOSE_WAIT  12289/httpd
tcp		1	  0 IP_SERVEUR:80	  66.249.66.174:59012	 CLOSE_WAIT  28901/httpd
tcp		1	  0 IP_SERVEUR:80	  66.249.66.174:35995	 CLOSE_WAIT  22518/httpd
tcp		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/httpd
tcp		0	  0 IP_SERVEUR:80	  195.101.141.123:3564	ESTABLISHED 17110/httpd
tcp		1	  0 IP_SERVEUR:80	  66.249.66.174:61545	 CLOSE_WAIT  25139/httpd
tcp		1	  0 IP_SERVEUR:80	  66.249.66.174:43369	 CLOSE_WAIT  4730/httpd
tcp		1	  0 IP_SERVEUR:80	  66.249.66.174:35692	 CLOSE_WAIT  12422/httpd
tcp		1	  0 IP_SERVEUR:80	  66.249.66.174:64621	 CLOSE_WAIT  10336/httpd
tcp		1	  0 IP_SERVEUR:80	  66.249.66.174:34401	 CLOSE_WAIT  541/httpd
tcp		1	  0 IP_SERVEUR:80	  66.249.66.174:57664	 CLOSE_WAIT  13566/httpd
tcp		1	  0 IP_SERVEUR:80	  66.249.66.174:34395	 CLOSE_WAIT  30711/httpd
tcp		0	  0 IP_SERVEUR:80	  195.101.141.123:2347	ESTABLISHED 12383/httpd
tcp		0	  0 IP_SERVEUR:80	  195.101.141.123:2348	ESTABLISHED 8979/httpd
tcp		1	  0 IP_SERVEUR:80	  66.249.66.174:64292	 CLOSE_WAIT  12423/httpd
tcp		1	  0 IP_SERVEUR:80	  66.249.66.174:43324	 CLOSE_WAIT  9073/httpd
tcp		0	  0 IP_SERVEUR:80	  195.101.141.123:1351	ESTABLISHED 30180/httpd
tcp		0	  0 IP_SERVEUR:80	  195.101.141.123:1352	ESTABLISHED 4548/httpd
tcp		1	  0 IP_SERVEUR:80	  66.249.66.174:60941	 CLOSE_WAIT  26234/httpd
tcp		1	  0 IP_SERVEUR:80	  66.249.66.174:50692	 CLOSE_WAIT  15319/httpd
tcp		1	  0 IP_SERVEUR:80	  66.249.66.174:55323	 CLOSE_WAIT  19116/httpd
tcp		1	  0 IP_SERVEUR:80	  66.249.66.174:55583	 CLOSE_WAIT  26569/httpd
udp		0	  0 0.0.0.0:55690		   0.0.0.0:*						   30015/named
udp		0	  0 IP_SERVEUR:32781   IP_SERVEUR:514	 	ESTABLISHED 32662/perl
udp		0	  0 0.0.0.0:10000		   0.0.0.0:*						   32662/perl
udp		0	  0 IP_SERVEUR:53	  0.0.0.0:*						   30015/named
udp		0	  0 127.0.0.1:53			0.0.0.0:*						   30015/named

Merci d'avance.

Valérie

**Dan** · 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 · 24 Septembre 2007

J'ai la release OVH 7.2.

Voici le résultat de top :

92 processes: 86 sleeping, 5 running, 1 zombie, 0 stopped
CPU0 states: 99,1% user,  0,4% system,  0,0% nice,  0,0% idle
CPU1 states: 100,0% user,  0,0% system,  0,0% nice,  0,0% idle
Mem:  1030884K av, 1010168K used,   20716K free,	   0K shrd,  203388K buff
Swap:  522104K av,	2820K used,  519284K free				  515804K cached

28901 nobody	18   0  4908 4908  4668 R	37,2  0,4  49:13 httpd
29890 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 httpd
16959 nobody	18   0  5440 5440  4860 R	33,2  0,5  33:34 httpd
12422 nobody	16   0  6604 6604  4904 R	32,3  0,6  11:10 httpd
22518 nobody	 9   0  7332 7332  4896 S	 1,9  0,7  10:37 httpd
11854 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 · 24 Septembre 2007

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 on

RewriteRule ^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 On
RewriteCond %{HTTP_HOST}	!^www.nomdomaine.com
RewriteCond %{HTTP_HOST}	^([^.]+).nomdomaine.com
RewriteRule ^$			  http://nomdomaine2.com/blog/%1.html [L]

Modifié 24 Septembre 2007 par vrobin

**Dan** · 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 · 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 · 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 on

RewriteRule ^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.

Connexion

Ralentissement serveur dû à de trop nombreux CLOSE_WAIT

Sujets conseillés

vrobin

Lien vers le commentaire

Partager sur d’autres sites

Dan

Lien vers le commentaire

Partager sur d’autres sites

vrobin

Lien vers le commentaire

Partager sur d’autres sites

vrobin

Lien vers le commentaire

Partager sur d’autres sites

Dan

Lien vers le commentaire

Partager sur d’autres sites

destroyedlolo

Lien vers le commentaire

Partager sur d’autres sites

vrobin

Lien vers le commentaire

Partager sur d’autres sites

Veuillez vous connecter pour commenter

Parcourir

Activité