QSQSRVR

[Henrik Motzkus]

Hallo Form,

ich habe eine Frage bezüglich der PJ-Jobs QSQSRVR in Verbindung mit WAS 5.02.

Die CPU Auslastung dieser Jobs ist für vergleichsweise kleine Datenbankoperationen relativ hoch und dauert entsprechend lange.

Wir haben diverse perfomancesteigernde Einstellungen schon getroffen und nun ist meine Frage bringt es was diese PJ-Jobs in einen extra Mainstoragepool zu packen. Und ist es überhaupt möglich.

[TARASIK]

Hallo Henrik,
hast Du die Ptfs für diesen Serverjob installiert ? Es gibt
für das R520 einige Ptfs mit Performance und WAS.
Vorraussetzung ist das R520.

[BenderD]

Hallo Henrik,

relativ ist relativ, erster Schritt wäre für mich mit dem Database Monitor zu messen was wie lange dauert.

Diverse Performance steigernde Massnahmen zu treffen halte ich für schlecht, wenn es danach immer noch schlecht ist. Da muss jede einzelne Massnahme messtechnisch verifiziert werden und wenn es nix war, wieder zurück. Das Risiko, dass man alles verschraubt ist einfach zu gross.

Die Database Server Jobs kann man in einen eigenen Pool platzieren und das könnte Sinn machen, aber zuerst muss man wissen, was los ist, ich tippe da eher auf anderes als Pools und PTFs. Könnte es sein, dass ihr da eine Einprozessor Maschine mit wenigen grotten langsamen Platten habt???

mfg

Dieter Bender

[Henrik Motzkus]

@Bender : Über unser Testverfahren brauchen wir nicht zu reden.

Meine Frage ist nur einfach, ob es Sinn machen könnte. Wenn ich während des Jobs mit WRKSYSSTS mir das Paging für die Datenbank angucke erhalte ich manchal Werte im dreistelligen Bereich. Daher der Gedanke mit dem zusätzlichen Pool. Oder gibt es noch etwas anderes?

Die Partition ist mit zwei Prozessoren und 4 GB RAM ausgestattet. Der System ASP hat 326 GB (22 Platten)

Insgesamt habe ich 6 Prozessoren auf der i825 und 22 GB RAM zur Verfügung.

Das sollte genügen. :-)

@TARASIK:
Habe mir schon etliche APAR 's angeguckt und nichts gefunden. Grundsätzlich schrecke ich ersteinmal davor zurück WAS anzuheben, da wir uns damit beim letzen Mal viele Probleme eingehandelt haben.


Vielen Dank ersteinmal

Gruß

[TARASIK]

Hallo Henrik,
hier z.B einen APAR:

http://www-912.ibm.com/n_dir/nas4apa...SRVR,websphere

Und dieses Ptf wurde ersetzt durch SI09902

Zu dem Problem mit der performance habe ich noch einen
Beitrag gefunden:

Use CPU utilization guideline values to monitor high-priority (interactive) jobs

Jim Cook
18 Sep 2002, Rating 4.20 (out of 5)
Don't wait until your system slows to a crawl before dealing with performance issues. By monitoring CPU utilization for critical applications, you can get warnings in advance of major problems.
This tip provides updated cumulative CPU utilization guideline values for monitoring your "interactive-like," response-time critical applications. Use a guideline value to alert you to possible response time degradation in the "near future" or a possible cause for "longer than normal" response times. The guideline values increase as the number of processors available in the system or partition (LPAR configuration) increases.
Recall that guidelines are just that -- guidelines. There may be instances when response time is very acceptable at values higher than guideline values shown. Alternatively, there may be other instances when response time is not acceptable and the CPU utilization guidelines are not exceeded.
The table shown below is an updated set of guideline values for monitoring steady-state CPU utilization of "high priority jobs" running under OS/400 -- where a response time is an important consideration. These guidelines apply to jobs/threads that perform work based upon input data and receiving a response. This work includes jobs doing 5250 transactions, Web serving, Domino server functions, and SQL-oriented database file operations.
No. of processors Guideline values for
per system/partition "high priority jobs/threads"

