Discussion :

[JeanMiG]

Bonjour,
Mon serveur d'entreprise sous RHEL fonctionne depuis une dizaine d'années, avec 150 utilisateurs connectés en même temps.
Le mois dernier, et une seconde fois la semaine dernière, le système s'est comme "figé", impossible de lancer une instruction qui lance un process fils.
Les utilisateurs connectés pouvaient naviguer dans le logiciel, faire défiler la base de données.
Mais :
=> impossible de se connecter (pour ceux qui ne l'étaient pas) (utilisateurs sous Windows, on utilise Putty en SSH pour se connecter).
=> pour ceux qui étaient connectés, impossible de lancer une impression (shell et exécutable pour convertir un flux de données en document avec mise en page en PCL ou en PDF).
Et ceci durant une dizaine de minutes.

J'ai cherché déjà dans :
vmstat => le système est quasiment au repos : pas d'accès disque délirant, CPU dispo à 98%, mémoire loin d'être saturée, interruptions normales
limitations SSH => je n'ai pas vu de limite déclarée
nombre de process => actuellement (60% de l'effectif), j'ai 83 utilisateurs connectés, et 568 process dans "ps aux", alors que "ulimit -p" m'indique un max de 7168 process, j'en suis très très loin.

Si quelqu'un a déjà eu ce genre de curiosité, ou aurait des pistes de diagnostic, je serais enchanté de partager...

Merci déjà de m'avoir lu.

[Jipété]

Bonjour,
Mon serveur d'entreprise sous RHEL fonctionne depuis une dizaine d'années,

Un futur problème de disque dur qui commence à fatiguer ?

[JeanMiG]

J'ai oublié de préciser.....

Il y a 15 ans, ce serveur (OS + DB + Applis) tournait sur un serveur physique (sur roulettes).
Il y a 10 ans, cette même appli (OS + DB + applis) tournait sur un serveur lame en rack.
Il y a 4 ans, j'ai migré l'ensemble (idem) sur une VM sous VMWare, sur un serveur physique en rack, avec baie de disque NetApp partagée.
D'où ma première idée : une autre VM sur le même serveur physique utilise la totalité des ressources (CPU ou mémoire). Ou encore, une autre VM sur un autre serveur physique utilise la totalité des ressources de stockage (baie de disques NetApp partagée par tous les serveurs).
Idée abandonnée, puisque les utilisateurs qui étaient connectés auparavant, ont continué à travailler, naviguer dans l'appli, faire défiler les données de la base de données, lancer des calculs.... Mais dès que cette appli lance un shell (impression en PCL ou PDF, conversion de flux en fichier Excel, ..)... rien ne se passe, écran figé. Idem lorsque d'autres voulaient se connecter... le mot "login:" ne s'affiche pas.
Ca dure entre 10 minutes et un quart d'heure. Rien dans aucun log système sous /var/log, ni message, ni maillog, ni ....
Et ça repart, comme si de rien n'était, plein pot, impressions, connexions, ... tout normal !
En 30 ans de Unix puis Linux, jamais vu ce phénomène.

Une modification récente tout de même (je juge utile de le préciser) : le moteur de base de données était limité à 150 utilisateurs en simultanée, mais avec l'accroissement des effectifs, j'ai dû augmenter ce quota, je limite aujourd'hui à 180 connexions. J'ai fait cette modification en septembre. J'ai eu 2 fois 10 minutes d'arrêt.
Donc je suis convaincu aujourd'hui que c'est une histoire de ressource, de quota, de nombre de connexions, de nombre de process, .... de saturation quelque part... mais sans log, sans message d'erreur, ...
Il y a plusieurs années, j'avais été confronté à un nombre de tty limité, et j'avais dû utiliser des instructions pour créer des tty supplémentaires dans les répertoires /etc. Mais aujourd'hui ce n'ai pas ça...
Quel mystère !!!!

[Jipété]

OK, ça me dépasse.

Faudrait ratisser plus large : poster dans les sous-forums de BdD, d'architecture, faut aller jouer dans la cour des grands, moi je suis un tout petit.

[Christophe]

Ce serait pas une tache planifiée ? sauvegarde ?

[disedorgue]

Bonjour,

Pour moi, ça ressemble à un problème réseau...

Est-ce que tu arrives à "pinguer" ton serveur quand ça arrive ?

Ton serveur est en direct sur le net ou proxy-fié ?

Voir aussi si le serveur ne se proxyfie pas lui-même...

[JeanMiG]

Bonjour,

Merci pour vos idées...

A l'heure où ça arrive, pas de sauvegarde, des cron oui et en particulier un cron qui "gicle" les utilisateurs qui n'ont pas touché au clavier depuis 1h (grâce à l'instruction w) de manière à faire de la place pour ceux qui souhaitent se connecter. Et à l'heure où c'est arrivé, ce "killer" avait tourné 2 minutes plus tôt.
Réseau : il s'agit d'un serveur de gestion de prod, c'est un serveur interne à l'entreprise, pas de connexion extérieure (sauf VPN).

Si ce n'est pas le nombre de PID qui bloque (je n'utilise que 1% des process), est-ce que ça peut être le gestionnaire de ces numéros (ce ne serait pas init ?) qui est occupé à autre chose, et ne fournit pas de PID pour pouvoir lancer effectivement ces process (session utilisateur, shell script de calcul, exécutable de conversion, ..) ?
Ce serait étrange... Mais de toute façon le phénomène est très étrange.
Et quoi de plus difficile à voir qu'un phénomène éphémère qui se produit 2 fois en trois mois. Non reproductible pour l'instant...
Je vais tenter de le reproduire en sollicitant beaucoup la machine => création de centaines de shell, de connexions, écriture d'un exé qui va dévorer la mémoire, ...
Le "top" tourne en permanence, mais il reste très calme, et se rafraîchit sans broncher.
Mais quand c'était arrivé, impossible de lancer "top" : impossible de lancer un exé ! Mais bizarrement il était possible de lancer "ps aux", mais "ps aux|wc" ne passait pas, ça lance trop de process, donc écran noir et rien... <Ctrl>-C rend la main...

Merci à vous tous.

[BufferBob]

salut,

avec un serveur aussi vieux et à priori d'entreprise, la bonne idée c'est d'avoir des graphs et du monitoring (remontées d'alertes), ça permet d'identifier plus facilement d'où viennent les problèmes, de mesurer l'impact des changements apportés à la machine à court, moyen et long terme, d'être notifié en temps réel quand les incidents se produisent etc.

en l'occurrence ça pourrait venir de tout et n'importe quoi de mon point de vue, de la bizarrerie réseau à la modif système oubliée en passant par le manque de RAM, le disque hôte défectueux, la VM voisine qui empiète sur les ressources, jusqu'à la blagounette malveillante d'un collègue etc. difficile de dire sans plus d'éléments.

[Tlams]

Que donne un dmesg ?