Offene Dateien

[Robi]

Hi,
ich habe hier ein SQLRPGLE Programm das nicht von uns ist.
Es ist ein Dienstprogramm und Wunder an Langsamkeit, daher habe ich mir mal die Source angesehen.

Es macht einige OVRDBF auf Ebene *job
und füllt mit div. dynamischen SQL's einige Dateien, um diese anschl. auszulesen und ein Ergebnis zu bringen.

Es wurde immer mit LR verlassen.
Ich habe nun das LR mal entfernt, und es ist deutlich schneller.
Aber ...
Je Aufruf sind die verwendeten Dateien neu geöffnet.

Wird dieses PGM vom Main Programm für 20 Datensätze aufgerufen, habe in 20 X die gleichen (4) Dateien geöffnet.

Wie kann ich das verhindern?

Ursprünglich lief es mit ACTGRP *caller, was *DFTACTGRP (OPM) war. Auch das versuchsweise setzen einer festen ACTGRP hat nix gebracht

Danke
Robi

[andreaspr@aon.at]

hi robi

was für einen wert verwendest du bei CLOSQLCSR?
*ENDACTGRP oder *ENDMOD?

lg andreas

[Robi]

hi, ich verwende
*endactgrp

[BenderD]

irgendwie verstehe ich weder die Beschreibung, noch das Problem:
@LR: wirkt nur bei OPM (und dann ist ACTGRP uninteressant)
entfernt man das SETON LR, wird Mehrfachaufruf meist messbar schneller, Funktion kann sich aber ändern, weil bei Dateien neu positioniert wird etc.
@ACTGRP: für ILE ist das Pendant zu dieser Technik (verlassen mit LR) benamte ACTGRP und RCLACTGRP
@CLOSSQLCSR: SQL macht immer lazy close, man muss also zwischen close aus Programm und close aus Datenbanksicht unterscheiden; CLOSSQLCSR wirkt nur auf die Programmsicht (und das ist auch gut so!!!), das einzige, was die Datenbank (noch!!!) zum faktischen close zwingt ist ein disconnect. (Stichwort: caching) warum sich dafür soviele Leute dafür interessieren, ist mir schleierhaft...
@Problem: was stört an den offenen Dateien???
schneller kriegt man das Teil möglicherweise dadurch, dass man die Zwischendateien weglässt und das ganze in ein Statement packt (Stichwort: CTE)

D*B

Hi,
ich habe hier ein SQLRPGLE Programm das nicht von uns ist.
Es ist ein Dienstprogramm und Wunder an Langsamkeit, daher habe ich mir mal die Source angesehen.

Es macht einige OVRDBF auf Ebene *job
und füllt mit div. dynamischen SQL's einige Dateien, um diese anschl. auszulesen und ein Ergebnis zu bringen.

Es wurde immer mit LR verlassen.
Ich habe nun das LR mal entfernt, und es ist deutlich schneller.
Aber ...
Je Aufruf sind die verwendeten Dateien neu geöffnet.

Wird dieses PGM vom Main Programm für 20 Datensätze aufgerufen, habe in 20 X die gleichen (4) Dateien geöffnet.

Wie kann ich das verhindern?

Ursprünglich lief es mit ACTGRP *caller, was *DFTACTGRP (OPM) war. Auch das versuchsweise setzen einer festen ACTGRP hat nix gebracht

Danke
Robi

[Robi]

Moin BenderD

Das LR nur bei OPM wirkt kann ich mir nicht vorstellen!?
Das rufende Programm ist OPM, das gerufene ILE.
Und in dem ILE Pgm hab ich den LR entfernt.
Die Funktionalität ist geblieben.

Was störtr an den offenen Dateien?
Es geht um eine Art Callcenter, das ca 50 - 60 'Kunden' / Stunde handelt. mit 80 - 110 Personen

Bei einem Power User währen also nach einer Stunde mehr als 50 mal die gleichen Dateien auf. Ich finde schon das das 'sub-Optimal' ist.


noch ne Idee ?
Robi

[BenderD]

... vorstellen oder nicht vorstellen, das ist immer so eine Sache - LR wirkt definitiv nur bei OPM Programmen, war denn der Recompile identisch mit dem ursprünglichen???
Optimal oder Suboptimal muss messbar sein, die mehrfach offen bleibenden Dateien sollten nromalerweise von der Datenbank adäquat gehandelt werden (sprich der Cache ist begrenzt, das wächst nicht beliebig). Optimierung könnte hier schon im Programm anfangen, da müsste man aber mehr sehen, was da wie gemacht wird (Stichwort: prepared Statement)

D*B

PS: (Änderung) sorry nachgelesen, LR wirkt bei Programm unabhängig von ILE/OPM

Moin BenderD

Das LR nur bei OPM wirkt kann ich mir nicht vorstellen!?
Das rufende Programm ist OPM, das gerufene ILE.
Und in dem ILE Pgm hab ich den LR entfernt.
Die Funktionalität ist geblieben.

Was störtr an den offenen Dateien?
Es geht um eine Art Callcenter, das ca 50 - 60 'Kunden' / Stunde handelt. mit 80 - 110 Personen