1 70
2 76
4 81
8 85
12 87
18 90
24 91
32 93
You need to determine, for your application environment, at which OS/400 job run priority value(s) the jobs/threads run that you want to monitor. The guideline for a job/thread at any given priority value then includes the cumulative utilization of all jobs/threads active at equal to or higher priority compared to the priority of the selected job(s)/thread(s). You are then monitoring the cumulative CPU utilization of all jobs/threads running at equal to or higher priority to that value. For example, assume you want to monitor HTTP serving functions. Find out the run priority for the associated HTTP jobs/threads running under OS/400. Taking HTTP configuration defaults, this would be OS/400 job/thread RUNPTY 25. By using a RUNPTY value of 25 you include the other OS/400 functions that run jobs and threads at RUNPTY values 0 (iSeries microcode) through 25.
Under OS/400, key high priority functions/applications with default RUNPTY values less than 25 include the following:
5250 jobs. These jobs default priority value is 20.
QSQSRVR jobs that perform Call Level Interface DB2 UDB SQL functions used by IBM functions such as Management Central and typically by Java-based applications performing SQL. These jobs/threads default to running at priority value 10.
QZDASOINIT jobs performing ODBC/JDBC SQL functions requested by client workstations. These jobs/threads default to running at priority 20.
Domino for iSeries server jobs performing various Domino functions. These jobs default to running at priority 20.
QRWTSRVR DDM Target jobs performing DDM requests from a DDM source application. These jobs default to running at priority 20.
You can get an approximation of the cumulative CPU utilization according to job type run priority values from the Resource Utilization Expansion section of the System Report. That report is one of the functions available with the Manager feature of the Performance Tools for iSeries, 5722-PT1, licensed program. Performance data used by this report is collected using OS/400 Collection Services.
Starting with V5R1, iSeries Navigator (Operations Navigator) Management Central System monitor or Job monitor functions can assist you in real-time monitoring of CPU utilization values for the various jobs/servers you wish to monitor.
Note that that there is no specific real-time "high priority work" monitor function provided by OS/400 through V5R2. Here are some suggested techniques, all or some of which may be useful in your environment:
Use Management Central System Monitor metric CPU Utilization (Interactive Jobs). This monitors average CPU utilization for all active jobs performing 5250 I/O operations. The percent is relative to the total processor capacity (processor CPW) of the system/partition. This does not include work performed by high-priority jobs not performing 5250 I/O operations. For example, CPU utilization (Interactive Jobs) would not include CPU consumed by the QSQSRVR, QZDASOINIT, Domino, or HTTP-related jobs.
Use Management Central Job Monitor and select job types Interactive, Batch Immediate, and Prestart. Depending on your runtime environment, this may cover only the jobs you are interested in. For example QSQSRVR, QZDASOINIT, and QRWTSRVR are prestarted jobs. The jobs that do most of the Domino server and HTTP server work run as Batch Immediate ("BCI") jobs. Note, there may be CPU consumed by other batch immediate and prestarted jobs in your environment.
These "high priority CPU utilization" guideline values cannot be directly applied to Interactive Feature utilization. A complete discussion of a set of guideline values for the Interactive Feature utilization is beyond the scope of this tip.
However, here is some information that may assist you with setting up your own guideline values for the Interactive Feature utilization:
Each system/partition with a low interactive CPW capacity with a single 5250 job consuming high CPU utilization over an extended period is considered an administrative job and may use "more CPU" than you may expect with a low interactive CPW capacity.
Interactive Feature utilization applies when there are two or more 5250 jobs consuming high CPU utilization over an extended period of time. Interactive Feature utilization varies, based on the time interval of consistently high CPU utilization by jobs/threads performing 5250 input and output operations and the higher the interactive CPW capacity for the partition/system.
In general, the Interactive Feature utilization is computed by the microcode, and the algorithm can be characterized as slow to anger (high 5250 jobs CPU utilization over several minutes time span) and quick to forgive (lowered 5250 job/thread CPU utilization over a "short" time span). At this time, the general recommended guideline value for Interactive Feature utilization is a value of 70%. As with the high priority CPU utilization guideline, there may be times of acceptable response time when Interactive Feature utilization approaches 100%, and there may be times of degraded response time when less than 70% of the Interactive Feature is being utilized over an extended period of time.
As the percent of Interactive CPW rating approaches 50% or more of the partition's (or total system) Processor CPW rating, guideline values higher than 70% may be applied. Additional information requires further investigation.
This tip assumes V5R1 or later. If you are running V4R5, you can use Management Central System monitor support, but not Job monitor support (new in V5R1). V4R5 or later Management Central System monitor support includes monitoring Interactive Feature utilization. V4R5 or later OS/400 Collection Services collects Interactive Feature utilization. After associated performance database files (QAPMcccc) have been generated, the Manager feature of Performance Tools for iSeries, 5722-PT1 can produce System and Component reports that contain Interactive Feature utilization values.
Additional information:
Managing OS/400 with Operations Navigator V5R1 Volume 1: Overview and more, SG24-6226 provides overview information on Collection Services and detailed information on using a System or Job monitor. This Redpiece can be found at http://www.ibm.com/redbooks. Search for this document by number.
iSeries Information Center at http://www.ibm.com/eserver/iseries/infocenter. Select Systems Management -> Performance.

