Changer la taille des pools

utilisant l’information d’activité de pool du rapport de composants. Le rapport montre la taille de chaque pool de stockage principal à la fin de chaque intervalle de collection. Vous constaterez peut-être une forte corrélation entre une haute activité d’écriture d’I/O disque et d’importants changements dans la taille des pools.

Traitement de la taille des pools du stockage principal. Vous pouvez attribuer une quantité de stockage principal à chacun des pools de stockage principal du système. Le système a besoin de deux pools : le pool Machine (pool 1) et le pool Base (pool 2, *Base). Vous pouvez établir jusqu’à 64 pools en démarrant, modifiant et terminant des sous-systèmes. Le stockage principal pour tous les pools est pris de, et renvoyé à, *Base.

La taille d’un pool de stockage principal change en interne quand les trames de pages passent d’un pool à un autre. Selon le réglage de l’option automatic pool tuning du système (valeur système QPFRADJ), la tentative d’atténuer la forte demande de page d’un pool peut être automatique. Le système peut déplacer des pages supplémentaires dans le pool. Vous pouvez manuellement déplacer des pages dans un pool en changeant sa taille avec la commande WRKSYSSTS. En outre, un nouveau pool peut être créé quand un sous-système attribué à un pool privé démarre.

Dans toutes ces situations, si certaines des trames de page « à déplacer » ont été changées, elles sont écrites par la tâche SMPO001 avant d’être effacées et transférées dans le pool de destination. Cela peut influencer la performance système globale pendant un temps relativement long, allant de quelques secondes à quelques minutes, selon le nombre de pages changées transférées dans le pool cible. Pourquoi en est-il ainsi ? Pour accroître la taille d’un pool, un certain nombre de trames de page sont déplacées à partir de *Base ; pour diminuer la taille du pool, un certain nombre de trames sont déplacées dans *Base. Chaque trame de page déplacée est d’abord débarrassée de son contenu et de l’attribution d’adresse virtuelle. Pour chaque trame de page dont le bit « change » est sur on (indiquant que les données dans la trame de page ont été modifiées), la trame de page écrit d’abord sur disque et son bit change est réinitialisé afin que la trame puisse être effacée avant d’arriver au pool de destination.

L’activité de tâche SMPO001 peut aussi indiquer que la disponibilité de trames de pages d’un pool est dangereusement basse, ou que la gestion du stockage SLIC a déterminé la présence de défauts de page excessifs dans un pool. Si la demande de pages de pool de stockage est suffisamment importante pour causer un nombre de défauts de pages supérieur à la normale, Storage Management purge les pages changées les plus anciennes du pool pour rendre davantage de trames de pages disponibles. Une purge continue peut survenir dans certains cas et indique généralement que le pool est sous-dimensionné ou que la demande est trop forte. Quand la disponibilité des trames de pages du pool est basse, vous pouvez choisir entre deux approches. La première consiste à définir la taille d’un pool avec une valeur permettant aux applications d’honorer le niveau de service de performance nécessaire – ne laissez pas à Dynamic Pool Adjuster le soin de changer le pool. Pour cela, vous pouvez soit changer la taille du pool à la volée (n’utilisez pas QPFRADJ) ou exécuter les applications dans un pool privé, que QPFRADJ ignore. La seconde approche consiste à comprendre et à planifier les charges de travail critiques pour éviter l’activité d’I/O disque associée au changement de taille de pool, quand les sous-systèmes démarrent et s’arrêtent.

Le système de Company aBc subit des tâches de sortie de page de haute priorité pendant les périodes de fortes demandes. En aval, l’écriture d’un tel nombre de trames de pages aussi rapidement se traduit par une haute mise en file d’attente des I/O disque. Il n’est pas possible de prévoir l’impact sur la performance d’I/O disque parce qu’il n’y a pas de moyen de savoir combien de pages modifiées participent au changement de taille du pool. Comme le système subit beaucoup de défauts de pages pendant les pointes de charge de travail et si QPFRADJ est sur on, le système transfère les trames de pages vers les pools avec beaucoup de défauts. Les nombreux défauts entraînent une forte activité d’I/O disque, pendant que les trames de pages changées et à transférer sont effacées et écrites individuellement. Cela illustre comment la performance se dégrade au fur et à mesure que le nombre de défauts de pool augmente.

Il est un autre scénario fréquent : à la fin d’un jour de travail interactif, le sous-système interactif QINTER s’arrête, et le ou les sous-systèmes batch deviennent plus actifs. Si QINTER tourne dans un pool de 4 Go et si 10 % de ses pages ont leur bit change activé, le système doit écrire environ 100 000 trames de pages. Cela peut prendre longtemps et augmentera probablement beaucoup le contenu du cache d’écriture. Comme toutes les opérations disque sont du FIFO planifié, beaucoup des opérations disque d’applications rencontrent de longs temps d’attente en raison de la file d’attente derrière les opérations de purge. Cela a généralement un effet visible et négatif sur le débit des applications.

La trame de page du stockage principal de l’iSeries représente 4 096 octets de mémoire. La figure 1 montre le nombre de trames de pages pour le pool de stockage principal ou la taille de mémoire totale. Notons au passage que 1 Go de mémoire demande 262 144 trames de pages.