**LIC-Task im Performance Explorer

**schatte** · 31-08-09, 17:13

Hallo Leute,

ich habe hier einen Kommuniktions-Batchjob, den ich gerne etwas optimieren würde. Der Job ließt Trigger aus einer DTAQ und schickt anschließend Datenbanksätze nach einer kleinen Umsetzung und Protokollierung über TCP/IP zu einem fernen System.

Ablauf ist also:
1. Trigger abwarten
2. Read auf eine Datenbanktabelle
3. Umsetzung des Records (nur Stringschieberei)
4. Protokollierung dieses Satzes in eine Datenbanktabelle
5. Senden per TCP inklusive Umsetzung nach Ascii
6. Antwort des Hostsystems

Wenn nun sehr viele Sätze zum Senden anstehen, dauern diese eigentlich simplen Tätigkeiten relativ lange.

Nun wollte ich mal mit dem Performance Explorer auswerten in welchen Programmen die Performance verloren geht. Allerdings kann ich diesmal im Ergebnis keine richtigen Einträge erkennen. Diesmal steht statt einzelnen Programmen nur **LIC-Task mit 99.6% CPU-Leistung ganz oben.
Sowas hatte ich bisher noch nie.

Weiß jemand wie ich ermitteln kann wodurch das *LIC-Task entsteht bzw. wie ich die Tätigkeiten von dem Job besser auswerten kann?

Über eine Antwort würde ich mich sehr freuen.

Code:

                                  +----------------- Inline Stats ------------++-------------- Cumulative Stats -----------+      
             Times   Calls MI CPLX              CPU        DB    DB   NDB   NDB              CPU        DB    DB   NDB   NDB  Call
Name        Called    Made  Issued          (us) /   %    SIO   AIO   SIO   AIO          (us) /   %    SIO   AIO   SIO   AIO Level
**LIC Task       0       0       0    146.816.094 99.6      0     0     0     0    146.816.094 99.6      0     0     0     0     0
Hautprogramm 14792   87450       0         70.650  0.0      0     0     0     0      1.303.095  0.9     12   644     0     0     0
Startprogramm    0       1       0              0  0.0      0     0     0     0        569.363  0.4      6   322     0     0     0
QCMD             0       1       0              0  0.0      0     0     0     0        569.363  0.4      6   322     0     0     0
QLNRFIDX     14191   17281       0         21.342  0.0      0     0     0     0        166.058  0.1      2     8     0     0     0
Lfdn. erm.    6180   12360       0          6.758  0.0      0     0     0     0        164.695  0.1      0     0     0     0     0
DTAQ-Lesen    1966    6882       0          5.893  0.0      0     0     0     0        137.463  0.1      0     0     0     0     0
QLNRFSEQ      3090    3090       0          4.365  0.0      0     0     0     0         95.038  0.1      4   314     0     0     0

Gruß
Matthias

**Fuerchau** · 31-08-09, 17:28

Wenn du TCP-IP selber verwendest, kann es beim Senden zur Verzögerung kommen.
Stichwort TCP_NONAGLE!
Das soll eine "Optimierung" sein, die man für direktes Senden abschalten sollte.

Defaultmäßig ist das nämlich ein, so dass tatsächlich erst gesendet wird, wenn man wieder auf Empfang geht.

**schatte** · 31-08-09, 17:35

Hallo,

danke schonmal für deine Antwort.
Aber macht das denn so viel aus? Im Code wird direkt nach dem Senden auf die Antwort gewartet, so dass da eigentlich nicht viel Zeit verloren gehen dürfte.
Steckt das TCP/IP Handling im LIC-Task mit drin oder gehört das nicht dazu?

Gruß
Matthias

**Fuerchau** · 31-08-09, 18:27

Deine LIC-Task kenne ich nicht.
Ich bin nur auf dieses Problem gestoßen in Verbindung mit einem SQL-Transfer zwischen der AS/400 und einer Oracle-Datenbank.
Hier wird ja eigentlich auch permanent gesendet und empfangen so dass es doch nicht zu diesen Verzögerungen kommen dürfte.
Es hat mich einige Mühe gekostet (Googel, Oracle-Seiten, Java) überhaupt den Zusammenhang zu erkennen.
"Versuch macht kluch" dachte ich und hab's einfach ausprobiert.

Vor abschalten des NONAGLE bekam ich ca. 10 Sätze pro Sekunden durch (2MBit-Standleitung), nach Abschalten waren es doch 200 !

Dies zeigte sich auch bei anderen SQl-Übertragungen, dass mit dem Abschalten ca. Faktor 20 erreichbar war.
Wenn die Leitung schneller wäre, wer weiß ...

**schatte** · 01-09-09, 07:58

