Serveur qui part en couille

23 réponses

Page 1 2

Auteur	Message
mirage \| Modérateur Inscrit le : 04/05/2005	# Le 22/06/2009 à 16:19 Salut, J'ai une machine qui part en couille depuis ce midi. Elle devient inaccessible (ping ok mais tout le reste est hs) si bien que je suis obligé de demander un hard reboot chez OVH. J'en suis au 5ème depuis 13h. Je ne sais pas trop ce qu'il se passe, si ce n'est que le load average approche les 150 avant que la machine ne "plante". Je ne sais pas trop où explorer ni trop quoi faire. J'ai regardé les logs et rien vu d'anormal à priori. Les courbes de trafic OVH sont "normales" (avec des énormes trous pendant les coupures). Une idée ? NB : A peine le temps d'écrire le message que je viens de nouveau de perdre l'accès à la machine
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 22/06/2009 à 16:24 Hello, difficile d'en deviner la cause "au pif" ; néanmoins pour une perte complète de l'accès c'est souvent un problème de saturation mémoire mais qui peut être provoqué par autre chose... bref, ça n'aide pas beaucoup si ce n'est que cela implique souvent des limites Apache ou MySQL bien trop hautes. Si tu récupères l'accès, coupe ces principaux services afin d'essayer de faire un diagnostique. edit : et regarde l'état du RAID, j'accumule un nombre impressionnant de RAID qui sautent chez OVH. daevel : infogérance et conseil \|\| moi
mirage \| Vincent Modérateur Inscrit le : 04/05/2005	# Le 22/06/2009 à 16:42 Pas de RAID sur cette machine mais il semblerait qu'Apache soit une des raisons du problème (plein de defunct). Quand je récupère l'accès (que je viens, encore une fois, de perdre), je coupe.
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 22/06/2009 à 16:44 Y a un joli script qui traine en ce moment et qui permet de faire tomber tous les Apache prefork... c'est peut être ça Normalement ça ne fait "que" bloquer ton Apache, mais si celui ci a un nombre de "maxclient" trop élevé, il va saturer la mémoire et tout planter. daevel : infogérance et conseil \|\| moi
Akarys \| Thierry Membre Inscrit le : 19/01/2008	# Le 23/06/2009 à 05:36 Bool a dit : Y a un joli script qui traine en ce moment et qui permet de faire tomber tous les Apache prefork... Bonjour Bool, Tu aurais plus de détails sur ce point/script ? J'ai un petit serveur avec normalement un load de 0.1 dont Apache s'emballe 2 ou 3 fois par jour depuis 2 semaines (load > 10) , et je n'ai toujours pas trouvé pourquoi... Comme palliatif j'ai mis un cron qui surveille /proc/loadavg et redémarre Apache s'il bloque, mais c'est pas l'idéal.
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 23/06/2009 à 07:13 C'est juste un script qui ouvre des dizaines/centaines de sockets sur un site, sans les refermer. Rien de nouveau, juste qu'auparavant à priori il n'existait pas de script "tout prêt" pour ça. http://ha.ckers.org/blog/20090617/slowloris-http-d... daevel : infogérance et conseil \|\| moi
Akarys \| Thierry Membre Inscrit le : 19/01/2008	# Le 23/06/2009 à 11:47 Merci Bool. Rien de bien neuf en effet, mais une discussion intéressante (quoique un peu longue). Un des problèmes avec ce genre d'attaque (qui n'est pas forcément mon cas) est que ces requêtes vides ne sont pas loguées par Apache. J'ai mis un netstat dans le rapport envoyé par mon script, mais rien de concluant à ce jour. A suivre...
mirage \| Vincent Modérateur Inscrit le : 04/05/2005	# Le 26/06/2009 à 09:22 Je viens de louer deux nouveaux serveurs et, sans même que je n'installe quoi que ce soit, je n'arrive pas à y accéder. Les machines saturent, LA hyper haut, ping ok mais tous les services sont hs (hard reboot obligé), mais pas de trace de ce dont tu parlais l'autre jour Bool dans les logs Apache. Quelqu'un a-t-il le même problème ?
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 26/06/2009 à 09:27 Attention avec les machines OVH aussi : à la livraison le RAID est souvent en cours d'initialisation, si bien que la machine est lente durant 12 à 24 heures. Si tu y vas à coup d'hard reboot, c'est pas près de se finaliser. daevel : infogérance et conseil \|\| moi
mirage \| Vincent Modérateur Inscrit le : 04/05/2005	# Le 26/06/2009 à 11:10 Y a pas de raid, ce sont des Kimsufi.
mirage \| Vincent Modérateur Inscrit le : 04/05/2005	# Le 26/06/2009 à 11:33 Apache, mySQL, Bind, Postfix (juste pour de l'envoi local) et vsFTPd. Il n'y a pas eu de passage en prod, juste une tentative mais quand j'ai vu la tronche que tirait la machine, j'ai fait marche arrière.
mirage \| Vincent Modérateur Inscrit le : 04/05/2005	# Le 26/06/2009 à 13:07 J'avais personnalisé suivant les modes de calcul donnés ici puis j'ai remis les paramètres par défaut, en vain. Là j'ai coupé Apache, le temps de pouvoir regarder ce qu'il se passe vraiment...
Julgates \| Julien Administrateur Inscrit le : 09/03/2005	# Le 29/06/2009 à 11:38 Alors mirage tu as trouvé ? J'ai aussi mon apache qui part en live, au début j'ai pensé que c'était du à un .log qui n'avait pas rotationné assez vite (> 2 Go) mais en le virant et en redémarrant ça charge toujours... Shopping Time Network - Founder / CTO
mirage \| Vincent Modérateur Inscrit le : 04/05/2005	# Le 29/06/2009 à 11:52 Non, pas trouvé d'où ça venait.
Liliandev \| Lilian Membre Inscrit le : 06/03/2009	# Le 01/07/2009 à 00:57 Moi je dis RAM en cause ... Oom-Killer quand tu nous tiens ... Que dit la machine dans le dmesg ? Lilian \| High-Tech - Communauté Webmaster - Communauté Informatique - Comparateur de prix
Akarys \| Thierry Membre Inscrit le : 19/01/2008	# Le 01/07/2009 à 13:07 Bonjour, Je ne sais pas si ça pourra aider les personnes concernées, mais pour moi le problème vient de process apache qui restent en CLOSE_WAIT : "tcp nn nn ip:80 ip:nnnn CLOSE_WAIT nnnn/apache" Un "netstat -tanpu \| grep -v TIME_WAIT" placé dans un cron de surveillance m'a clairement montré le phénomène. Des heures sans aucun, puis 1, puis en quelques secondes 2..3..4.. et dès que ce nombre approche du MaxClient... Apache ne répond plus... Ne me reste plus qu'à trouver ce qui empêche ces "apache" de finir comme il faut... ??
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 01/07/2009 à 13:10 Akarys : c'est pas justement le problème provoqué par slowloris ça ? Des tas de connexions ouvertes en boucle, qui ne sont "jamais" fermées. daevel : infogérance et conseil \|\| moi
caaptusss \| Jérémy Membre Inscrit le : 25/09/2007	# Le 01/07/2009 à 13:12 Deux solutions possible face à ça : 1) Mettre le keepAlive à off => Permet de fermer les processus dès l'envoi des données. A défaut de l'envoi, règle le timeout sur 10 secondes (souvent suffisant pour envoyer une page web, sauf pour le bas débit mais c'est marginal); 2) Baisse le maxclient pour éviter tout dépassement de mémoire (surtout avec un keepalive à off). Rajoute un petit cron qui relance apache toutes les 15 minutes ou un cron qui relance apache si le load average dépasse un certain chiffre correspondant pour toi à un plantage et le tour sera joué. L'ensemble de mon réseau répond à ces règles, j'ai fait passer le taux de disponibilité de 84 % (pas super) à 97 %. FirstHeberg.com
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 01/07/2009 à 13:22 Le keepalive permet d'éviter au client de devoir ré-établir une connexion TCP pour chaque fichier téléchargé. Je trouve dommage de le désactiver à cause d'un problème de conception d'Apache. Mais là ça ne correspond pas aux sockets CLOSE_WAIT : par exemple j'ai un serveur avec 11'152 slots en KeepAlive, et justement 11'674 sockets en ESTABLISHED et aucun en CLOSE_WAIT. Par contre tu as raison sur le fait qu'une saturation des slots Apache ne devrait pas faire planter le serveur en saturant la mémoire : cela impliquerait que le nombre de slots autorisés est configuré beaucoup trop haut. Pour ce qui est du restart à l'aveugle des services faute de corriger les problèmes, je crois que tu connais déjà mon opinion là dessus ;) daevel : infogérance et conseil \|\| moi
mirage \| Vincent Modérateur Inscrit le : 04/05/2005	# Le 01/07/2009 à 13:43 Bool a dit : Pour ce qui est du restart à l'aveugle des services faute de corriger les problèmes, je crois que tu connais déjà mon opinion là dessus ;) +1 Personnellement, j'ai réinstallé la machine et je n'y ai pas retouché. Je pense qu'il y a eu un mélange de mauvaise configuration et peut être de la saloperie qui traine en ce moment.

