Je viens vous demander un peu d'aide sur un problème aussi récurrent qu'absurdement sombre...
Exposé de la situation :
J'ai un serveur RPS chez OVH (ouaip, je sais, c'est pas bien), jusqu'à il y a peu de temps (~ 4 mois ?) on avait pas d'ennui, rien, nada, 100 jours d'uptime, la joie et la bonne humeur.
Puis on a changé de serveur (RPS 1 -> RPS 1 : Wow !) et ... d'OS.
On est passé de Gentoo (plus jamais) à Debian Lenny, et par la même occasion d'un vieux pannel webmin bien moisi (la version actuelle est super, mais celle qu'on avait datait de 2004 tout de même) au pannel DTC (non, pas D... Ton... C..., Digital Technology Control).
Jusque-là, tout va plutôt bien, septembre se passe assez bien, puis vient octobre !
Alors là, c'est la débandade, je le jure, j'ai rien fait ! Mais pourtant ! Le serveur plante régulièrement, une fois minimum par semaine, quand c'est pas plusieurs fois par semaine !
On cherche tant qu'on peut, on finit par être sincèrement convaincu que le disque dur réseau du RPS est défectueux, mais le service client ne veut rien entendre : pas tant qu'on aura pas des logs "incriminant le matériel".
Bon, soit, on va logger tout ce qu'on peut... Je décide donc de mettre en place un log sur les premières lignes de la commandes "top", qui sont à mon goût, assez descriptives de l'état du système à un instant donné.
On attend un peu, ah ! Nouveau plantage !
Je me jète sur mes logs tout frais, et que vois-je ? Euh... bah rien d'intéressant, justement, si ce n'est une remarque sur les processus.
En effet, le serveur plante, déjà, de manière originale : SSH ne répond plus, ou tellement lentement que c'est absolument (si si) inutilisable, Apache, ftp, etc... ne veulent rien savoir, on a juste droit au protocole ICMP (Ping).
Mais plus original encore : quand on regarde les logs, on s'aperçoit que le processeur n'est pas surchargé, la ram non plus... et le disque dur non plus !
Mystère alors, pourquoi le serveur plante-t-il ?
On cherche un peu dans syslog : Apache2 renvoit des erreurs comme quoi les connection SQL (MySQL en localhost) sont timeoutées... Bon, je tente une petite modif, j'augmente le timeout de la connection MySQL.
On attend un peu... on secoue... aujourd'hui, rebelotte !
Serveur planté, mêmes symptomes que d'hab. Reboot hardware... on regarde les logs... ah ben !
Alors qu'on avait constaté que lors du plantage précédent on avait une augmentation vive du nombre de processus (170 -> 220 en moins d'une heure), on s'aperçoit que le serveur a trainé depuis aujourd'hui 00h00 plus de 200 processus toute la journée, et plus de 400 voire 500 processus toute l'après-midi ! Et ce... sans planter !
Allons-bon, le plantage précédent ne venait donc pas de l'augmentation du nombre de processus, puisqu'aujourd'hui, c'est à 886 processus que notre serveur plante !
Have a look to the "top" command logs :
top - 15:52:41 up 1 day, 19:55, 0 users, load average: 184.87, 164.43, 157.20
Tasks: 545 total, 1 running, 543 sleeping, 0 stopped, 1 zombie
Cpu(s): 4.4%us, 1.0%sy, 0.3%ni, 86.3%id, 7.9%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 494356k total, 489048k used, 5308k free, 1880k buffers
Swap: 1959928k total, 374436k used, 1585492k free, 20084k cached
top - 15:55:13 up 1 day, 19:58, 0 users, load average: 207.26, 179.56, 163.80
Tasks: 582 total, 16 running, 565 sleeping, 0 stopped, 1 zombie
Cpu(s): 4.4%us, 1.0%sy, 0.3%ni, 86.2%id, 8.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 494356k total, 489440k used, 4916k free, 4780k buffers
Swap: 1959928k total, 702520k used, 1257408k free, 23880k cached
top - 15:56:24 up 1 day, 19:59, 0 users, load average: 198.23, 183.26, 166.34
Tasks: 597 total, 1 running, 595 sleeping, 0 stopped, 1 zombie
Cpu(s): 4.4%us, 1.0%sy, 0.3%ni, 86.2%id, 8.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 494356k total, 487100k used, 7256k free, 3548k buffers
Swap: 1959928k total, 868868k used, 1091060k free, 22268k cached
top - 16:00:56 up 1 day, 20:04, 0 users, load average: 232.36, 209.60, 181.45
Tasks: 639 total, 1 running, 637 sleeping, 0 stopped, 1 zombie
Cpu(s): 4.4%us, 1.1%sy, 0.3%ni, 86.1%id, 8.2%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 494356k total, 488136k used, 6220k free, 4856k buffers
Swap: 1959928k total, 964720k used, 995208k free, 25016k cached
top - 16:01:05 up 1 day, 20:04, 0 users, load average: 233.62, 210.62, 182.08
Tasks: 649 total, 2 running, 646 sleeping, 0 stopped, 1 zombie
Cpu(s): 4.4%us, 1.1%sy, 0.3%ni, 86.1%id, 8.2%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 494356k total, 486184k used, 8172k free, 4868k buffers
Swap: 1959928k total, 958452k used, 1001476k free, 27372k cached
top - 16:01:05 up 1 day, 20:04, 0 users, load average: 233.62, 210.62, 182.08
Tasks: 649 total, 2 running, 646 sleeping, 0 stopped, 1 zombie
Cpu(s): 4.4%us, 1.1%sy, 0.3%ni, 86.1%id, 8.2%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 494356k total, 486184k used, 8172k free, 4868k buffers
Swap: 1959928k total, 958452k used, 1001476k free, 27372k cached
top - 16:05:55 up 1 day, 20:09, 0 users, load average: 272.82, 242.09, 202.51
Tasks: 696 total, 3 running, 692 sleeping, 0 stopped, 1 zombie
Cpu(s): 4.4%us, 1.1%sy, 0.3%ni, 85.9%id, 8.3%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 494356k total, 487240k used, 7116k free, 4384k buffers
Swap: 1959928k total, 956384k used, 1003544k free, 25028k cached
top - 16:05:55 up 1 day, 20:09, 0 users, load average: 272.82, 242.09, 202.51
Tasks: 696 total, 8 running, 687 sleeping, 0 stopped, 1 zombie
Cpu(s): 4.4%us, 1.1%sy, 0.3%ni, 85.9%id, 8.3%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 494356k total, 487240k used, 7116k free, 4388k buffers
Swap: 1959928k total, 956380k used, 1003548k free, 25008k cached
top - 16:10:33 up 1 day, 20:13, 0 users, load average: 274.41, 267.18, 223.80
Tasks: 702 total, 1 running, 695 sleeping, 0 stopped, 5 zombie
Cpu(s): 4.4%us, 1.1%sy, 0.3%ni, 85.7%id, 8.5%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 494356k total, 489428k used, 4928k free, 5228k buffers
Swap: 1959928k total, 979812k used, 980116k free, 28888k cached
(a priori ça commence à planter ici)
top - 16:35:18 up 1 day, 20:38, 0 users, load average: 308.09, 301.56, 274.72
Tasks: 804 total, 1 running, 801 sleeping, 0 stopped, 2 zombie
Cpu(s): 4.4%us, 1.1%sy, 0.3%ni, 85.1%id, 9.2%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 494356k total, 487668k used, 6688k free, 4296k buffers
Swap: 1959928k total, 979124k used, 980804k free, 24884k cached
top - 16:38:15 up 1 day, 20:41, 0 users, load average: 292.94, 298.19, 278.09
Tasks: 804 total, 1 running, 797 sleeping, 0 stopped, 6 zombie
Cpu(s): 4.4%us, 1.1%sy, 0.3%ni, 85.0%id, 9.3%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 494356k total, 488760k used, 5596k free, 2456k buffers
Swap: 1959928k total, 979972k used, 979956k free, 29516k cached
top - 16:43:13 up 1 day, 20:46, 0 users, load average: 298.51, 300.09, 284.54
Tasks: 824 total, 1 running, 818 sleeping, 0 stopped, 5 zombie
Cpu(s): 4.3%us, 1.1%sy, 0.3%ni, 84.9%id, 9.4%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 494356k total, 483880k used, 10476k free, 4776k buffers
Swap: 1959928k total, 979928k used, 980000k free, 27120k cached
top - 16:43:31 up 1 day, 20:46, 0 users, load average: 297.49, 299.79, 284.70
Tasks: 821 total, 1 running, 814 sleeping, 0 stopped, 6 zombie
Cpu(s): 4.3%us, 1.1%sy, 0.3%ni, 84.9%id, 9.4%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 494356k total, 483744k used, 10612k free, 4716k buffers
Swap: 1959928k total, 979904k used, 980024k free, 28228k cached
top - 16:44:24 up 1 day, 20:47, 0 users, load average: 297.29, 299.22, 285.36
Tasks: 835 total, 1 running, 829 sleeping, 0 stopped, 5 zombie
Cpu(s): 4.3%us, 1.1%sy, 0.3%ni, 84.8%id, 9.4%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 494356k total, 482544k used, 11812k free, 5048k buffers
Swap: 1959928k total, 975988k used, 983940k free, 29956k cached
(là, c'est plantage confirmé)
top - 16:48:07 up 1 day, 20:51, 0 users, load average: 322.61, 306.60, 290.93
Tasks: 864 total, 1 running, 853 sleeping, 0 stopped, 10 zombie
Cpu(s): 4.3%us, 1.1%sy, 0.3%ni, 84.8%id, 9.5%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 494356k total, 472172k used, 22184k free, 3740k buffers
Swap: 1959928k total, 971548k used, 988380k free, 33120k cached
top - 16:48:27 up 1 day, 20:51, 0 users, load average: 314.33, 305.75, 290.99
Tasks: 863 total, 1 running, 852 sleeping, 0 stopped, 10 zombie
Cpu(s): 4.3%us, 1.1%sy, 0.3%ni, 84.8%id, 9.5%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 494356k total, 474592k used, 19764k free, 3752k buffers
Swap: 1959928k total, 972132k used, 987796k free, 34460k cached
top - 16:56:05 up 1 day, 20:59, 0 users, load average: 302.22, 303.70, 295.24
Tasks: 843 total, 1 running, 839 sleeping, 0 stopped, 3 zombie
Cpu(s): 4.3%us, 1.0%sy, 0.3%ni, 84.6%id, 9.7%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 494356k total, 487880k used, 6476k free, 2972k buffers
Swap: 1959928k total, 978692k used, 981236k free, 32072k cached
top - 16:58:19 up 1 day, 21:01, 0 users, load average: 312.01, 305.04, 296.75
Tasks: 850 total, 1 running, 847 sleeping, 0 stopped, 2 zombie
Cpu(s): 4.3%us, 1.0%sy, 0.3%ni, 84.5%id, 9.8%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 494356k total, 488736k used, 5620k free, 3368k buffers
Swap: 1959928k total, 975032k used, 984896k free, 33288k cached
top - 17:13:47 up 1 day, 21:16, 0 users, load average: 356.77, 354.32, 332.90
Tasks: 884 total, 1 running, 880 sleeping, 0 stopped, 3 zombie
Cpu(s): 4.3%us, 1.0%sy, 0.3%ni, 84.2%id, 10.2%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 494356k total, 489544k used, 4812k free, 6116k buffers
Swap: 1959928k total, 973700k used, 986228k free, 29876k cached
La problématique est donc la suivante : Comment savoir qui ouvre tous ces processus ?
Comment savoir pourquoi ils ne se ferment pas ?
Comment envoyer une alerte à l'admin au dessus d'un nombre de processus limite (histoire de regarder manuellement ce qui se passe avant que le bazar plante) ?
Ou toute autre manipulation qui pourrait aider à recouvrir une stabilité exemplaire !
En remerciant d'avance toutes celles et tous ceux qui participeront à ce sujet :)
Bonne soirée à vous =)
Undo
# processus ?
Posté par __o . Évalué à 3.
À mon avis tu as une tache cron qui se lance toutes les minutes, et qui de temps en temps dure plus d'une minute. Donc les processus de cette tache s'accumulent, consomment toute la mémoire, ça swap, et ça ne répond plus. La tache cron doit venir de ton panel, et la durée de plus d'une minute doit être causée par des accès disques particulièrement lents sur un RPS à certaines heures.
# vmstat + memoire
Posté par briaeros007 . Évalué à 2.
Moi j'avais (j'ai toujours en réalité) un problème proche : mon système marche sans problème, et plus ou moins aléatoirement paf comportement erratique, kernel bug, kernel oops, et general protection fault.
Le problème venait de la mémoire. Essaie de faire un coup de memtest et de regarder dans kern.log ce qu'il t'affiche juste avant de planter.
Sinon, laisse un vmstat tourner tu auras le temps "wait" et les i/o sur la swap pour vérifier ce qui marche ou pas.
# Logs ?
Posté par JJD . Évalué à 2.
La commande vmstat devrait te permettre de voir l'évolution du du système avant le plantage. Lance
vmstat -n 5 >vmstat.log &
de façon à pouvoir observer, après un redémarrage ce qu'il s'est passé (pense éventuellement à purger le fichier avec "> vmstat.log" de temps en temps, puisque seule la fin devrait t'intéresser).
Bien entendu, il faut aussi que tu récupères régulièrement la liste des processus en cours d'exécution avec un "ps -ef" redirigé dans un fichier (tu peux mettre ça dans la crontab avec redirection dans un fichier). Je ne sais pas ce que tu fais avec ce serveur, mais plus de 800 processus en cours d'exécution ça me semble beaucoup !
Les données que tu fournis sont surprenantes : le load average est à plus de 300, mais le CPU ne fout rien (85% en iddle). En revanche, il y a près 1GO de swap utilisé pour 500MO de RAM, ce qui n'est pas vraiment étonnant au vu du nombre de processus.
Il faudrait également que tu regardes dans les log système (/var/log/messages et /var/log/kern.log) ce qu'il se passe juste avant le plantage : il peut il y avoir des choses intéressantes, en particulier concernant le manque de mémoire (j'ai vu des machines planter, alors qu'il restait du swap disponible, en raison d'un manque de mémoire "haute"). Tu peux également avoir des détails sur l'occupation mémoire en lisant le fichier /proc/meminfo.
Enfin, il peut aussi être intéressant d'observer les connexion réseau sur la machine avec :
netstat -tanp
Vi que la machine héberge au moins un serveur HTTP, un serveur FTP et un serveur SSH, on ne peut exclure l'attaque par déni de service ou l'exploitation d'un faille de sécurité.
Bon courage dans tes recherches,
JJD
# la piste du disque n'est pas totalement à exclure ...
Posté par totof2000 . Évalué à 2.
La situation s'est rétablie lorsque le disque en question est retombé en marche (problème sur les drivers SCSI : un patch a résolu le problème).
[^] # Re: la piste du disque n'est pas totalement à exclure ...
Posté par nonas . Évalué à 1.
[^] # Re: la piste du disque n'est pas totalement à exclure ...
Posté par totof2000 . Évalué à 2.
# io wai et load
Posté par NeoX . Évalué à 2.
top - 17:13:47 up 1 day, 21:16, 0 users, load average: 356.77, 354.32, 332.90
Tasks: 884 total, 1 running, 880 sleeping, 0 stopped, 3 zombie
Cpu(s): 4.3%us, 1.0%sy, 0.3%ni, 84.2%id, 10.2%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 494356k total, 489544k used, 4812k free, 6116k buffers
Swap: 1959928k total, 973700k used, 986228k free, 29876k cached
tu as une charge >100% (356.77)
et tu attends plein de retour d'acces disque (10.2%wa)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.