Question Qu'est-ce qui peut provoquer la panne de TOUS les services d'un serveur tout en répondant à ping? et comment comprendre


Il m'est déjà arrivé deux fois, en quelques jours, que mon serveur tombe complètement en panne, ce qui signifie http, ssh, ftp, dns, smtp, essentiellement TOUS les services cessent de répondre, comme si le serveur avait été désactivé, sauf qu'il répond toujours au ping , qui est ce qui me blesse le plus.

J'ai quelques scripts php qui causent une charge énorme (processeur et mémoire) sur le serveur en rafales courtes, utilisés par un petit groupe d'utilisateurs, mais généralement le serveur "survit" parfaitement à ces rafales, et quand il tombe en panne ne coïncide jamais avec de tels pics d'utilisation (je ne dis pas que cela ne peut pas être lié, mais cela ne se produit pas juste après).

Je ne vous demande pas de pouvoir, comme par magie, me dire quelle est la cause ultime de ces accidents, ma question est la suivante: existe-t-il un processus unique dont la mort peut entraîner la chute simultanée de tous ces services? La chose amusante est que tous les services réseau sont en panne, à l'exception du ping. Si le serveur avait consommé 100% de la CPU par un processus quelconque, il ne répondait pas non plus à la requête ping. Si apache plantait à cause (par exemple) d'un script php cassé, cela n'affecterait que http, pas ssh et dns .... etc.

Mon OS est Cent OS 5.6

Plus important encore, après le redémarrage du serveur, quels journaux système devrais-je consulter? / var / log / messages ne révèle rien de suspect.


8
2017-10-21 12:10


origine




Réponses:


(tl; dr toujours répondre au ping est un comportement attendu, vérifiez votre utilisation de la mémoire)

Les demandes d'écho ICMP (c.-à-d. Ping) sont gérées par la pile de mise en réseau dans le noyau, sans autre dépendance.

Le noyau est connu comme étant "résident en mémoire", ce qui signifie qu'il sera toujours conservé dans la RAM et qu'il ne peut pas être échangé sur le disque comme le ferait une application normale.

Cela signifie que, dans les situations où vous n'avez plus de mémoire physique, les applications sont permutées sur le disque, mais le noyau reste à sa place. Lorsque la mémoire physique et la mémoire d'échange sont saturées (et que le système ne peut plus gérer vos programmes), la machine bascule. Cependant parce que une) le noyau est toujours en mémoire et b) il peut répondre aux demandes de ping sans l'aide de rien d'autre, le système continuera à répondre au ping même si tout est mort.

En ce qui concerne votre problème, je soupçonne fortement des problèmes de mémoire. Installez "sysstat" et utilisez la commande "sar" pour afficher un journal de la mémoire / cpu / chargement / io, etc. Je m'attendrais bien à ce que, au moment du crash, vous utilisiez à la fois 100% physique et swap.

Je voudrais aussi envisager de regarder dmesg ou / var / log / messages pour tout signe du tueur de MOO (tueur de mémoire insuffisante) invoqué. C'est le système d'urgence du noyau qui commencera à tuer les processus en cas d'épuisement de la mémoire. Son efficacité dépend en grande partie des processus qui sont éliminés. Un seul processus consommant la mémoire sera efficacement tué et libéré. ​​Cependant, un site Web basé sur Apache engendrera des processus de remplacement dès que le processus enfant sera tué.


7
2017-10-21 13:06



+1 pour le tueur de MOO - HTTP500
Merci beaucoup, je suis presque sûr que c'est le problème, car la RAM et le swap étaient pleins avant la panne du serveur. (Je peux voir sur les statistiques du gestionnaire d'ovh). Et ce sont probablement certains de mes scripts php fous qui utilisent beaucoup de mémoire. Cela me laisse toutefois perplexe pour deux raisons. (1) on dirait que la mémoire consommée par php n'est pas libérée par la suite, mais cela n'aurait aucun sens; (2) dans tous les cas, je ne m'attendrais pas à ce qu'un système d'exploitation approprié meure complètement juste à cause d'un (voire de quelques) processus utilisant trop de mémoire ... Je m'attendrais à ce qu'il - matteo
refuser d'allouer de la mémoire aux programmes qui le demandent quand il n'y a pas assez de RAM pour que le système continue à fonctionner correctement ... Je veux dire un programme buggy ou même malveillant ne devrait jamais être capable de détruire tout le système ... - matteo
@matteo Linux a ce qu’on appelle "surcommit": juste parce que vous malloc() 1 Go de RAM ne signifie pas réellement que vous allez l'utiliser, le gestionnaire de mémoire enregistre donc la quantité de mémoire que votre programme pense avoir et la quantité de mémoire réellement utilisée par le programme. En fait, il fonctionne correctement. temps. Au moins, jusqu'à ce que plus d'un programme veuille utiliser tous les 1 Go qu'il pense avoir. - DerfK
@matteo je vois non indication qu'il s'agit d'un problème de MOO. En règle générale, le tueur OOM sélectionne des processus spécifiques ou répondent à certains critères, mais il ne tue pas toujours un démon comme ssh. C'est définitivement du côté des E / S. Vous n'avez pas expliqué votre situation matérielle / vos spécifications techniques comme je l'avais demandé dans ma réponse. - ewwhite


Il s'agit généralement d'un problème de sous-système d'E / S ou de disque. Souvent, cela sera associé à une charge système extrêmement élevée. Par exemple, le système présenté en détail dans le graphique ci-dessous ne répondait plus (mais pouvait faire l'objet d'une requête ping) lorsqu'un script fonctionnait mal, bloquait un groupe de fichiers et que la charge passait à 36 ... sur un système à 4 processeurs.

enter image description here

Les services qui s'exécutent dans la RAM et ne nécessitent pas d'accès au disque continuent de s'exécuter ... Ainsi, la pile réseau (ping) est active, mais les autres services restent bloqués lorsqu'un accès au disque est requis ... SSH lorsqu'une clé est référencée ou recherche de mot de passe nécessaire. SMTP a tendance à s'arrêter lorsque la charge moyenne atteint 30 ou plus ...

Lorsque le système est dans cet état, essayez une télécommande nmap contre l'IP du serveur pour voir ce qui se passe.

La journalisation ne fonctionne probablement pas s'il s'agit d'un problème de disque ou de stockage ...

Pouvez-vous décrire la configuration matérielle? Est-ce une machine virtuelle? Quelle est la disposition de stockage?

Plus que la journalisation, vous voulez savoir si vous pouvez représenter graphiquement les performances du système et comprendre quand cela se produit. Voir si cela correspond à une activité spécifique.


4
2017-10-21 12:19



Si tel est le problème, existe-t-il un moyen d'indiquer à SSH de conserver le ou les mots de passe en mémoire, donc même si le serveur est dans cet état, je peux au moins pouvoir me connecter via ssh et exécuter certaines commandes pour voir Que se passe-t-il? - matteo
S'il s'agit d'E / S, vous devez aller au fond des choses. S'il s'agit d'un délai d'attente sur une grappe de disques ou d'une interaction de pilote, cela diffère d'un script qui s'exécute mal ou d'un problème de conflit de ressources. - ewwhite