View Full Version : Job Prio des Users ändern?
Guten Morgen,
und ich dachte, das ist bestimmt ganz einfach :D
Nun um das ganze etwas ausführlicher zu erklären:
Wir betreiben auf der i5 ein ERP System das da heist M3 und ist von der Firma Infor.
Innerhalb diesem System gibt es die Möglichkeit eigene Masken mit SQL-Abfragen zu generieren und den Usern zur Verfügung zu stellen. Da diese Abfragen zum Teil doch etwas mehr CPU benötigen und dadurch teilweise das System ausbremsen, war meine Idee, ich schraub die Prio runter, damit falls ein anderer "wichteiger" Job kommt dieser bevorzugt wird bzw. der normale Ablauf nicht darunter leidet.
Die SQL Statements wurden schon soweit durchläuchtet, das unserer Meinung und auch Beraterseitig keine weiter Performance rausgeholt werden kann.
Ich wollte nun eben für diesen einen User die Prio ändern, nicht für das ganze System oder andere User damit in mitleidenschaft ziehen.
... wenn denn das ERP komplett über QZDASOINIT zugreift, wäre Holgers Vorschlag der schlechteste, weil er allen schadet und nichts positives bewirkt und der von Robert der, der am wenigsten schadet, weil er nichts bezweckt.
Selektiv einzugrenzen gibt es nur die Möglichkeit über die Exit Schnittstellen von DB2, oder über Auftrennung der Serverjobs in verschiedene Subsysteme und dann kann man auf SubsystemEbene unterschiedliche eine class mit unterschiedlichen Prios zuordnen. Aber eigentlich gehört das an der Quelle geheilt: am Index Design!!!
D*B
Viele Softwarehäuser haben sich für den internen Gebrauch eine Überwachung gebastelt, die, wenn ein Job zu sehr die anderen Leute behindert, die Priorität dieses Jobs heruntersetzt.
Wenn 1. an den SQL-Statements wirklich nichts mehr zu optimieren ist, und 2. Indizes wirklich nichts mehr helfen, würde ich 3. daran denken, so was auch auf einem Produktivsystem einzusetzen, um nicht immer manuell eingreifen zu müssen.
Zu 1. und 2.: dies halte ich für ein Gerücht, alles lässt sich optimieren und sei es, die SQL's in Einzelschritte zu zerlegen.
Oft genug habe ich erlebt, dass Join-Beziehungen mittels temporärer Ergebnistabelle (create qtemp/mytemptable as select ...) um Faktoren schneller sind. Mitunter von Minuten zu Sekunden!
Man bedenke, dass eine CTE/derived Table/Scalarer Subselect keine temporären Zwischentabellen ergeben sondern je Quellsatz zur Ausführung kommen.
zu 3.: Klar, wenn man bei 1 und 2 nichts findet, landet man bei 3 was nicht wesentlich was bringt sondern nur Geld kostet.
Und was die ominöse Prio angeht, so betrifft dies die "Häufigkeitsverteilung" auf der sog. Zeitscheibe.
Bildlich gesprochen erhält jeder Job über die Prio entsprechende Anteile. Je mehr Job's im System, so geringer der %-Anteil. Zu verstehen ist das wie die Anzahl der Tortenstücke die durch die "Anzahl Jobs" * (100-Prio) berechnet werden und gleichmäßig verteilt sind.
Jeder Job bekommt so eine definierte Ausführungszeit.
Bei jedem I/O oder sonstigen Wartebefehlen wird die Zeitscheibe vorzeitig abgegeben, der Rest verfällt und genau davon lebt das System eigentlich.
Wenn ein rechenintensiver Job seinen Zeitanteil nun voll ausschöpft, leiden alle anderen Jobs, die ihren Anteil vorzeitig aufgeben, extrem darunter.
Wenn also bei z.B. 1000 Job's nur 1 einziger Job etwas weniger häufig dran kommt, seinen Anteil aber ausschöpft, ändert das am Gesamtverhalten des Systems nur unwesentliches.
Bei Systemen mit wenigen Jobs (ich meine hier < 100) kann es da schon Auswirkungen bringen.
Ggf. interessant ist eher "Zeitscheibe in Millisekunden", Dialog z.B. 2000, Batch 5000!
D.h., wenn ein intensiver Rechenjob eben ohne IO-Unterbrechung 5 Sekunden rechnet wird er danach zwangsunterbrochen.
... bei Performance geht es oft wüst durcheinander:
@"Optimierung" Statements: SQL ist an der Ergebnismenge orientiert! Wenn zwei Beschreibungen derselben Ergibnismenge unterschiedliche Laufzeiten haben, dann ist das eine Schwäche des Optimizers (das könnte nach dem nächsten PTF/RELEASE genau umge´kehrt sein - mit einer Ausnahme: mit optimize for n rows kann man den Optimizer beeinflussen.
@Einzelschritte: Wenn man aus einem SQL Statement mehrere mit Zwischentabellen machen kann (manchmal geht das), dann kann man dadurch Richtung Selektivität forcieren, sprich: Extrakte ziehen, die man verjoint (kostet aber oft CPU, da man Lesezugriffe gegen CPU tauscht).
@Zeitscheibe: beim ersten synchronen I/O (reinpagen von Platte) verliert man die CPU. I/O intensive Jobs erreichen also das Ende der Zeitscheibe fast nie - rumschrauben daran bringt hier eher nix.
@Prio: die Job Prio kommt immer dann zum Zuge, wenn ein verdrängter Job wieder CPU haben will. Das heißt: auch ein Job mit Prio 99 kann ein System voll auslasten.
@Speicherpools: Hier wird tatsächlich aufgeteilt, was allerdings bei den Einstellungen der meisten Systeme nicht wirklich zieht, die dynamische Steuerung macht die Reaktion auf Speicherfrass nur träger, verhindert diesen Effekt aber nicht.
Die meisten Probleme mit der Datenbank liegen im Index Design! Sprich fehlende Indexe. Bevor man hier nicht untersucht hat, ist jede andere Maßnahme nicht sehr sinnvoll.
D*B
Ja, 3. ist die letzte Möglichkeit, den Systembetrieb aufrechtzuerhalten, wenn ein User / Programm unerwartet ungewöhnlich viele Ressourcen benötigt. Das ist keine Optimierung; der Verursacher hat noch länger zu warten.
Ich hab' auch schon mal ein Produktivsystem gesehen, wo interaktive Benutzer Klassen mit, wenn ich mich recht erinnere, 120000 msec (2 Minuten) max. CPU-Zeit hatten.
Da gewöhnt man sich ganz schnell an, so ziemlich alles zu submitten, da sonst der Job beinhart endet.
Bei Dialogjobs können in 8 Stunden da schon mal 2 Minuten zusammenkommen:).
Und was die "Optimierung" angeht so musst ich schon feststellen, dass das Programm je nach Datenmenge mal günstig oder ungünstig lief.
Laut Debug-Diagnose wurde der Zugriffsplan immer neu erstellt und somit der Weg immer neu kalkuliert.
Die "Extrakt"-Ziehung (das habe ich wirklich von Dieter gelernt), bringt dort mitunter gewaltige Vorteile, ins besonders wenn Derived Tables / CTE's mit GroupBy-Konstrukten gebaut und verjoint werden.
Hier ist die temporäre Tabelle mit Index gewaltig im Vorteil.
... einen prestarted Job mit CPUTIME zu kastrieren macht überhaupt keinen Sinn - das ist sowieso nur ein Angst Anker gegen loopende Jobs.
@Extrakte: Das war in der leider nicht mehr aktiven Bigdata Installation ein wichtiges Instrument...
D*B
holgerscherer
13-02-15, 21:01
Innerhalb diesem System gibt es die Möglichkeit eigene Masken mit SQL-Abfragen zu generieren und den Usern zur Verfügung zu stellen. Da diese Abfragen zum Teil doch etwas mehr CPU benötigen und dadurch teilweise das System ausbremsen, war meine Idee, ich schraub die Prio runter, damit falls ein anderer "wichteiger" Job kommt dieser bevorzugt wird bzw. der normale Ablauf nicht darunter leidet.
Die SQL Statements wurden schon soweit durchläuchtet, das unserer Meinung und auch Beraterseitig keine weiter Performance rausgeholt werden kann.
Ich wollte nun eben für diesen einen User die Prio ändern, nicht für das ganze System oder andere User damit in mitleidenschaft ziehen.
Ganz Einfach ist meinst einfach ganz falsch ;-) Wenn ein SQL viel CPU benötigt, hat das Gründe, die im Design liegen (wie Dieter und Baldur korrekt schreiben). Und wenn jeder User selbst sein Design machen kann (sprich, SQL in bairisch reintippt), wird es lustig. Wenn alle meinen, es ist performancemässig nichts mehr raus zu holen, wird gern mit neuer Hardware gewunken, oder (wie von mir pauschalisiert) mit demokratischer Bestrafung per Priorität. Aber damit ist das Problem ja nicht gelöst.
Wenn Du nur für einen speziellen User die Prio ändern willst, dann halte Dich an die vorhandenen Vorschläge: CHGJOB wenn möglich. Alternativ ein Scriptle, das mittels WRKACTJOB prüft, was dieser User macht, und wenns ein QZDASOINIT ist mit CPU > 20%, dann eine zwangspause von 3-5 Sekunden (wirkt Wunder) und schlechterer Priorität.
Kann beispielsweise auf der PUB1.DE ausprobiert werden.
-h
Immer dann, wenn die User (auch bedienergeführt) in der Lage sind quasi eigene SQL's zu stricken, stöhnt man wieder über die Laufzeiten und Systemlasten.
Der User ist mit der Antwortzeit unzufrieden, alle anderen User mit der Systemlast.
Wenn der User mit der unglücklichen Abfrage und unzufriedenen Antwortzeit nun auch noch ausgebremst wird ist der Frust nicht zu vermeiden.
Gerne werden sog. "Call-Center"-Anwendungen freie Suchmasken angeboten.
Gerade hier kommt es aber auf intelligente Indizes und "starre" SQL's an die schnelle Antworten aus z.B. Millionen Adressen liefern können.
Schließlich gibt es ja genug Methoden und Hilfsmittel (Textindizes) um genau obiges Hauptproblem nicht auftreten zu lassen.
"Genug"- oder "Maximal"-Optimiert gibt es nicht, wenn es immer noch zu solchen CPU-Lasten kommt.
Bestell doch mal Dieter ein, ich garantiere dir, dass der noch was findet.