[BenderD]

Hallo Henrik,

@Bender : Über unser Testverfahren brauchen wir nicht zu reden.

wer wird denn gleich beleidigt sein?

Meine Antwort ist ganz einfach: ohne Kenntnis der Ursachen des Problems macht das keinen Sinn, das wäre der erste vor dem zweiten Schritt.

Was die Hardware Ausstattung angeht, ist die keineswegs üppig. Zwei Prozessoren für zwei dicke Serverdienste (WebSphere und Datenbank) ist die absolute Untergrenze!!! 4GB Hauptspeicher wären für WebSphere alleine nicht einmal zuviel!!!

Was sie Platten angeht, sehe ich meine Befürchtungen bestätigt, euer System ist unbalanciert. Hiezu der folgende link:

http://www-1.ibm.com/servers/eserver...mt/diskarm.htm

Ich empfehle sich mal die Platten Auslastungen monitoren zu lassen.


mfg

Dieter Bender

[Fuerchau]

Bei solchen Performance-Problemen auf der Datenbank würde ich mal VisualExplain versuchen. Dort sehe ich dann, welche Zugriffspfade, Indizees, Hashtabellen ggf. anzulegen sind.

Über den OpsNav (@Dieter, ja ich weiß) kann man auch statische Hashtabellen für einzelne Felder hinterlegen um auch nach dem nächsten IPL die Zugriffswege zu erhalten.

Ich muss immer wieder feststellen, dass beim Thema SQL-Zugriffe die Zugriffspfade (Indizees) stark vernachlässigt werden.
Bei Join's als auch Subselects werden häufig mehrere Millionen Zugriffe generiert, obwohl die Tabellen gerade mal ein paar Tausend Sätze aufweist.

Durch intelligente Verwendung des WITH-Selects konnte ich die Zugriffe aber so drastisch beschleunigen, dass e.g. eine Query-Liste, die vorher ca. 2 Stunden lief, nur noch 3 Minuten benötigt !!!

[BenderD]

Hallo,

@Baldur: hast Du das mit den statischen Hashtables mal ausprobiert und nachgemessen? funktioniert das, oder ist das (noch) Absichtserklärung?

Was den Ooops Nerv angeht, der Auswertungsteil des Database Monitors ist wirklich gut, wobei ich persönlich mit den Bildchen von Visual Explain auf Kriegsfuss stehe, wenn ich mir die anschaue, verstehe ich anschließend den Text der Debug Messages nicht mehr.

mfg

Dieter

