> Tech > Environnement WAS et ressources système

Environnement WAS et ressources système

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Naturellement, le job du serveur d’applications lui-même est un bon point de départ. Les performances de vos applications WAS seront affectées directement par deux facteurs : la quantité de mémoire dont dispose le serveur d’applications et la contention dont cette mémoire fait l’objet. Nous n’entrerons pas dans les détails de

ce sujet, car il existe beaucoup de white papers traitant de WAS sur l’iSeries, qui expliquent la manière d’aménager un pool de mémoire partagée (SHR POOL) pour le serveur d’applications. Il est souhaitable que ce SHRPOOL soit dédié afin qu’aucune autre application ne l’utilise. Vous utilisez déjà les SHRPOOL sur l’iSeries pour réserver de la mémoire disponible au service d’un job ou d’un ensemble de jobs. La présence de pools définis permet aux utilisateurs de mieux contrôler quels jobs utilisent les ressources mémoire du système. Sur l’iSeries, la mémoire ne peut pas être dédiée directement à un job spécifique. Elle est attribuée à un pool et les jobs sont attribués aux pools.

Lors de la création d’un SHRPOOL, il faut s’assurer que le pool ainsi constitué contient assez de mémoire pour éviter ces défauts de page tant redoutés. Même si ce n’est pas toujours vrai pour les charges de travail OS/400 traditionnelles, les défauts de page dans le pool exécutant un serveur d’applications indiquent généralement une mémoire insuffisante. Le job du serveur d’applications est beaucoup plus sensible aux défauts de page qu’un job traditionnel. Le moyen le plus simple d’identifier des défauts de page dans un pool mémoire consiste à utiliser la commande WRKSYSSTS (Work with System Status). Cette commande fournit une interface écran qui montre le nombre de défauts pour les I/O base de données et non-base de données. Aucun nombre particulier de défauts ne représente un problème ; cependant, il faut tendre vers zéro défaut non-base de données pour le pool qui héberge le serveur d’applications. La situation se corse quand les défauts non-base de données dans le pool commencent à augmenter. Même des niveaux de défauts peu élevés entraîneront une dégradation perceptible des temps de réponse, mais un très haut niveau de défauts peut engendrer des temps de réponse intolérables.

Pour maintenir des temps de réponse réguliers, gardez les mêmes valeurs minimum et maximum pour certains paramètres du conteneur du serveur d’applications. Il faut donc garder la même valeur pour le nombre minimum et maximum de threads pour le conteneur, ainsi que pour le nombre de threads utilisés pour l’une quelconque des sources de données définies. Cette façon de faire lisse les temps limites de réponse et facilite le diagnostic des problèmes. Quand les threads minimum et maximum sont différents, le système consacre des cycles à essayer de maintenir les limites de seuil. Ce surcroît de maintenance et, surtout, le moment où il se produit, peut faire varier les temps de réponse.

Il est souvent judicieux d’établir une partition logique où toutes les ressources peuvent être dédiées à 100 % à la charge de travail du serveur d’applications. Dans un tel environnement, les threads du serveur d’applications n’ont pas à lutter pour des ressources avec les autres jobs actifs sur le système. Autre avantage d’une partition dédiée : il est plus facile de séparer et gérer les jobs base de données sur un système base de données d’arrière-plan. Le fait d’avoir une partition séparée pour le serveur d’applications lui permet d’avoir sa propre adresse IP. Vous pouvez acheminer les requêtes base de données d’après cette adresse IP pour mieux contrôler quels jobs en arrière-plan travailleront d’après les requêtes provenant du serveur d’applications (pour plus d’informations sur la configuration, voir « Host Server Customization Requirements for TCP/IP Address and Subnet Mask », numéro de document 355207973, à www- 912.ibm.com/s_dir/slkbase.nsf/slkbase). Ce thème nous amène tout naturellement au domaine suivant : la base de données.

Téléchargez cette ressource

Cybersécurité des collectivités : Enjeux, Perspectives & Solutions

Cybersécurité des collectivités : Enjeux, Perspectives & Solutions

Villes, intercommunalités, métropoles, départements et régions sont particulièrement exposés aux risques de cybersécurité. Ce livre blanc Stormshield présente les défis cyber que rencontrent les collectivités, les solutions et perspectives pour qu’elles puissent assurer leur mission d’utilité publique, en toute sécurité.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010