Bonjour tout le monde,
j'administre un serveur Linux (Intrepid plus exactement) et depuis quelque temps, sans raison apparente, il c'est mis a figer l'écran et "killer" des services comme ssh pour l'accès distant.
Des recherches dans les logs ont révélé un soucis de mémoire (out of memory), je crois, sur le net j'ai trouvé quelques pistes mais rien de concret.
Le serveur à 2Go RAM + 2Go SWAP, service web, téléphonie, Mysql entre autres, j'ai pu constater que peut avant les plantages, mysql utilisé pas mal de mémoire, et donc le premier à être stoppé par omm_killer, ce que laisse penser un problème originaire d'une des taches du cron, en effet, divers services du système dépendent du cron, mais les plantages sont aléatoires, en plus, je n'ai rien trouvé en plus des taches habituelles.
J'ai trouvé aussi qu'un script perl qui prends pas mal de mémoire au fur et à mesure car le serveur ne redémarre pas tous les jours.
Quelqu'un aurai une piste pour moi ? J'en ai plus d'idée et ces plantages agacent tout le monde
Merci à tous
[
attachment=197]
Salut Gbueno3,
Difficile de te dire, comme ça, d'où vient ton problème !
D'ailleurs, d'où il vient, en fait, tu le sais déjà plus ou moins : d'un manque de mémoire RAM !
Alors, quelques pistes quand même : Tu dis qu'il y a un serveur web.. j'imagine que c'est Apache. Sache que Apache est ENORMEMENT gourmand en mémoire vive, et tout spécialement quand il est utilisé avec mod_php. Un seul processus apache peut utiliser jusqu'à 40Mo de RAM facilement pour une page dynamique un peu lourde ...
Donc je te fais le calcul : 25 processus * 40Mo = 1Go de RAM ... Ça va vite !
Ensuite, MySQL prend facilement 300-400Mo aussi, si tu as un serveur mail, genre postfix, associé à courier-imap, ça bouffe encore plusieurs centaines de Mo de RAM ... Si tu as amavis d"installé, avec le daemon ClamAV, ça te bouffe encore des centaines de Mo de RAM ... Donc on arrive très très vite aux 2Go !
Pour savoir quels processus sont susceptibles de bouffer la RAM, tu peux utiliser les commandes htop (en temps réel) et top (en temps réel et en redirection de la sortie) via un cron.
C'est ce que je faisais il fut un temps : j'avais un cron qui lançait top avec l'option "-b" de mémoire, pour rediriger la sortie de top vers stdin, et j'enregistrer tout ça dans un fichier de log. En mm tps, je datais chaque entrée avec un script (en clair, mon cron lançait un script bash qui lançait top, après avoir écrit la date) et comme ça je pouvais voir, au moment du plantage quels étaient les processus qui bouffaient le plus de CPU ou de RAM (on doit sans doute pouvoir ordonner la sortie de la commande top).
Tu peux aussi logger le nombre de processus Apache, vérifier que la limite "maxclients" de Apache n'est pas un peu trop haute... etc. etc. ... tu as plein d'options qui s'ouvrent à toi.
Tu peux aussi installer un outil comme Munin pour avoir des graphiques de l'utilisation de ta RAM, de ton CPU, etc.... pour voir si c'est une augmentation soudaine, si c'est une saturation progressive, si ça arrive toujours aux mêmes moments...? si ça correspond ausi à un pic de traffic (en loggant le nombre de packets échangés sur eth0 par la même occasion (avec Munin) par exemple ...).
Voilà, je t'ai donné pas mal d'idée, tiens-nous au courant de ton avancement !!
Salut Troll, comment ca va ?
J'avais pensai aussi pour les enregistrements "top", les plantages sont aléatoires et progressives.
Les 2Go de RAM sont vite "bouffés", mais il en reste encore pas mal du SWAP (je sait ce n'est pas la même chose). En ce qui concerne les processus, les plus lourds sont mysql et un script perl, mais il en reste du SWAP, bref.
L'intrigant c'est que aucune modification (hard/soft) n'a été faite et le serveur tournait comme ça depuis un bon moment, alors pour quoi maintenant ? Trois plantages en 2 semaines.
Et à chaque plantage j'ai droit à une réparation de la base des données car l'arrêt brutal de mysqld casse la base.
Je me suis peut être embrouillé dans le premier poste, si je réfléchi bien, il est possible que les messages à l'écran soient la cause de la surconsommation de mémoire, qu'en pensez vous ?
IL est minuit, dernier redémarrage du serveur aujourd'hui 10:30hs, j'ai pu me connecter, pas de problème apparent pour le moment, consommation RAM 99% dont mysql 9%, script perl 22% ; consommation SWAP 2%, on vera bien demain.
Merci pour la réponse rapide, je prendrai en compte bien sûre les idées, a bientôt
Si j'ai bien appris une chose dans la gestion de serveurs web c'est qu'il ne faut pas compter sur la swap. Ce n'est pas fait pour remplacer la ram mais lui venir en secours. Si ta ram est quasiment saturée en permanence alors faut en rajouter ou alléger la charge mais faut pas laisser comme ça. Le problème de la swap en fait c'estque c'est très lent Du coup qd ca swappe tout ton serveur ralentit et la file d'attente s'agrandit, augmentant ainsi la conso mémoire et faisant swapper encore plus et donc ralentir encore plus et ainsi de suite... jusqu'à l'oom killer !
Suite des événements donc,
Le monitoring des processus (top) à finalement démontré que la charge monte jusqu'au omm_killer éffectivement, mais...
Il semble avoir un bug sur un des scripts perl comme même, je ne comprennais pas comme ça c'est fait que la mémoire monte sans arrêt, même si le serveur est sous dimensionné il devrait tenir le coup (comme c'est le cas depuis le temps).
Le dit fichier consommateur est le AST_VDadapt.pl, qui lui est apparemment lié au cron, du les messages à l'écran au moment du plantage.
Voila, je suis à la recherche d'info encore, de petit à petit j'avance
(12-10-2011 16:03 PM)gbueno3 a écrit : [ -> ]Suite des événements donc,
Le monitoring des processus (top) à finalement démontré que la charge monte jusqu'au omm_killer éffectivement, mais...
Il semble avoir un bug sur un des scripts perl comme même, je ne comprennais pas comme ça c'est fait que la mémoire monte sans arrêt, même si le serveur est sous dimensionné il devrait tenir le coup (comme c'est le cas depuis le temps).
Le dit fichier consommateur est le AST_VDadapt.pl, qui lui est apparemment lié au cron, du les messages à l'écran au moment du plantage.
Voila, je suis à la recherche d'info encore, de petit à petit j'avance
Ben maintenant ma foi y'a plus qu'à ouvrir ton script perl et comprendre ce qui se passe
Mais à mon avis, comme ton script PERL plante, le lendemain, il doit traîter des données pas terminées de la veille, et du coup il consomme encore plus que la veille, et va du coup consommer de plus en plus de jour en jour. Tu devrais essayer de forcer son exécution en allouant 10Go de swap par exemple si tu n'as pas la possibilité d'allouer plus de RAM.
Pour allouer plus de swap, tu peux créer un fichier de type block sur ton disque dur avec la commande
dd puis ensuite tu l'affecte à la swap soit en modifiant le fstab soit avec la commande
swapon.
mmhm, effectivement je ne peux ajouter de la RAM, la solution de secours est de redémarrer le serveur une fois par nuit au travers le cron pour vider la mémoire, donc jusqu'à trouver le problème pas de soucis en ce qui concerne la surconsommation.
Pour les scripts perl je ne suis pas un AS mais il y a peut être une boucle infinie ou quelque chose comme ça, non ? J'ai lu un sujet hier qui parlé d'une mise à jour de perl pour résoudre le problème, mais si ça été ça, pour quoi il n'y a pas de soucis avec d'autres *.pl ?
Eh oui Troll, j'avais penser a ajouter du swap mais j'ai bien peur que la consommation aie jusqu'au bout du swap aussi si j'enlève le reboot.
J'ai eu également une surprise hier
d'autres serveurs ont aussi le soucis mémoire, mais ne plantent pas (pour le moment !)
je doute que si tu lui ajoute 10go de swap il aille jusqu'au bout ! dans tous les cas le perl c'est pas dur a comprendre c'est très proche du php.
Moi je te conseille de faire ce sue j'ai suggéré au-dessus je vois pas grand chose d'autre pour faire avancer le schmilblick.
Oui, je commence à manquer des solutions aussi.
J'ai plus tôt téléchargé le AST_VDadapt.pl sur le site de vicidial et le fichier du serveur pour les comparer, ils sont identiques.
Pour la mise à jour de perl je pense que c'est une fausse piste car ils parlent de perl-5.8.8 vers le 5.8.9 et je suis sur la version 5.10.0.
J'augmenterai le SWAP et l'intervalle entre les redémarrages pour le moment.
Bonjour à toi.
Tu en es où ?