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.

[chrtophe]

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 ?

[tabouret]

Bonjour,

Lance un dstat continue sur un mois complet avec surveillance du cpu, des IRQ/IOwait, des processus, de la RAM/SWAP/BUFFER/CACHES, des disques, du réseau...Met limite toutes les options disponibles une fois que le problème survient export au format csv et jolies courbes en perspective.

Bizarre que deux fois par mois pendant 10-20 minutes il soit impossible de lancer de nouveaux processus.

C'est quoi l'OS?

Init est un processus de l'espace utilisateur, les PID c'est le kernel qui s'en occupe (si je ne dis pas de betises).

[netmonk]

Personnellement je regarderais du coté de `ulimit`
et de `open files (-n) 1024 ` par defaut a 1024.
vu l'augmentation du nombre d'utilisateurs, cette limite doit etre facilement atteinte en terme de socket/pipe/fichier ouverts.

Sinon une deuxieme hypothese un Filesystem full (meme /tmp ca peut etre chiant quand c'est full ou un /var/log/ car impossibilité d'ecrire et souvent bloquant en terme d'IO)

[JeanMiG]

Bonjour à tous en cette journée de reprise.
Et donc bonne année.
Merci à tous vos messages. Je prends toutes les idées...

@netmonk.
File system full j'y avait bien pensé, mais tous mes disques sont largement taillés, y compris /home. Pour /tmp, il est à 4% mais la place dispo n'est que 4Go, ce n'est pas énorme mais je n'ai jamais dépassé les 4%. J'ai aussi vérifié les i-nodes (sur une autre machine dans une vie précédente j'avais eu des soucis), là aussi je suis plus que large.
Il me semblait que ulimit -> 1024 était le nombre de fichier par session utilisateur... Si effectivement c'est un total, ça pourrait faire juste.

@tabouret.
la commande 'dstat' n'existe pas chez moi.
L'OS est un RedHat Entreprise 3ES ; kernel = 2.4.21-47.ELmsp.
Et il me semble que 'Init' était justement ce qu'on eppelle le Kernel : c'est lui qui gère les process... il me semble ...

@Tlams.
dmesg ne donne rien de special, pas d'erreur particulière...

@ BufferBob
Une blague je n'y crois pas. Une autre VM qui bouffe toutes les ressources, c'était ma première idée, mais comme les utilisateurs déjà connectés naviguent normalement dans la base de données (dans l'appli), j'ai abandonné cette idée.
Des outils de monitoring, oh oui ça serait utile. Pour l'instant je n'utilise que 'vmstat' (qui tourne en permanence) et 'top' (que je lance en cas de besoin). Et pour la période concernée le vmstat tournait de manière régulière (396 lignes par heure), et le top ne me montre rien de dramatique.

Autre élément : j'ai "cancel" des impressions qui étaient en file d'attente suite à une imprimante HS. ça ne prenait pas beaucoup, mais c'est toujours des ressources gaspillées.

[tabouret]

Init n'est justement pas le Kernel il est simplement lancé par celui ci et s'exécute dans l'espace utilisateur.

Et bien n'hésite pas a nous donner les résultats de vmstat si le problème revient (iotop ce serait parfait aussi si tu peux l'installer dessus).

Autre chose à regarder (ça m'est arrivé pas mal de fois en production) si ça peut être une piste :

Un disque avec beaucoup d'espace disponible (du -sh /* montre que le disque n'est pas beaucoup rempli) mais un FS complètement saturé (df -h te montrera un disque utilisé à 100%).
Ce qui voudrait dire que des fichiers supprimés sont encore utilisés par des applications.

[Tlams]

Tu as regardé du coté hyperviseur ?
La VM n'est pas balloté d'un node à l'autre ? C'est le genre de chose qui laisse pas forcément de trace niveau OS, mais dont l'impact utilisateur peut être parfois étrange.

[JeanMiG]

Bonjour, et encore merci pour toutes vos idées autant diverses que variées...

@Tlams, hyperserveur.
Notre répartition de VM est figée, nous n'avons pas mis en place les "migrations dynamiques". On ne déplace les VM que "à froid".

@Tabouret, taille disque.
Non, aucun problème de taille. j'utilise quotidiennement le df -m comme outil de surveillance, et je suis stable et large.
... Mais je suis d'accord avec toi, il m'est arrivé, par exemple lors de la reindexation de la base de données (le WE), d'avoir "disk full" alors que ni par "ls" ni par "du" je n'avais de gros fichier. Mais le mécanisme de reindexation crée un énorme fichier temporaire de travail, qui n'est jamais fermé (ou de manière très éphémère) et qui est détruit dans la foulée. Et donc en cours de processus, quand on lance des "df -m" on voit la place disque qui fond comme neige au soleil... sans voir de fichier (oui, la première fois ça perturbe bien).

J'ai juste la mémoire dispo qui diminue avec les connexions d'utilisateurs, mais avec un mini à 17Mo (sur 4Go), et le swap (taillé à 8Go) n'est pas utilisé du tout. Si j'arrivais à saturer la mémoire, le swap serait sollicité, ça ralentirait tout le monde, mais ça ne laisserait pas comme ça utilisateurs bosser comme si de rien n'était, mais en bloquant tout lancement de nouveau process...

J-Michel

[tabouret]

Bon très peu de chances que ce soit ça mais vérifie quand même la swapiness.