Hallo,
ich habe gerade das C-Programm geprüft, dass die eigentliche TCP/IP Kommunikation durchführt. Hier ist leider schon ein setsockopt TCP_NODELAY drin. Diese Optimierungsmöglichkeit ist also leider schon erschöpft.

Weiß keiner, was dieser **LIC-Task alles macht? Den hatte ich bisher noch nie mit so einem hohen Wert an CPU-Zeit im Performance Explorer Log.

Gruß
Matthias

**Christian Bartels** · 01-09-09, 08:23

Hallo Matthias,

ich denke, daß **LIC-Task eine Zusammenfassung aller LIC Tasks im System ist. Im Grunde verbirgt sich dahinter eine Vielzahl von Tasks, die aber alle nicht in WRKACTJOB, sondern nur über STRSST oder WRKSYSACT sichtbar sind. Wenn diese LIC Tasks über 99% CPU verbrauchen, sollte man sie eigentlich mit WRKSYSACT erkennen können. Abhängig vom Task-Namen kann man dann sagen, was sie machen.

Mit freundlichen Grüßen,
Christian Bartels.

**BenderD** · 01-09-09, 09:15

... wenn du in der PEX Definition Task *all angibst, sollte der summarische Wert unter **LIC Tasks sich in der Auswertung aufgliedern lassen in die einzelnen dahinter stehenden Tasks - und dann sollte man da mehr ersehen können.

D*B

Zitat von schatte

Hallo Leute,

ich habe hier einen Kommuniktions-Batchjob, den ich gerne etwas optimieren würde. Der Job ließt Trigger aus einer DTAQ und schickt anschließend Datenbanksätze nach einer kleinen Umsetzung und Protokollierung über TCP/IP zu einem fernen System.

Ablauf ist also:
1. Trigger abwarten
2. Read auf eine Datenbanktabelle
3. Umsetzung des Records (nur Stringschieberei)
4. Protokollierung dieses Satzes in eine Datenbanktabelle
5. Senden per TCP inklusive Umsetzung nach Ascii
6. Antwort des Hostsystems

Wenn nun sehr viele Sätze zum Senden anstehen, dauern diese eigentlich simplen Tätigkeiten relativ lange.

Nun wollte ich mal mit dem Performance Explorer auswerten in welchen Programmen die Performance verloren geht. Allerdings kann ich diesmal im Ergebnis keine richtigen Einträge erkennen. Diesmal steht statt einzelnen Programmen nur **LIC-Task mit 99.6% CPU-Leistung ganz oben.
Sowas hatte ich bisher noch nie.

Weiß jemand wie ich ermitteln kann wodurch das *LIC-Task entsteht bzw. wie ich die Tätigkeiten von dem Job besser auswerten kann?

Über eine Antwort würde ich mich sehr freuen.

Code:

                                  +----------------- Inline Stats ------------++-------------- Cumulative Stats -----------+      
             Times   Calls MI CPLX              CPU        DB    DB   NDB   NDB              CPU        DB    DB   NDB   NDB  Call
Name        Called    Made  Issued          (us) /   %    SIO   AIO   SIO   AIO          (us) /   %    SIO   AIO   SIO   AIO Level
**LIC Task       0       0       0    146.816.094 99.6      0     0     0     0    146.816.094 99.6      0     0     0     0     0
Hautprogramm 14792   87450       0         70.650  0.0      0     0     0     0      1.303.095  0.9     12   644     0     0     0
Startprogramm    0       1       0              0  0.0      0     0     0     0        569.363  0.4      6   322     0     0     0
QCMD             0       1       0              0  0.0      0     0     0     0        569.363  0.4      6   322     0     0     0
QLNRFIDX     14191   17281       0         21.342  0.0      0     0     0     0        166.058  0.1      2     8     0     0     0
Lfdn. erm.    6180   12360       0          6.758  0.0      0     0     0     0        164.695  0.1      0     0     0     0     0
DTAQ-Lesen    1966    6882       0          5.893  0.0      0     0     0     0        137.463  0.1      0     0     0     0     0
QLNRFSEQ      3090    3090       0          4.365  0.0      0     0     0     0         95.038  0.1      4   314     0     0     0

Gruß
Matthias

**schatte** · 01-09-09, 12:52

Hallo,
danke für die Antworten.

Ich habe jetzt nochmal den PEX mit *ALL für die Tasks laufen lassen. Jetzt bekomme ich eine riesige Liste von verschiedenen Tasks ausgegeben, die fast alle < 0.05 % CPU liegen. Die beiden mit dem größten Satz sind:

Code:

Task ID          Job/Task Name                 Pool Priority Existence    Elapsed Time (us)             CPU (us)    CPU %  DB CPU
                                                             Start/End                                                           
