Identifiez-vous Devenir membre

Rechercher

Serveur qui part en couille

30 réponses

Page 12

Auteur	Message
caaptusss 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 \| Régie Publicitaire \| Hébergement Gratuit
Bool 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 ;) Google is watching you.
mirage 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.
Akarys Membre Inscrit le : 19/01/2008	# Le 01/07/2009 à 13:54 Quelques réponses - Dans mon cas le serveur ne plante pas (MaxClient faible), simplement plus personne ne peut entrer chez apache vu que les CLOSE_WAIT qui ont décidé de ne pas sortir finissent par occuper toutes les places . - Je ne pense pas que ce soit une attaque ou du slowloris. Ce n'est pas spécialement violent et j'ai déjà trouvé du GoogleBot en CLOSE_WAIT. (Il est en général quasi seul la nuit sur ce serveur). - @caaptus: J'avais déjà indiqué : "j'ai mis un cron qui surveille /proc/loadavg et redémarre Apache s'il bloque (ou va bloquer!) mais c'est pas l'idéal.". Redémarrer apache toutes les 15 min !! - modifier le keepalive pour ça ne serait pas justifié, comme le dit Bool. Il se trouve qu'il l'est déjà dans ce cas qui ne génère que des pages dynamiques et utilise un hébergement mutu pour tout ce qui est statique. - je vais surveiller de plus près ces CLOSE_WAIT maintenant, et vais trouver ...! à suivre...
dob Modérateur Inscrit le : 10/05/2005	# Le 01/07/2009 à 14:20 Je surveille tous les statuts TCP désormais au lieu des principaux, si un serveur de Julgates repart en vrille on pourra regarder ce que ça fait... Mais il faut bien garder à l'esprit que les connexions peuvent aussi bien rester actives à cause d'une attaque qui ne les ferme pas, qu'à cause d'un apache qui n'arrive plus à les fermer. C'est plus un symptôme qu'une cause à mon avis. Julien Tartarin Founder & CTO @ Mailjet.com
dob Modérateur Inscrit le : 10/05/2005	# Le 01/07/2009 à 15:38 J'ai fait un test avec slowloris.pl, c'est impressionnant à quelle vitesse un Apache arrête de répondre... Cela dit, aucune montée du load average sur le serveur victime, par contre beaucoup de connexions TCP ESTABLISHED et FIN_WAIT2 (= le local a envoyé un signal de fermeture, mais il faut que le distant fasse de même). Et aussitôt le script coupé, tout redevient accessible. Julien Tartarin Founder & CTO @ Mailjet.com
Julgates Administrateur Inscrit le : 09/03/2005	# Le 01/07/2009 à 23:34 Après coup je pense qu'il y a vraiment un simple problème de réglage sur ce serv (je ne pense pas à un pb matériel), puisque c'est un serveur SQL dédié à la base, et l'installation d'apache2 a été faite en copiant une config apache1 qui ne doit pas être pleinement adaptée. Beyoung Interactive - Consultant web
cerise Membre Inscrit le : 31/10/2008	# Le 02/07/2009 à 07:48 Julgates j'ai eu un soucis de charge serveur trop élevée sur debian aussi en juin sur un serveur qui tournait très bien il s'est mis à monter en charge avec un loadavg constamment supérieur à 4 et des pics à 12 sur un serveur qui normalement ne dépassait jamais 2. Ovh m'a alerté également d'une température CPU anormale, très élevée. C'est apache qui en était la cause et la machine plantait régulièrement au bout d'un moment avec des tas de connexions pas fermées. J'ai baissé les Keepalive, ajusté les réglages et il y a eu un mieux mais pas un fonctionnement normal non plus et toujours des montées en charge par moment... Et puis fin juin, lors d'un apt-get update, il y a eu une mise à jour d'apache et depuis tout est revenu à la normal, le loadavg a chuté d'un coup et il est même encore plus bas qu'avant. Je pense que comme l'a dit bool, il y a un truc pas net au niveau apache qui doit trainer, et des correctifs ont été faits CeriseClub
Akarys Membre Inscrit le : 19/01/2008	# Le 02/07/2009 à 13:25 Une piste ? J'ai laissé tourner tout l'après-midi cette bête commande bash : while true; do date; netstat -tanpu \| grep CLOSE_WAIT \| ccze -A; sleep 10; done Globalement il s'est contenté d'égrener le temps, mais par 2 fois sur 10/15 minutes j'ai eu 5 à 10 CLOSE_WAIT simultanés, avec des ip apparaissant moins d'1 minute à chaque fois. Ces IP apparaissaient en état 'D' dans /server-status et j'ai vu qu'à cet instant je ne pouvais pas résoudre l'adresse IP. Par exemple : $ time host 91.91.220.52 ;; connection timed out; no servers could be reached real 0m14.011s et le timeout de 10 à 20 secondes, c'est long ! J'ai eu de TRES nombreuses IP de gaoland.net qui semble avoir des soucis de DNS car 10 minutes plus tard $ time host 91.91.220.52 52.220.91.91.in-addr.arpa domain name pointer 52.220.91-91.rev.gaoland.net. real 0m0.012s Je n'ai pas de gethostbyaddr() sur le site en question, donc je suppose que ça bloque au niveau du reverseip pour les log apache (HostnameLookups à "On"). Je ne suis pas du tout spécialiste de Bind9 ou des Timeout autour des DNS, mais vais maintenant surveiller ce point qui suffirait à expliquer la "saturation" apache si le nombre d'IP Gaoland (ou autre?) devient trop important ... A suivre...
dob Modérateur Inscrit le : 10/05/2005	# Le 06/07/2009 à 11:22 En général il est recommandé de désactiver la résolution du reverse ip... d'ailleurs c'est le comportement par défaut maintenant. Julien Tartarin Founder & CTO @ Mailjet.com
dob Modérateur Inscrit le : 10/05/2005	# Le 02/09/2009 à 17:53 Petit up : Pour Apache -> ftp://ftp.monshouwer.eu/pub/linux/mod_antiloris/ Ça marche très bien, tout simplement en limitant le nombre de requêtes en état READ par IP, à partir du scoreboard d'Apache. Julien Tartarin Founder & CTO @ Mailjet.com