Bei einem Power User währen also nach einer Stunde mehr als 50 mal die gleichen Dateien auf. Ich finde schon das das 'sub-Optimal' ist.


noch ne Idee ?
Robi

[Robi]

@BenderD
Die Sourcen sind auf der Kiste, da es mal hier entwickelt wurde. Insofern glaub ich schon das ich die richtige Source habe.
Ein Kompile der unveränderten Basis kommt auch auf die selbe größe wie das 'Orginal'

Die Logik zu verändern ist nicht erlaubt. (Dann hätt ich das Prob. auch selber lösen können)

Ich befürchte (ohne es zu wissen) das die vielen offenen Dateien und der damit verbundenen Recourcen verbrauch bei 80 - 100 Usern die Kiste nachmittags quasi lahm legt.

@andreas
k.a. ob das Sinn macht
Die Dateien werden bei jedem Aufruf mit "DELETE from Datei" leer gemacht. (vor meiner Änderung : drop, crtdupobj UND delete)

Gruß
Robi

[Robi]

@Fuerchau

einfach gemacht ...
ja, so sehen die Innereien des Pgm's auch aus.
Trotzdem ist das, was es macht ziemlich komplex und das Ergebnis gut.
Die ACTGRP steht auf *caller, (das ILE Pgm läuft also in *DFTACTGRP = OPM)
Ein Versuch mit einer festen ACTGRP hat nicht geholfen.

Insofern ist die Vermutung mit dem OVR und dem 'selbstverständlichen' offen bleiben der Dateien leider falsch

Robi

[andreaspr@aon.at]

was du auf jeden fall benötigst ist beim aufzurufenden pgm
ACTGRP = *CALLER
und beim rufenden pgm ACTGRP = *NEW

eventuell musst du beim OVRDBF die beiden attribute auch setzen?:
SHARE *YES
OPNSCOPE *ACTGRPDFN

ab da bin ich dann mit meinem latein am ende.

lg andreas

[BenderD]

...falsche Source meinte ich nicht, andere Erstellungsparameter (ist ja bei SQL Programmen nicht ganz trivial).
Bezüglich LR habe ich schneller geschrieben als gedacht, Programme wirkt LR unabhängig von ILE, SRVPGMs nicht.
Problem beim dynamic SQL ist immer, wenn der komplette String erst zur Laufzeit zusammen gebastelt wird, erkennt die Datenbank oft nicht, ob derselbe Zugriffspfad schon da war und dann läuft der Cache von benutzten ODPs hoch. Ich habe allerdings noch in keinem Fall deinen befürchteten Ressourcenfrass beobachten können, allerdings schon häufig diesen Effekt.
Resumee: Versuch macht kluch

D*B

@BenderD
Die Sourcen sind auf der Kiste, da es mal hier entwickelt wurde. Insofern glaub ich schon das ich die richtige Source habe.
Ein Kompile der unveränderten Basis kommt auch auf die selbe größe wie das 'Orginal'

Die Logik zu verändern ist nicht erlaubt. (Dann hätt ich das Prob. auch selber lösen können)

Ich befürchte (ohne es zu wissen) das die vielen offenen Dateien und der damit verbundenen Recourcen verbrauch bei 80 - 100 Usern die Kiste nachmittags quasi lahm legt.

@andreas
k.a. ob das Sinn macht
Die Dateien werden bei jedem Aufruf mit "DELETE from Datei" leer gemacht. (vor meiner Änderung : drop, crtdupobj UND delete)

Gruß
Robi

[andreaspr@aon.at]

soviel ich weis wirkt sich das LR nur bei PEP(Programmeingangsprozedur)-pgms/modulen aus.
da ist es egal ob es ein OPM oder ILE ist.
anders gesagt: wenn du mit ein main-pgm, mit einem service-pgm (=ILE), welches viele module beinhaltet, dann wirkt sich das LR nur auf das main-pgm aus und nicht in den einzelnen modulen im service-pgm. in den sub-proceduren gibt es nur noch ein return.

@robi: da dein ILE-PGM ein PEP ist, wirkt sich dort auch das LR aus.

ich glaub, das problem liegt am dyn. sql. ist es für (dyn.) sql denn möglich (und sinnvoll) files vorher manuell zu öffnen und offen zu lassen?

[Fuerchau]

Da das ILE kein Serviceporpgramm ist (Aufruf aus OPM), wie ist dann die Einstellung der ACTGRP ?

Ich vermute mal, es steht auf *NEW, so dass mit jedem Call eine neue ACTGRP erstellt wird, durch LR=*OFF diese aber nicht geschlossen wird und somit die Dateien offen bleiben.
Irgendwann hat der Job dann allerdings keine Ressourcen mehr.

Da das Programm aber mit OVRDBF arbeitet besteht die Gefahr, dass ab dem 2. Aufruf nicht mit den richtigen Dateien gearbeitet wird, da diese ja nun nicht mehr geschlossen werden.
Dies gilt ggf. auch für offene ODP's der SQL-Statements.

Das Programm zu beschleunigen wird wohl nicht ganz so einfach werden.
Da hat es sich jemand ganz schön einfach gemacht.