Qu'est-ce qui peut provoquer la panne de TOUS les services d'un serveur tout en répondant au 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, en gros TOUS les services cessent de répondre, comme si le serveur avait été éteint, sauf qu'il répond toujours au ping , ce qui me choque le plus.

J'ai quelques scripts php qui provoquent une énorme charge (CPU et mémoire) sur le serveur en courtes rafales, utilisés par un petit groupe d'utilisateurs, mais généralement le serveur "survit" parfaitement bien à ces rafales, et quand il descend, il ne coïncident 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 ceux-ci).

Je ne vous demande pas par magie de pouvoir me dire la cause ultime de ces plantages, ma question est: y a-t-il un seul processus dont la mort pourrait faire baisser simultanément tous ces services? Le plus drôle, c'est que tous les services réseau tombent en panne, sauf le ping. Si le serveur avait absorbé 100% du processeur par un processus, il ne répondrait pas non plus au 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 un redémarrage dur du serveur, quels journaux système dois-je consulter? / var / log / messages ne révèle rien de suspect.

centos service server-crashes

— matteo
source

Réponses:

( tl; dr répondant toujours 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 pour être "résident en mémoire", ce qui signifie qu'il sera toujours conservé dans la RAM et ne peut pas être échangé sur le disque comme une application ordinaire le peut.

Cela signifie que dans les situations où vous manquez de mémoire physique, les applications sont échangées sur le disque, mais le noyau reste où il est. Lorsque la mémoire physique et la mémoire d'échange sont pleines (et que le système ne peut plus gérer vos programmes), la machine basculera. Cependant parce que a) le noyau est toujours en mémoire et b) il peut répondre aux requêtes ping sans l'aide d'autre chose, le système continuera de répondre au ping malgré tout étant 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 voir un journal de la mémoire / cpu / load / io load etc. Je m'attendrais à des moments de crash vous verriez à la fois 100% physique et swap utilisé.

J'envisagerais également de regarder dmesg ou / var / log / messages pour tout signe de l'appel OOM-killer (out-of-memory-killer). Il s'agit du 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 tués. Un seul processus consommant de la mémoire sera efficacement tué et libéré de la mémoire, mais un site Web basé sur Apache engendrera des processus de remplacement dès qu'un processus enfant sera tué.

— Coops
source

+1 pour OOM Killer

— 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 manager d'Ovh). Et c'est probablement certains de mes scripts PHP fous qui utilisent beaucoup de mémoire. Cela m'énerve cependant pour deux raisons. (1) on dirait que la mémoire dévoré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 (ou même de quelques) processus utilisant trop de mémoire ... je m'attendrais à ce que

— matteo

refuser d'allouer de la mémoire aux programmes qui le demandent lorsqu'il n'y a pas assez de RAM pour que le système continue de fonctionner correctement ... Je veux dire qu'un buggy ou même un programme malveillant ne devrait jamais pouvoir détruire tout le système ...

— matteo

@matteo Linux a ce qu'il appelle un "sur-engagement": ce n'est pas parce que vous avez malloc()1 Go de RAM que vous allez l'utiliser, donc le gestionnaire de mémoire garde une trace de la quantité de mémoire que votre programme pense avoir et de la quantité de mémoire programme a effectivement utilisé, et il fonctionne réellement bien, la plupart du temps. Au moins, jusqu'à ce que plus d'un programme veuille réellement utiliser tous les 1 Go qu'il pense avoir.

— DerfK

@matteo Je ne vois aucune indication qu'il s'agit d'un problème de MOO. En règle générale, l'OOM-killer choisit des processus spécifiques qui 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 / spécifications matérielles comme je l'ai demandé dans ma réponse.

— ewwhite

Il s'agit généralement d'un problème d'E / S ou de sous-système de disque. Souvent, cela sera associé à une moyenne de charge système extrêmement élevée. Par exemple, le système détaillé dans le graphique ci-dessous ne répondait pas (mais était pingable) lorsqu'un script fonctionnait mal, verrouillé un tas de fichiers et la charge passait à 36 ... sur un système à 4 CPU.

entrez la description de l'image ici

Les services qui s'exécutent en RAM et ne nécessitent pas d'accès au disque continuent de s'exécuter ... Ainsi, la pile réseau (ping) est en place, mais les autres services se bloquent 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 moyenne de charge atteint environ 30 ...

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

Votre 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? S'agit-il d'une machine virtuelle? Quelle est la disposition du stockage?

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

— ewwhite
source

En supposant que c'est le problème, existe-t-il un moyen de dire à 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 du problème. S'il s'agit d'un délai d'expiration de la baie de disques ou d'une interaction de pilote, c'est différent d'un script qui s'exécute mal ou d'un problème de contention de ressources.

— ewwhite