Auteur

Message

Inscrit le : 04/05/2005

# Le 22/06/2009 à 16:19

Salut,

J'ai une machine qui part en couille depuis ce midi. Elle devient inaccessible (ping ok mais tout le reste est hs) si bien que je suis obligé de demander un hard reboot chez OVH. J'en suis au 5ème depuis 13h.

Je ne sais pas trop ce qu'il se passe, si ce n'est que le load average approche les 150 avant que la machine ne "plante".

Je ne sais pas trop où explorer ni trop quoi faire. J'ai regardé les logs et rien vu d'anormal à priori. Les courbes de trafic OVH sont "normales" (avec des énormes trous pendant les coupures).

Une idée ?

NB : A peine le temps d'écrire le message que je viens de nouveau de perdre l'accès à la machine

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 22/06/2009 à 16:24

Hello,

difficile d'en deviner la cause "au pif" ; néanmoins pour une perte complète de l'accès c'est souvent un problème de saturation mémoire mais qui peut être provoqué par autre chose... bref, ça n'aide pas beaucoup si ce n'est que cela implique souvent des limites Apache ou MySQL bien trop hautes.

Si tu récupères l'accès, coupe ces principaux services afin d'essayer de faire un diagnostique.

edit : et regarde l'état du RAID, j'accumule un nombre impressionnant de RAID qui sautent chez OVH.

