Aller au contenu
  • Société
    • Qui sommes-nous
    • Nos valeurs
    • Nos partenaires
    • Entreprise citoyenne
    • Régions
  • Services
    • Expertise
    • Formation
    • Développement
    • Migration
    • Infogérance
  • Join the Team
  • Actualités
  • Blog
    • Blog easyteam.fr
    • Blog Cloud Natives
  • Formations
  • Rugb’Easyteam
  • Contact
Menu
  • Société
    • Qui sommes-nous
    • Nos valeurs
    • Nos partenaires
    • Entreprise citoyenne
    • Régions
  • Services
    • Expertise
    • Formation
    • Développement
    • Migration
    • Infogérance
  • Join the Team
  • Actualités
  • Blog
    • Blog easyteam.fr
    • Blog Cloud Natives
  • Formations
  • Rugb’Easyteam
  • Contact
Inscrivez-vous à la newsletter

Inscrivez-vous à la newsletter

Abonnez-vous maintenant et nous vous tiendrons au courant.
Nous respectons votre vie privée. Vous pouvez vous désabonner à tout moment.

Bienvenue sur le Blog d'EASYTEAM (ex ArKZoYd)

  • Accueil
  • Actualités
  • Cloud
  • Infrastructure
  • Données / Sécurité
  • Intégration
  • Dev / DevOps
  • SAM / FinOps
Menu
  • Accueil
  • Actualités
  • Cloud
  • Infrastructure
  • Données / Sécurité
  • Intégration
  • Dev / DevOps
  • SAM / FinOps
  • le 12/04/2019
  • Olivier Docquois
  • Java, Middleware

Stuck Threads sur le terrain

Partager sur linkedin
LinkedIn
Partager sur twitter
Twitter
Partager sur facebook
Facebook

Cet article se veut pragmatique et est un retour d’expérience terrain.
Il n’a pas la vocation à expliquer les concepts de base des pools de connexion, des Threads ou des work managers qui ont déjà été expliqués par mes collègues.

 

Posons le sujet :

Il arrive fréquemment que nos clients observent des Stuck Threads sur le serveur sans savoir réellement si cela impacte leur production et comment y remédier.

L’analyse des Stuck Threads nécessite une analyse approfondie de votre infrastructure et de votre architecture. C’est un travail d’expert qui est réalisé lors de mission de conseils techniques.

Easyteam, par sa vocation, peut vous aider. Nous fournissons ce service à nos clients.

 

Qu’est-ce qu’un Stuck Threads ?

Le Stuck Threads est un révélateur de performance de votre application.

Il concerne une ressource allouée à votre application mais surtout traduit son occupation, c’est à dire comment vous l’utilisez.

 

Comment cela se traduit-il ?

Weblogic Server surveille vos traitements, plus exactement vos fils : les « thread » de processus. Dès lors qu’un fil est occupé depuis un certain temps, Weblogic le considère bloqué : c’est le « Stuck ».

Un Stuck Threads est donc la traduction d’une occupation considérée anormale par le serveur. Mais voilà, une valeur anormale pour votre serveur peut être acceptable par vous-même…

 

Quelle est l’origine des Stuck Threads ?

Il peut y avoir de nombreuses raisons pour lesquelles un fil est bloqué.

Cependant, l’origine est souvent une ressource indisponible.

Très communément, il faut orienter les recherches vers les pools JDBC, les connexions externes : les web services, les sockets, et caetera.

Mais une ressource peut aussi simplement être occupée par un traitement long de votre application. Dans ce cas, c’est un comportement normal, voire attendu.

 

Comment identifier les Stuck Threads ?

Le Stuck Threads doit être une alerte pour votre équipe.

Il faut rechercher son origine, c’est à dire identifier la ressource bloquée.

  •  Tout d’abord, il faut consulter et analyser la log.
  • Ensuite, et pour aller plus loin, il est conseillé d’effectuer une opération de ‘vidage’ du fil : c’est le  « threads dump ». On peut s’aider d’outils spécialisés comme thredlogic ou jmeter. Il est également possible de créer une notification de type « Diagnostic Image » à partir de la console Weblogic.

Ces informations vous permettent d’isoler la « root cause » de l’avertissement.

 

Est-ce grave ?

Tout d’abord, est-ce que mon serveur Weblogic va tomber, i.e. passer au statut FAILED ?

C’est une fausse idée préconçue…

  • Tout d’abord, non, car Weblogic est configuré ainsi : la valeur par défaut de Failure Action est Ignore, take no action.
  • Ensuite, un délai définit l’alerte : c’est le MaxStuckThreadTime (600 secondes par défaut).
  • Enfin, il existe un seuil pour le nombre de Threads à partir duquel le serveur va réagir. La valeur par défaut de Stuck Threads Count est de à 0 (zéro). L’état FAILED se déclenchera uniquement si cette valeur est positive ! Encore une fois, seul l’état « Health » de votre serveur passera à WARNING.

C’est à vous de faire ces ajustements.

Ensuite, il y a une seconde question : est-ce que le service est rendu ?

Il faut pondérer : ce n’est pas parce qu’un fil est bloqué qu’il est inutilisable ; tout dépend du comportement qui s’en suit !

 

Est-ce que la situation va se rétablir d’elle même ?

