Performance Probleme nach Releasewechsel von V5R3 nach V5R4

[tfroehlich]

Hallo *ALL,

nach einem Releasewechsel von V5R3 nach V5R4 gibt es starke Performanceprobleme (lange Antwortzeiten). Es handelt sich hierbei um eine recht große Maschine mit mehreren Partitionen. Das Performanceproblem tritt nur auf einer Partition auf. Dort laufen etwa 9000 Jobs, wobei die CPU bei etwa 50% Auslastung steht. Es wurden auch schon die neusten PTFs eingespielt.

Bis auf den Releasewechsel hat sich sonst nichts an den restlichen Anwendungen auf der Maschine verändert.

Hat von euch schonmal jemand solch ein Problem festgestellt?

Viele Grüße
Matthias

--------------------------------------------------------
Hallo Matthias,

hast Du schon den Befehl WRKSYSACT schon probiert?

Vielleicht siehst Du damit den Job, der die Maschine lahm legt.

Gruss Thomas

[schatte]

--------------------------------------------------------
Hallo Matthias,

hast Du schon den Befehl WRKSYSACT schon probiert?

Vielleicht siehst Du damit den Job, der die Maschine lahm legt.

Gruss Thomas

In WRKSYSACT sieht auch alles normal aus. Also keine besonderen IBM Jobs oder sonstige Jobs.

[schatte]

Hallo,

das Problem hat sich gestern gelöst. Es hat wohl an der Konfiguration der virtuellen CPUs für diese Partition gelegen. Man hat die Anzahl der virtuellen CPUs verkleinert. Jetzt läuft die Partition auch wieder sehr performant.

Seltsam ist nur, dass sich die Konfiguration nach dem Releasewechsel nicht geändert hatte. Also scheint es doch noch ein Problem von V5R4 zu sein.

Viele Grüße
Matthias

[holgerscherer]

Seltsam ist nur, dass sich die Konfiguration nach dem Releasewechsel nicht geändert hatte. Also scheint es doch noch ein Problem von V5R4 zu sein.

Viele Grüße
Matthias

Wie sah denn die LPAR Config im Detail aus? Sind alle Partitionen (oder zumindest die primäre) auch auf V5R4 gehoben worden? Davon ist ja auszugehen ;-)
V5R4 hat eine etwas andere, abweichende Behandlung der virtuellen CPUs, so dass möglicherweise beim Update der Hypervisor der Meinung war, die besagte LPAR auf drei Fragmente von CPUs zu verteilen. Immerhin sah man im WRKSYSACT eine gewaltige Fehlseitenbedingung in den Pools 2 und 4, die sich (wenn es ein normaler Mangel an RAM) auch auf die Plattenaktivität auswirken sollte. Daher ist es höchstwahrscheinlich, dass die LPAR-Config sich verschoben hat und die CPUs eher damit beschäftigt waren, das BRANCHen zwischen den einzelnen Jobs ständig neu zu würfeln. Wieviel CPUs sind in der Box drin?

-h