daevel : infogérance et conseil || moi

mirage | Vincent
Modérateur

Inscrit le : 04/05/2005

# Le 22/06/2009 à 16:42

Pas de RAID sur cette machine mais il semblerait qu'Apache soit une des raisons du problème (plein de defunct). Quand je récupère l'accès (que je viens, encore une fois, de perdre), je coupe.

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 22/06/2009 à 16:44

Y a un joli script qui traine en ce moment et qui permet de faire tomber tous les Apache prefork... c'est peut être ça
Normalement ça ne fait "que" bloquer ton Apache, mais si celui ci a un nombre de "maxclient" trop élevé, il va saturer la mémoire et tout planter.

daevel : infogérance et conseil || moi

Akarys | Thierry
Membre

Inscrit le : 19/01/2008

# Le 23/06/2009 à 05:36

Bool a dit :
Y a un joli script qui traine en ce moment et qui permet de faire tomber tous les Apache prefork...

Bonjour Bool,
Tu aurais plus de détails sur ce point/script ?
J'ai un petit serveur avec normalement un load de 0.1 dont Apache s'emballe 2 ou 3 fois par jour depuis 2 semaines (load > 10) , et je n'ai toujours pas trouvé pourquoi...
Comme palliatif j'ai mis un cron qui surveille /proc/loadavg et redémarre Apache s'il bloque, mais c'est pas l'idéal.

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 23/06/2009 à 07:13

C'est juste un script qui ouvre des dizaines/centaines de sockets sur un site, sans les refermer. Rien de nouveau, juste qu'auparavant à priori il n'existait pas de script "tout prêt" pour ça.

http://ha.ckers.org/blog/20090617/slowloris-http-d...

daevel : infogérance et conseil || moi

Akarys | Thierry
Membre

Inscrit le : 19/01/2008

# Le 23/06/2009 à 11:47

Merci Bool.
Rien de bien neuf en effet, mais une discussion intéressante (quoique un peu longue).
Un des problèmes avec ce genre d'attaque (qui n'est pas forcément mon cas) est que ces requêtes vides ne sont pas loguées par Apache. J'ai mis un netstat dans le rapport envoyé par mon script, mais rien de concluant à ce jour. A suivre...

mirage | Vincent
Modérateur

Inscrit le : 04/05/2005

# Le 26/06/2009 à 09:22

Je viens de louer deux nouveaux serveurs et, sans même que je n'installe quoi que ce soit, je n'arrive pas à y accéder. Les machines saturent, LA hyper haut, ping ok mais tous les services sont hs (hard reboot obligé), mais pas de trace de ce dont tu parlais l'autre jour Bool dans les logs Apache.

Quelqu'un a-t-il le même problème ?

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 26/06/2009 à 09:27

Attention avec les machines OVH aussi : à la livraison le RAID est souvent en cours d'initialisation, si bien que la machine est lente durant 12 à 24 heures. Si tu y vas à coup d'hard reboot, c'est pas près de se finaliser.

daevel : infogérance et conseil || moi

mirage | Vincent
Modérateur

Inscrit le : 04/05/2005

# Le 26/06/2009 à 11:10

Y a pas de raid, ce sont des Kimsufi.

mirage | Vincent
Modérateur

Inscrit le : 04/05/2005

# Le 26/06/2009 à 11:33

