[z/OS]

Conditions du délai d'expiration - causes et correctifs possibles

Ce fichier répertorie les variables de délai courantes et les outils destinés au contrôle de ces conditions du délai d'expiration

L'horloge qui expire en premier risque de ne pas indiquer le problème qui doit être résolu. Pour diagnostiquer correctement les conditions du délai d'expiration, vous devez connaître toutes les valeurs de l'horloge qui peuvent être appliquées à une région serviteur particulière.

Tableau 1. Conditions du délai d'expiration - causes et correctifs possibles. Vous pouvez utiliser ces variables de délai courantes pour contrôler les conditions du délai d'expiration.
Type général de l'horloge Causes possibles Solutions possibles
Entrée Le client n'a envoyé qu'une partie des données et l'envoi du reste des données a été retardé. L'application du côté client risque de retenter de mettre la logique en place si elle reçoit un code mineur d'expiration en retour.
Session La session est en veille lorsqu'elle n'est pas utilisée. Si vous considérez la perte des sessions en veille comme un problème, augmentez les valeurs des délais d'expiration des sessions persistantes ou utilisez la session plus fréquemment.
Répartition WLM Aucune unité d'exécution n'est libre pour traiter la requête à cause de l'une des conditions suivantes :
  • Les unités d'exécution sont toutes des requêtes de traitement occupées.
  • Les unités d'exécution actives attendent une réponse de DB2, WebSphere MQ, d'un autre serveur et ainsi de suite. Dans ce cas, recherchez des messages indiquant un conflit de ressources. Par exemple, vous risquez de voir sur la console z/OS des messages relatifs aux blocages DB2.

Dans les deux cas, la requête expire l'attente dans la file d'attente WLM à expédier dans un serviteur (région).

Le cas dans lequel les unités d'exécution sont toutes des requêtes de traitement occupées peut indiquer l'une des conditions suivantes :
  • Le nombre de régions serviteur que WLM peut lancer est trop faible. Pour définir cette valeur, sélectionnez Serveurs >Serveurs d'applications >nom_serveur >Instance de serveur dans la console d'administration. Cliquez sur Plusieurs instances activées et spécifiez une valeur pour le Nombre maximal d'instances.
  • Le nombre d'unités d'exécution admises dans une région serviteur est trop faible. Ce nombre est contrôlé par le paramètre des règles d'isolement de la console d'administration ou la variable WebSphere : profil_charge_travail_région_serveur
  • Vous devez répliquer des serveurs pour gérer la quantité de travail entrant.
Toutes ces conditions indiquent que le réglage des performances peut être nécessaire.
Transaction Les causes possibles des expirations des transactions comprennent :
  • Les mêmes que celles concernant l'expiration de la répartition WLM ou
  • Des retards qui empêchent le coordinateur de transactions de valider ou d'annuler une transaction pendant le délai imparti.
Voir les solutions possibles pour les expirations de la répartition WLM. En outre, vous pouvez rechercher des messages indiquant un conflit de ressources impliquées dans la transaction qui a expiré.
Sortie Les causes possibles des expirations de la sortie sont les mêmes que celles de la répartition WLM (la répartition est pour le protocole IIOP, la sortie est pour le protocole HTTP). Voir les solutions possibles pour les expirations de la répartition WLM. De plus, vous pouvez utiliser la variable WebSphere protocol_accept_ http_work _after_min_srs=1 pour empêcher le gestionnaire du transport HTTP de répartir des demandes tant que WLM n'a pas démarré un minimum de régions serviteur.

Icône indiquant le type de rubrique Rubrique de référence



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rtrb_fixtimeout
Nom du fichier : rtrb_fixtimeout.html