[Fuerchau]

Was die DEBUG-Nachrichten angeht, so bin ich auch inzwischen soweit, dass ich diesen nicht mehr ganz traue.
Auch wenn ich die vorgeschlagenen Zugriffspfade angelegt habe, werden diese manchmal nicht verwendet !

Dafür sind meine Erfahrungen mit den WITH-Konstrukten sehr gut.
Manchmal werden diese temporären Ergebnisse als Join aufgelöst (insbesonders wenn Zugriffspfade verwendet werden können und auch werden), häufig aber tatsächlich eine temporäre Table (*QUERYnnnnn) erstellt.

Der Vorteil liegt meistens in dem Konstrukt
"where field [not] in (select ...)"

Hier ist das Problem, dass ich nur 1 Spalte im Ergebnis haben darf ich aber (Mandantenfähigkeit) eigentlich eine Kombination benötige. Bei einem WITH-Konstrukt war der Zugriff dann um Faktor 10.000 schneller !

Beispiel:

with
xTmp1 as (select f1, f2, f3, f4 concat f5 as fx
from table1 where ...)
,
xTmp2 as (select h4 concat h5 as hx
from table2 where ...)

select * 
from xTmp1 where fx in (select hx from xTmp2)

Es wurden tatsächlich 2 temporäre Tabellen erstellt (*QUERY0001, *QUERY0002) und die Auswertung lief superschnell.

[BenderD]

@Baldur

what the f.... is with construct? Gibt es zu meinem Erstaunen schon unter V5R1, wo ist das eigentlich dokumentiert? Ich kannte bis eben nur die implizite Variante (select ... from (select ... from ...) as hugo, bei der ich aber ausser besserer Lesbarkeit keine Vorteile beobachtet habe.

mfg

Dieter

[Fuerchau]

Das ganze heißt offiziell "Common-Table-Expression", siehe unter
http://publib.boulder.ibm.com/iserie...htm#HDRCOMTEXP

und zeitigt ganz erstaunlich Ergebnisse.

Möchte ich per ODBC (und bei JDBC findest du sicherlich ähnliche Anwendungen) dem Benutzer e.g. die Anzahl erwarteter Datensätze anzeigen (Fortschrittsanzeige ist da sehr schön) verwende ich folgende Methode (natürlich erst ab V5):

with
xTable as (fullselect)
,
xCount as (select count(*) as xRecs from xTable)

select * from xTable, xCount

Mit diesem Crossjoin bekomme ich zwar die Anzahl als letztes Feld immer übergeben, aber ich kann nun eine Fortschrittsanzeige darstellen und der Overhead ist geringfügig !

[Henrik Motzkus]

Vielen Dank für die Antworten. Wie man sieht kommen hier die Ansätze zur Perfomancesteigerung aus zwei unterschiedlichen Ecken. Einerseits eine optimal Ausschöpfung aller Möglickeiten in SQL (saubere Programmierung und durchdachtes Datenbankdesign) , was mir in meinem Fall nichts nützt, weil ich auf die Programme unserer Entwickler keinen Einfluss habe, und andererseits ein optimal konfiguriertes System. Auf letzteres habe ich Einfluss und kann schalten und walten. Trotzdem bin ich jetzt immer noch nicht schlauer, was meine Datenbankjobs angeht.

Kann ich die Performance steigern indem ich einen zusätzlichen SHRPOOL für diese Jobs anlege oder nicht? Würde das Paging nur aufhören, wenn noch mehr RAM zur Verfügung steht?

Und den WAS auch noch in einen extra Pool packen?

@Bender: Ich versuche die Ursache herauszufinden indem ich an solchen Schrauben drehe. Aber ich darf doch wohl vorher die Frage stellen ob es nun die richtige Schraube ist, ohne gleich eine Grundsatzdebatte über Sinn und Unsinn zu beginnen.
Vielleicht hat schon jemand damit Erfahrungen gemacht? Das reicht im Prinzip schon.

Vielen Dank

Gruß Henrik