Apache, mySQL, Bind, Postfix (juste pour de l'envoi local) et vsFTPd.

Il n'y a pas eu de passage en prod, juste une tentative mais quand j'ai vu la tronche que tirait la machine, j'ai fait marche arrière.

mirage | Vincent
Modérateur

Inscrit le : 04/05/2005

# Le 26/06/2009 à 13:07

J'avais personnalisé suivant les modes de calcul donnés ici puis j'ai remis les paramètres par défaut, en vain. Là j'ai coupé Apache, le temps de pouvoir regarder ce qu'il se passe vraiment...

Julgates | Julien
Administrateur

Inscrit le : 09/03/2005

# Le 29/06/2009 à 11:38

Alors mirage tu as trouvé ? J'ai aussi mon apache qui part en live, au début j'ai pensé que c'était du à un .log qui n'avait pas rotationné assez vite (> 2 Go) mais en le virant et en redémarrant ça charge toujours...

Shopping Time Network - Founder / CTO

mirage | Vincent
Modérateur

Inscrit le : 04/05/2005

# Le 29/06/2009 à 11:52

Non, pas trouvé d'où ça venait.

Liliandev | Lilian
Membre

Inscrit le : 06/03/2009

# Le 01/07/2009 à 00:57

Moi je dis RAM en cause ... Oom-Killer quand tu nous tiens ...

Que dit la machine dans le dmesg ?

Lilian | High-Tech - Communauté Webmaster - Communauté Informatique - Comparateur de prix

Akarys | Thierry
Membre

Inscrit le : 19/01/2008

# Le 01/07/2009 à 13:07

Bonjour,
Je ne sais pas si ça pourra aider les personnes concernées, mais pour moi le problème vient de process apache qui restent en CLOSE_WAIT : "tcp nn nn ip:80 ip:nnnn CLOSE_WAIT nnnn/apache"

Un "netstat -tanpu | grep -v TIME_WAIT" placé dans un cron de surveillance m'a clairement montré le phénomène.
Des heures sans aucun, puis 1, puis en quelques secondes 2..3..4.. et dès que ce nombre approche du MaxClient... Apache ne répond plus...
Ne me reste plus qu'à trouver ce qui empêche ces "apache" de finir comme il faut... ??

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 01/07/2009 à 13:10

Akarys : c'est pas justement le problème provoqué par slowloris ça ? Des tas de connexions ouvertes en boucle, qui ne sont "jamais" fermées.

daevel : infogérance et conseil || moi

caaptusss | Jérémy
Membre

Inscrit le : 25/09/2007

# Le 01/07/2009 à 13:12

Deux solutions possible face à ça :
1) Mettre le keepAlive à off => Permet de fermer les processus dès l'envoi des données. A défaut de l'envoi, règle le timeout sur 10 secondes (souvent suffisant pour envoyer une page web, sauf pour le bas débit mais c'est marginal);
2) Baisse le maxclient pour éviter tout dépassement de mémoire (surtout avec un keepalive à off).

Rajoute un petit cron qui relance apache toutes les 15 minutes ou un cron qui relance apache si le load average dépasse un certain chiffre correspondant pour toi à un plantage et le tour sera joué.

L'ensemble de mon réseau répond à ces règles, j'ai fait passer le taux de disponibilité de 84 % (pas super) à 97 %.

FirstHeberg.com

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 01/07/2009 à 13:22

Le keepalive permet d'éviter au client de devoir ré-établir une connexion TCP pour chaque fichier téléchargé. Je trouve dommage de le désactiver à cause d'un problème de conception d'Apache.
Mais là ça ne correspond pas aux sockets CLOSE_WAIT : par exemple j'ai un serveur avec 11'152 slots en KeepAlive, et justement 11'674 sockets en ESTABLISHED et aucun en CLOSE_WAIT.

Par contre tu as raison sur le fait qu'une saturation des slots Apache ne devrait pas faire planter le serveur en saturant la mémoire : cela impliquerait que le nombre de slots autorisés est configuré beaucoup trop haut.

Pour ce qui est du restart à l'aveugle des services faute de corriger les problèmes, je crois que tu connais déjà mon opinion là dessus ;)

daevel : infogérance et conseil || moi

mirage | Vincent
Modérateur

Inscrit le : 04/05/2005

# Le 01/07/2009 à 13:43

Bool a dit :
Pour ce qui est du restart à l'aveugle des services faute de corriger les problèmes, je crois que tu connais déjà mon opinion là dessus ;)

+1

Personnellement, j'ai réinstallé la machine et je n'y ai pas retouché. Je pense qu'il y a eu un mélange de mauvaise configuration et peut être de la saloperie qui traine en ce moment.

Page 1 2

Répondre

Vous ne pouvez pas participer au forum, car votre inscription n'a pas été validée. Pour vous faire valider en tant que Membre, cliquez ici.