![[z/OS]](../images/ngzos.gif)
Valeurs de délai d'expiration : Instructions pour la modification des valeurs de délai d'expiration
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
En règle générale, l'augmentation des valeurs de délai d'expiration doit être votre dernier recours ou seulement une action temporaire pour éviter que la multiplication des clichés de fins anormales liées au délai d'expiration n'entame les performances du système. Si vous augmentez les valeurs de délai d'expiration sans avoir dûment diagnostiqué l'expiration de délai, les seuls résultats que vous pourrez obtenir sont des clichés et des fins anormales moins fréquents pour la même expiration de délai ou des performances d'applications ou de système ralenties.
Pour plus d'informations sur la façon de définir des valeurs pour ces variables de délai et sur la façon dont ces variables mappent vers des variables internes, consultez Contrôler le comportement via les valeurs de délai
(Certaines variables WebSphere sont présentées sur plusieurs lignes à des fins d'affichage.
Variable WebSphere et sa relation, si elle existe, avec les autres délais | Comment contrôler le traitement de ce type d'expiration de délai : | Si vous voulez modifier la valeur, prenez en compte ce qui suit : |
---|---|---|
Délai d'attente WLM Pour le travail HTTP et Scalable Messaging Support, le délai WLM n'est pas défini et seul ConnectionResponseTimeout est activé (recouvrant entièrement la fenêtre de distribution) |
SMF fournit des données sur le temps que WLM a passé en file d'attente | Le temps pris par le travail pour arriver à un serviteur dépend de plusieurs facteurs : le nombre de serviteurs démarrés par WLM, le nombre de serviteurs que vous le laissez démarrer, le nombre de classes de service sur lesquelles le travail est réparti, le nombre de travaux que vous obtenez et ainsi de suite. |
ConnectionIOTimeOut Aucun. |
Ce comportement n'est pas facile à contrôler. Activer un point de trace indiquerait si un client a échoué en raison de ce paramètre de délai d'expiration, cependant la fonction de trace a des conséquences sur les performances. |
|
ConnectionResponseTimeout Si le composant de l'application démarre des transactions, les délais de transaction peuvent également être impliqués. |
Ce comportement n'est pas facile à surveiller mais le contrôleur arrêtera le serviteur (région) avec une fin anormale EC3 pour cette expiration de délai. |
|
ConnectionKeepAliveTimeout Aucun. Tous les autres délais sont relatifs au traitement du travail, tandis que ce dernier est relatif à ce qui se passe lorsqu'il n'y a pas de travail. |
Aucun. | Attendre entre les demandes ou dépenser pour établir une nouvelle session. Vous pouvez avoir envie de garder des sessions en veille pendant un moment pour éviter le coût de démarrage d'une nouvelle session sans vouloir les garder éternellement étant donné que l'accumulation d'utilisations de ressources peut provoquer un incident. |
Délai d'expiration de la demande (Service ORB) Aucun. Cette variable est un délai d'expiration côté client et seulement IIOP. |
Aucun moyen de contrôler, excepté pour observer les délais d'expiration se produisant du côté du client. | Pendant combien de temps acceptez-vous de laisser un client attendre ? |
Elément actif du programme d'écoute de l'ORB Elément actif du programme d'écoute SSL de l'ORB Aucun. Ces variables sont relatives à une activité de session pendant des périodes de veille et seulement pour IIOP, ces délais d'expiration n'interagissent donc pas avec le délai d'expiration ConnectionKeepAliveTimeout. |
Vous devez lire TCP/IP APAR PQ18618 pour plus d'informations sur les valeurs SOCK_TCP_KEEPALIVEet leurs conséquences. |
Est-il utile d'avoir un délai d'expiration pour les sessions en veille ? En principe, non, car cela peut consommer des ressources. Cependant, détecter un délai d'expiration nécessite un trafic réseau entre les piles TCP/IP. Autrement dit, créer un trafic sur des sessions en veille peut avoir des conséquences indésirables sur le réseau. |
Délai d'expiration de la durée de vie totale d'une transaction Cette variable peut être remplacée par des applications jusqu'au maximum indiqué par la variable Délai d'expiration maximal des transactions, ce qui limite la durée qu'une application peut définir pour que ses transactions s'effectuent. Il se peut également que les délais de sortie provoquent une expiration du travail mais les délais de transaction et les délais de sortie ne se reconnaissent pas entre eux. |
Le contrôleur émet le message BBOT0003W pour indiquer une expiration de délai et arrête le serviteur (région) avec les codes motif de fin anormale EC3, 04130002 ou 04130005. |
|
Délai d'expiration maximal des transactions Lorsqu'elle est définie, cette variable limite la durée qu'une application peut définir pour que ses transactions s'effectuent. Lorsque la variable Délai d'expiration maximal des transactions est définie, les transactions d'applications sont contrôlées par le délai défini sur la variable Dépassement du délai autorisé pour la durée de vie des transactions. |
Aucun. | Les considérations sont les mêmes pour transaction_ defaultTimeout |
transaction_ recoveryTimeout Aucune |
Aucun. | Les verrous sont maintenus tant qu'un contrôleur attend que les autres contrôleurs nécessaires résolvent les transactions en attente de validation. Combien de temps pouvez-vous attendre pour utiliser ces ressources ? |
server_region_request_cputimeused_limit | Ce comportement n'est pas facile à surveiller mais le contrôleur arrêtera une requête lorsque la limite de temps d'utilisation de l'unité centrale est atteinte. |
|
|
Ce comportement n'est pas facile à surveiller mais le contrôleur arrêtera le serviteur avec une fin anormale EC3 lorsque le pourcentage d'unités d'exécution qui ne répondent pas remplit cette condition. |
|