Tout d’abord, ne tuez pas vos Threads en exécution : ce n’est pas faisable en java.

  • Ensuite, et normalement, les Threads bloqués disparaissent si les conditions de blocages sont levées. Alors oui : ici, le service est rendu… mais nous vous dispense pas d’une analyse approfondie de l’organe du problème et d’y remédier.
  • Cependant le nombre de threads bloqués peut augmenter jusqu’à bloquer votre application puis votre serveur Weblogic. Cela peut être le cas si la capacité mémoire de la JVM est atteinte… Alors non : ici vous êtes bloqué ! Dans ce cas, il pourrait être judicieux de redémarrer le noeud (node) impacté.

 

Illustration :

Un client rencontre un grand nombre de Stuck Threads dans ces logs :

  1. La lecture de la trace montre l’origine : un pool JDBC. Cela traduit que la connexion vers la base de données est bloquée.
  2. Il faut alors analyser la stack trace pour détecter des problèmes. Nous relevons l’erreur java.net.SocketInputStream.socketRead0.
  3. La base de données n’a pas répondu à l’ouverture demandée par la pool jdbc du serveur Weblogic. L’origine est donc un problème externe. Dans ce cas, il faut se rapprocher de l’administrateur de la base de données. Celui-ci détectera des blocages de sessions et y remédiera.
  4. Comme la situation perdure au delà des seuils, il est logique que le threads soit considéré comme bloqué par le serveur Weblogic qui porte la connexion jdbc bien que le problème ait pour origine un dysfonctionnement de la base de données.

Nb : un autre axe de réflexion aurait pu être le réseau puisque l’indicateur est une erreur de Socket.

 

Conclusion :

Un Stuck Threads traduit l’occupation d’un fil à un instant ‘t’.

Là est souvent l’erreur : il traduit l’occupation d’une ressource, pas obligatoirement un blocage !

Il faut être alerté lorsque l’occupation de la ressource est anomale. C’est une question de sensibilité. Il faut rechercher pourquoi le Thread prend un temps jugé anormal pour traiter le travail qui lui est assigné.

Bien entendu, le scénario catastrophe sera l’occupation complète des ressources du serveur Weblogic jusqu’à son « plantage » mais ce n’est pas systématique !

La bonne pratique est toujours de trouver les causes du fil bloqué et d’y remédier pour les éviter complètement plutôt que de réagir à une alerte du serveur.

Une fois votre infrastructure et votre application optimisées, alors il conviendra de s’assurer du « fine tuning » de votre serveur puis définir le comportement face aux Stuck Threads jugé ‘anormaux’.

 

Voilà, nous espérons que ce petit article sera une bonne introduction pour le gestion des fils, des occupation de ressources, un ébauche d’analyse et surtout un guide sur le fine tuning de votre serveur et les comportements à adopter.

 

Pour aller plus loin :
  1. OSB : « Stuck Threads » sur la consommation de fichiers : https://easyteam.fr/osb-stuck-threads-sur-la-consommation-de-fichiers/
  2. Sensibilisation autour du Work Manager https://easyteam.fr/sensibilisation-autour-du-work-manager/

 

Olivier Docquois
Olivier Docquois
Voir tous ses articles
Partager sur linkedin
LinkedIn
Partager sur twitter
Twitter
Partager sur facebook
Facebook

Laisser un commentaire Annuler la réponse

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Les derniers articles

  • Customiser le monitoring des ressources Weblogic avec JMX 01/03/2021
  • Modernisation d’Oracle SOA Suite 22/02/2021
  • SQL Server 2019 : nouveauté TDE 15/02/2021
  • Libérer de l’espace sur les serveurs Oracle Weblogic 08/02/2021
  • Perdre Un Nœud d’un Cluster Always On 01/02/2021

Les derniers commentaires

  • PEDRO dans Contention du listener : Comment désactiver la notification ?
  • SY dans Oracle Database 12c In-Memory: Configuration/Découverte de l’option
  • Jeancy dans Configurer la messagerie de l’Agent SQL Server en vue de l’utilisation de la messagerie de base de données
  • Libérer de l'espace sur les serveurs Oracle Weblogic - EASYTEAM dans "Dans le doute, reboot !" et si on rendait cela scriptable et modulable !
  • Arnaud dans OCI Designer Toolkit : Créer, visualiser et déployer vos environnements OCI graphiquement
Espace Membres
Mot de passe perdu ?
EASYTEAM

Tour Nova, 71 Boulevard National,
92250 La Garenne-Colombes
Tél. 0800 40 60 40
contact@easyteam.fr

Facebook
Linkedin
Twitter
Navigation
  • Accueil
  • Qui sommes-nous
  • Entreprise citoyenne
  • Nos valeurs
  • Régions
  • Partenaires
  • Contact
  • Support
Menu
  • Accueil
  • Qui sommes-nous
  • Entreprise citoyenne
  • Nos valeurs
  • Régions
  • Partenaires
  • Contact
  • Support
Services
  • Développement
  • Migration
  • Infogérance
  • Expertise
  • Formation
Menu
  • Développement
  • Migration
  • Infogérance
  • Expertise
  • Formation
Blog
  • Cloud
  • Infrastructures
  • Data
  • Intégration
  • Dev / DevOps
  • SAM / FinOps
  • Applications
Menu
  • Cloud
  • Infrastructures
  • Data
  • Intégration
  • Dev / DevOps
  • SAM / FinOps
  • Applications
Copyright 2018 - EASYTEAM, Tous droits réservés
Mentions légales
Politique de confidentialité​