Si QTIME01 est beaucoup plus haut que le champ DELTACPU, ce peut être l’indication d’un polling de processeur partagé LPAR.

Partant de la même charge de travail, les données de performances collectées pour un job montrent généralement qu’il a utilisé la CPU plus fréquemment sur un processeur à deux voies que sur un processeur à une voie. On peut dire la même chose si l’on compare le temps de CPU du job sur n’importe quel processeur à n-voies par rapport à un processeur à (n-k)-voies.

Selon IBM, le prix à payer pour invoquer des processeurs partagés est souvent de 5 %, ce qui signifie que l’adoption de processeurs entier peut en fait améliorer les performances de grandes machines.

Si vous utilisez des processeurs dédiés ou si votre système utilise moins de 100 % de la CPU, il est probable que vous ne constaterez pas beaucoup de différence de performances sur l’ensemble. En revanche, quand le système est occupé à 100 % et que LPAR se consacre à ses recherches, il y aura dégradation. Company aBc constate cela quand elle alloue plus de processeurs à la partition applicative et baisse la demande de CPU en pic de charge de travail au-dessous de 100 %.

Ne vous méprenez pas sur mes propos : LPAR est superbe et, à condition de bien soigner le développement et l’exploitation des applications, sa performance est excellente. Mais, comme avec tout mécanisme très puissant, pour tirer le maximum de LPAR, il faut lire sa documentation et la comprendre. Si vous envisagez des pics de demande de capacité, vous devez les gérer. De plus, l’effet de l’allocation de processeur LPAR est compliqué à prévoir et à modéliser. Dans bien des cas, on ne peut l’observer et le mesurer qu’à posteriori. Ainsi, certains LPAR qui bénéficient de processeurs non limités, peuvent voir une moyenne de 55 % d’utilisation de CPU et atteindre des pics d’utilisation de CPU de 150 %