Priosisierung von Subsystemen 6.1.0

[dbausnnd]

Hallo Zusammen,

aus Performancegründen möchte ich bestimmte Subsysteme niedrieger priorisieren oder besser gesagt die Subsysteme sollen nicht mehr so viel ressourcen ziehen.

Dabei hatte ich ursprünglich die zugewiesene Pool größe fix auf 1gb gesetzt. Wiedererwartend war sehr viel Aktivitäe im SBS vorhanden, was in einer extrem hohen CPU Auslastung und Plattenarm Auslastung wiederspiegelte.
Ich habe den Pool auf *CALC wieder gesetzt.

Weiter habe ich die Zeitscheibe auf 2000ms verringert und die maximale Wartezeit auf 120 erhöht (Klasse). Leider bin ich mir nicht sicher ob das die korrekten Parameter sind oder ob es evtl weitere Bereiche für Einschränkungen gibt.

Über Tips wäre ich sehr dankbar.

Gruß

dbausnnd.

[Fuerchau]

Die Zeitscheibe spielt nur dann eine Rolle, wenn ein Programm mal tatsächlich länger irgendwas rechnet.
Jeder IO unterbricht die Zeitscheibe aber vorzeitig, so dass dieser Wert selten Auswirkungen zeigt.

Die Wartezeit gilt nur für exclusive Objektsperren z.B. ALCOBJ, die keine eigene Wartezeit definieren.

Gesteuert wird das ganze über die Ausführungspriorität der Klasse, die über den Leitwegeintrag eines SBS zugeordnet wird!

Ablaufpriorität - Hilfetext

Die Ablaufpriorität, verglichen mit der Priorität anderer
im System ablaufender Jobs. Die Ausführungspriorität liegt
im Bereich von 1 (höchste Priorität) bis 99 (niedrigste
Priorität). Jobs mit der höchsten Priorität erhalten den
besten Service von der CPU.

Dieser Wert bezeichnet die höchste zulässige
Ablaufpriorität für Threads innerhalb des Jobs. Für
einzelne Threads kann die Priorität auch niedriger sein.
Ende

[dbausnnd]

Erstmal Danke für die wiedermal schnelle Antwort

Verstehe ich das richtig das du die Auswführungspriorität der Klasse meinst?

Ist das der einzige Faktor den verändern kann um SBS unterschiedlich zu priorisieren?

Gruß

dbausnnd

[Fuerchau]

Definitiv Ja.
Wobei dieser Parameter nur als Relativwert zum Gesamtsystem gilt.
Brauchen andere Jobs keine Zeit laufen die niedriger priorisierten dann wieder schneller.

[BenderD]

... da gibt's schon noch mehr Schräubchen, Activity level, max. Jobs..., aber "rumschbiele an de Gnebbscher" sollte nur dürfen, wer Ahnung davon hat - siehe auch deine Erfahrungen mit der festen Poolgröße!!!

D*B

[dbausnnd]

... da gibt's schon noch mehr Schräubchen, Activity level, max. Jobs..., aber "rumschbiele an de Gnebbscher" sollte nur dürfen, wer Ahnung davon hat - siehe auch deine Erfahrungen mit der festen Poolgröße!!!

D*B

Ich denke meine Frage ist eindeutig gestellt. Dieser Post führt zu keiner Lösung und ist aus meiner Sicht daher unnötig.

Was wann, wie und von wem an unserem System ausgeführt wird letztlich auch von uns entschieden.

Bitte also nur Postings die auch weiterbringen.....

[BenderD]

... ich kann auch deutlicher werden: Finger weg von Sachen, von denen du keinerlei Ahnung hast!!!

[Christian Bartels]

Mit V6R1M0 und dem PTF SI41479 gibt es auch die Möglichkeit, die maximale Anzahl der verfügbaren CPUs zu begrenzen, die von einem Subsystem verwendet werden können. Dokumentiert ist das für IBM i 7.1, die Doku gilt aber auch für 6.1 mit dem PTF SI41479:

Managing workload capping

Mit freundlichen Grüßen,
Christian Bartels.

[holgerscherer]

Über Tips wäre ich sehr dankbar.

Das Subsystem zieht keine Ressourcen, sondern die Programme darin. Hier würde ich ansetzen. Ansonsten über die Klasse die CPU-Prioritäten runtersetzen. Das Reduzieren des Pools bringt - wie erwartet - nur höhere Paging-Aktivität, wenn die Jobs den Speicher brauchen, ist also kontraproduktiv.

Was noch gehen könnte - wenn arg CPU-Lastig - gelegentlich per ferngesteuertem DLYJOB die Zähne ziehen, aber das ist schon eine harte Methode.

Notfalls mal jemanden kommen lassen - hier kann man an den vielen Schrauben mehr ruinieren als verbessern.

-h