00000000000005BB SMXCAGER01                       1      240   Y    Y           2757913037              8644512      2.03
0000000000000617 ASCHCMN23                        1       40   Y    Y           2757912072             76214455     17.89

Der SMXCAGER ist wohl für Pools mit *CALC in WRKSHRPOOL nötig, was der andere macht konnte ich nicht herausfinden.

Gruß
Matthias

**BenderD** · 01-09-09, 13:28

... wenn ich raten müsste, würde ich auf irgendwas mit asynchronous Communication tippen...

D*B

Zitat von schatte

Hallo,
danke für die Antworten.

Ich habe jetzt nochmal den PEX mit *ALL für die Tasks laufen lassen. Jetzt bekomme ich eine riesige Liste von verschiedenen Tasks ausgegeben, die fast alle < 0.05 % CPU liegen. Die beiden mit dem größten Satz sind:

Code:

Task ID          Job/Task Name                 Pool Priority Existence    Elapsed Time (us)             CPU (us)    CPU %  DB CPU
                                                             Start/End                                                           
00000000000005BB SMXCAGER01                       1      240   Y    Y           2757913037              8644512      2.03
0000000000000617 ASCHCMN23                        1       40   Y    Y           2757912072             76214455     17.89

Der SMXCAGER ist wohl für Pools mit *CALC in WRKSHRPOOL nötig, was der andere macht konnte ich nicht herausfinden.

Gruß
Matthias

**Fuerchau** · 01-09-09, 14:18

Vielleicht hat ja jemand die IP eurer AS/400 ausfindig gemacht und es läuft eine DOS-Attacke (Überlast).
Die AS/400 teilt sich aber die CPU immer noch so auf, dass der Anwender da kaum was von merkt.
Ein PC-Server hätte da wohl längst gestreikt.

**Christian Bartels** · 02-09-09, 09:24

Soweit ich in Erfahrung bringen konnte, heißen die LIC tasks für Asynchrone Communication eher ASCS-yyyyyyyyyy oder ASCL-xxxx (jeweils mit Bindestrich); über ASCH... habe ich nichts gefunden. SMXCAGER01 ist in der Tat der "Expert Cache Pool Ager" für Pool 1, hängt also mit *CALC zusammen.

Sind denn die beiden Tasks relevant, d.h. machen sie eine zweistelligen Prozentsatz an den 99,6% CPU aus, oder ist es die Menge der Tasks, die das Problem ausmacht? Wenn es die Menge ist, könnte man vielleicht versuchen, die Task-Namen nach den ersten 3 oder 4 Zeichen zu gruppieren, um herauszufinden, ob es eine bestimmte Komponente ist, die das Problem verursacht. Wenn ASCHCMN23 allein wirklich einen nennenswerten Prozentsatz ausmacht, könnte man vielleicht einen formatierten Task-Dump erzeugen (STRSST -> Service tools user ID/password -> 1. Start a service tool -> 4. Display/Alter/Dump -> 1. Display/Alter storage -> 4. Tasks/Processes -> 1. Task -> 1. Find by task name oder 5. Display list of tasks -> 1=Select task to work with -> Enter to continue -> 2. Base structure. Damit erhält man den internen Call-Stack der Task, jeder Eintrag beginnt mit "ISF ADDRESS". Wenn ich da die ersten paar Module-Namen bekommen könnte, könnte ich mal in den Sourcen nachschauen, was die machen.

Mit freundlichen Grüßen,
Christian Bartels.

**schatte** · 02-09-09, 09:52

Hallo,

ich habe mal die Tasks auf 10-Stellen gekürzt gruppiert und sortiert. Den RMTMSAFETA habe ich gestern übersehen. Der hat ja immerhin 32%!
Das der CFINT auf der Maschine läuft ist wahrscheinlich auch nicht so optimal.
Das sind aber nur die Tasks von einem Job und nicht alle auf dem System (LSTALLJOB *NO in der PEX-Definition)

Code:

RMTMSAFETA                                      32,37
CFINT01                                         30,86
ASCHCMN23                                       17,89
CFINT02                                         11,35
SMMIRRORMC                                       2,24
SMXCAGER01                                       2,03
IOCMETHLIN                                       0,86
WR15CLI                                          0,80
SMXCAGER02                                       0,45
JO-RECRA-D                                       0,19
SMIOSTCPGS                                       0,17
SMPOL001                                         0,14
JO-EVALUAT                                       0,10
SMIOSTCPGF                                       0,09
JO-RECRA-U                                       0,07
SMXCSPRVSR                                       0,02

WR15CLI ist übrigens das eigentliche Cobol-Programm.

Grüße
Matthias

Thema: **LIC-Task im Performance Explorer

Thread Tools

Bewerten Sie diesen Thema

Display