Auteur

Message

caaptusss
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 | Régie Publicitaire | Hébergement Gratuit

Bool
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 ;)

Google is watching you.

mirage
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.

Akarys
Membre

Inscrit le : 19/01/2008

# Le 01/07/2009 à 13:54

Quelques réponses
- Dans mon cas le serveur ne plante pas (MaxClient faible), simplement plus personne ne peut entrer chez apache vu que les CLOSE_WAIT qui ont décidé de ne pas sortir finissent par occuper toutes les places .
- Je ne pense pas que ce soit une attaque ou du slowloris. Ce n'est pas spécialement violent et j'ai déjà trouvé du GoogleBot en CLOSE_WAIT. (Il est en général quasi seul la nuit sur ce serveur).
- @caaptus: J'avais déjà indiqué : "j'ai mis un cron qui surveille /proc/loadavg et redémarre Apache s'il bloque (ou va bloquer!) mais c'est pas l'idéal.". Redémarrer apache toutes les 15 min !!
- modifier le keepalive pour ça ne serait pas justifié, comme le dit Bool. Il se trouve qu'il l'est déjà dans ce cas qui ne génère que des pages dynamiques et utilise un hébergement mutu pour tout ce qui est statique.
- je vais surveiller de plus près ces CLOSE_WAIT maintenant, et vais trouver ...!
à suivre...

dob
Modérateur

Inscrit le : 10/05/2005

# Le 01/07/2009 à 14:20

Je surveille tous les statuts TCP désormais au lieu des principaux, si un serveur de Julgates repart en vrille on pourra regarder ce que ça fait...

Mais il faut bien garder à l'esprit que les connexions peuvent aussi bien rester actives à cause d'une attaque qui ne les ferme pas, qu'à cause d'un apache qui n'arrive plus à les fermer. C'est plus un symptôme qu'une cause à mon avis.

Julien Tartarin
Founder & CTO @ Mailjet.com

dob
Modérateur

Inscrit le : 10/05/2005

# Le 01/07/2009 à 15:38

