Dossier Administration : Configuration de Work Management

Supposons que votre charge de travail normale et quotidienne ressemble à celle du Scénario 1 :

• Utilisateurs 5250 interactifs : 50 % de la charge de travail
• Utilisateurs connectés ODBC : 5 %
• Serveur HTTP: 5 %
• Jobs batch : 15 %
• Writers d’impression : 2 %
• Système : 15 %
• Autres : 8 %

Bien que cet exemple ne représente pas forcément chaque serveur de production exécutant
IBM i, il constituera un bon point de départ pour comprendre les principes élémentaires. (Il vous faudra établir votre propre configuration Work Management d’après les exigences de votre société.)

Premièrement, déterminez votre préférence quant au fonctionnement de l’ajusteur de performance automatique. Les pools partagés définis ont deux paramètres de tailles de pool. Sur la commande pour écran vert WRKSHRPOOL, vous verrez ces paramètres sous l’intitulé Size % avec labels Minimum et Maximum. En utilisant IBM Navigator for i, cliquez sur Work Management|Memory Pools|Shared Pools. Les colonnes que nous utiliserons sont Tuning – Minimum Size et Tuning – Maximum Size.

Comme les valeurs usine minimale et maximale sont 1 et 100, l’ajusteur de performance automatique est souvent occupé toute la journée à régler vers le haut et vers le bas. Si vous définissez ces limites selon une fenêtre plus étroite, l’ajusteur de performance automatique passera moins de temps au réglage. (Mais rappelons que vous ne pouvez pas allouer plus de 100 % du système aux pourcentages minimums combinés.) Ici, j’ai appliqué les exigences des charges de travail du scénario 1 pour créer la configuration que l’on voit dans la figure 1. Quand la demande survient, il faut qu’il y ait assez de mémoire disponible, mais pas au point de la gaspiller.

Dans cet exemple, le pool mémoire batch a un minimum de 15 %. Cela suppose qu’il y aura un flux constant de jobs batch au travers des sous-systèmes associés. Si, à un moment, il n’y a pas de jobs dans ces sous-systèmes, 15 % de la mémoire du serveur seront utilisés. A l’inverse, si vous fixez un minimum bas et si une vague de jobs batch démarrent dans ces sous-systèmes, l’ajusteur de performance automatique passera du temps à surveiller et à allouer plus de mémoire, jusqu’à ce que le pool partagé ait ce dont il a besoin. Malheureusement, cette façon de faire réduit le temps passé à réellement traiter ces jobs, au risque de dégrader la performance globale du serveur.

Pour la plupart des entreprises, l’équilibre de charge de travail initial est trouvé « pifométriquement » ; mais, si vous comprenez les exigences de charge de travail sur votre serveur, vous pouvez réduire le champ des suppositions. Commencez par demander conseil à quelqu’un d’expérimenté en réglage de systèmes multiples. Après avoir déterminé les minimums et maximums pour le scénario d’usage quotidien normal, vous devez vous occuper des autres scénarios que votre serveur rencontrera. Le traitement de nuit est un bon point de départ : la charge de travail batch est supérieure et la charge de travail interactive est nettement réduite. Si je laisse la configuration Work Management du scénario 1 en l’état pour le traitement nocturne, cette configuration restreindra les ressources disponibles pour le travail batch à traiter. Par exemple, un de mes clients avait un job batch nocturne critique dont l’exécution prenait quatre heures. En appliquant une configuration plus orientée batch à la fin du jour de travail, le client a ramené ce temps à 90 minutes seulement.