J'ai fait un test avec slowloris.pl, c'est impressionnant à quelle vitesse un Apache arrête de répondre...
Cela dit, aucune montée du load average sur le serveur victime, par contre beaucoup de connexions TCP ESTABLISHED et FIN_WAIT2 (= le local a envoyé un signal de fermeture, mais il faut que le distant fasse de même).
Et aussitôt le script coupé, tout redevient accessible.

Julien Tartarin
Founder & CTO @ Mailjet.com

Julgates
Administrateur

Inscrit le : 09/03/2005

# Le 01/07/2009 à 23:34

Après coup je pense qu'il y a vraiment un simple problème de réglage sur ce serv (je ne pense pas à un pb matériel), puisque c'est un serveur SQL dédié à la base, et l'installation d'apache2 a été faite en copiant une config apache1 qui ne doit pas être pleinement adaptée.

Beyoung Interactive - Consultant web

cerise
Membre

Inscrit le : 31/10/2008

# Le 02/07/2009 à 07:48

Julgates j'ai eu un soucis de charge serveur trop élevée sur debian aussi en juin sur un serveur qui tournait très bien il s'est mis à monter en charge avec un loadavg constamment supérieur à 4 et des pics à 12 sur un serveur qui normalement ne dépassait jamais 2. Ovh m'a alerté également d'une température CPU anormale, très élevée.
C'est apache qui en était la cause et la machine plantait régulièrement au bout d'un moment avec des tas de connexions pas fermées. J'ai baissé les Keepalive, ajusté les réglages et il y a eu un mieux mais pas un fonctionnement normal non plus et toujours des montées en charge par moment...
Et puis fin juin, lors d'un apt-get update, il y a eu une mise à jour d'apache et depuis tout est revenu à la normal, le loadavg a chuté d'un coup et il est même encore plus bas qu'avant.
Je pense que comme l'a dit bool, il y a un truc pas net au niveau apache qui doit trainer, et des correctifs ont été faits

CeriseClub

Akarys
Membre

Inscrit le : 19/01/2008

# Le 02/07/2009 à 13:25

Une piste ?
J'ai laissé tourner tout l'après-midi cette bête commande bash :

while true; do date; netstat -tanpu | grep CLOSE_WAIT | ccze -A; sleep 10; done

Globalement il s'est contenté d'égrener le temps, mais par 2 fois sur 10/15 minutes j'ai eu 5 à 10 CLOSE_WAIT simultanés, avec des ip apparaissant moins d'1 minute à chaque fois.

Ces IP apparaissaient en état 'D' dans /server-status et j'ai vu qu'à cet instant je ne pouvais pas résoudre l'adresse IP.
Par exemple :

$ time host 91.91.220.52

;; connection timed out; no servers could be reached

real    0m14.011s

et le timeout de 10 à 20 secondes, c'est long !
J'ai eu de TRES nombreuses IP de gaoland.net qui semble avoir des soucis de DNS car 10 minutes plus tard

$ time host 91.91.220.52

52.220.91.91.in-addr.arpa domain name pointer 52.220.91-91.rev.gaoland.net.

real    0m0.012s

Je n'ai pas de gethostbyaddr() sur le site en question, donc je suppose que ça bloque au niveau du reverseip pour les log apache (HostnameLookups à "On").

Je ne suis pas du tout spécialiste de Bind9 ou des Timeout autour des DNS, mais vais maintenant surveiller ce point qui suffirait à expliquer la "saturation" apache si le nombre d'IP Gaoland (ou autre?) devient trop important ...

A suivre...

dob
Modérateur

Inscrit le : 10/05/2005

# Le 06/07/2009 à 11:22

En général il est recommandé de désactiver la résolution du reverse ip... d'ailleurs c'est le comportement par défaut maintenant.

Julien Tartarin
Founder & CTO @ Mailjet.com

dob
Modérateur

Inscrit le : 10/05/2005

# Le 02/09/2009 à 17:53

Petit up : Pour Apache -> ftp://ftp.monshouwer.eu/pub/linux/mod_antiloris/

Ça marche très bien, tout simplement en limitant le nombre de requêtes en état READ par IP, à partir du scoreboard d'Apache.

Julien Tartarin
Founder & CTO @ Mailjet.com

Page 12

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.