Laufzeitproblem - COMMIT aufteilen?
14 Beiträge
•
Seite 1 von 1
14 Beiträge
Seite 1 von 1
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Moin,
ich habe hier gerade einen Job, der eine Datei abarbeitet, sie (in einer kundeneigenen Transaktion) verbucht und am Schluss einen COMMIT macht. Die Laufzeit ist unter aller Kajüte.
Ich kann am Protokoll erkennen, dass die Buchungen immer "langsamer" werden (immer mehr Zeit brauchen), je mehr Sätze abgearbeitet wurden.
Mein Ansatz wäre, den COMMIT öfter zu machen, damit im Buffer nicht so viel aufläuft. Die Befürchtung ist, dass die Buchungen aufgrund des immer größer werdenden Buffers immer langsamer werden, mit häufigeren COMMITs sollte der nicht so voll laufen.
Ist der Gedanke grundsätzlich richtig oder bin ich auf dem falschen Dampfer?
Ralf
ich habe hier gerade einen Job, der eine Datei abarbeitet, sie (in einer kundeneigenen Transaktion) verbucht und am Schluss einen COMMIT macht. Die Laufzeit ist unter aller Kajüte.
Ich kann am Protokoll erkennen, dass die Buchungen immer "langsamer" werden (immer mehr Zeit brauchen), je mehr Sätze abgearbeitet wurden.
Mein Ansatz wäre, den COMMIT öfter zu machen, damit im Buffer nicht so viel aufläuft. Die Befürchtung ist, dass die Buchungen aufgrund des immer größer werdenden Buffers immer langsamer werden, mit häufigeren COMMITs sollte der nicht so voll laufen.
Ist der Gedanke grundsätzlich richtig oder bin ich auf dem falschen Dampfer?
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Hallo Ralf,
meiner Erwartung nach hast Du die richtige Fahrkarte gelöst.
Durch Commit sollte die Laufzeitverschlechterung pro Buchung wieder zurückgesetzt werden.
Aber warum testest Du das nicht einfach mal in Deinem konkreten Fall aus?
MfG
Thomas R.
meiner Erwartung nach hast Du die richtige Fahrkarte gelöst.
Durch Commit sollte die Laufzeitverschlechterung pro Buchung wieder zurückgesetzt werden.
Aber warum testest Du das nicht einfach mal in Deinem konkreten Fall aus?
MfG
Thomas R.
Beitrag
von Shortcut IT (ForumUser / 52 / 2 /
18
)
»
Hallo,
Ich würde das eher mal mit der ST12 tracen und dann sehen, wo die Laufzeit verbraucht wird.
Viele Grüße
Shortcut IT
ich kann mir vorstellen, dass hier das eigentliche Problem liegt. Erste Vermutung: interne Tabellen, die sich aufblähen und schlechte Zugriffe darauf (bzw. ungeeignete Definition der internen Tabelle(n), fehlende Secondary keys etc.). In dem Fall würde ein zwischendurch abgesetzter zusätzlicher COMMIT WORK keinen Performance-Gewinn bewirken.Ich kann am Protokoll erkennen, dass die Buchungen immer "langsamer" werden (immer mehr Zeit brauchen), je mehr Sätze abgearbeitet wurden.
Ich würde das eher mal mit der ST12 tracen und dann sehen, wo die Laufzeit verbraucht wird.
Viele Grüße
Shortcut IT
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Weil gestern in Berlin Feiertag war und ich eine entsprechende Testdatei beschaffen muss. So konnte ich die Zeit wenigstens nutzen, meine Vermutung zu diskutieren.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
Ich nehme nicht für mich in Anspruch, es zu wissen, aber dass ein voller Puffer die Laufzeit verschlechtert, kann ich mir kaum vorstellen. Ich mein, der muss doch irgendwann später sequentiell abgearbeitet werden, also werden da einfach bis zum Commit Datenbanktransaktionen immer hinten drangehängt. Da sollte die millionenste so schnell gehen wie die erste.
Klingt für mich nach einem Memory Leak, als ob Du vergessen hast irgendeine Puffertabelle vor jedem Durchlauf leerzuräumen und sich dadurch geschachtelte Loops hochpotenzieren. Ich denke, Shortcut IT's Ratschlag ist gut: Tracen, wo die Laufzeit entsteht.Ich kann am Protokoll erkennen, dass die Buchungen immer "langsamer" werden (immer mehr Zeit brauchen), je mehr Sätze abgearbeitet wurden.
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Also, um das mal klarzustellen: Das Programm ist NICHT von mir. ICH habe GAR NICHTS vergessen ;)
Ralf *dankt für die Hinweise
Ralf *dankt für die Hinweise
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Tja, da muss ich dich enttäuschen. Ich mache (statt eines COMMITs nach dem LOOP) jetzt einen COMMIT innerhalb des LOOPs. Vorher: Nach zwei Stunden hat der Anwender das Programm entnervt abgebrochen. Nachher: 12 Minuten Laufzeit. ;)DeathAndPain hat geschrieben: ↑10.03.2023 17:40Ich nehme nicht für mich in Anspruch, es zu wissen, aber dass ein voller Puffer die Laufzeit verschlechtert, kann ich mir kaum vorstellen.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
Mein Tipp: Verbucherbaustein(e).
Wenn es "nur" Datenbankoperationen wären, wäre ich auch der Meinung wie D&P, dass viele Operationen in einer LUW keine bzw. nur geringe Auswirkungen auf die Laufzeit haben dürften.
Wenn es "nur" Datenbankoperationen wären, wäre ich auch der Meinung wie D&P, dass viele Operationen in einer LUW keine bzw. nur geringe Auswirkungen auf die Laufzeit haben dürften.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Moin,
Ich habe bei diversen "Alteisen" unserer Entwicklungen ähnliche Erfahrungen gemacht wie Ralf.
Letztlich läuft bei vielen Langläufern oft auch das Memory voll und die UNDO Logs der DB ebenso. Oder das Anwendungslog wird im Speicher aufgebläht.
Es gibt also ein paar Stellen, die evtl. Einfluss nehmen.
Ich persönlich würde jetzt nicht in jedem Loop ein Commit absetzen, sondern mit einem COMMIT Counter arbeiten, hängt alles immer auch vom Mengengerüst ab.
VG
Frank
Ich habe bei diversen "Alteisen" unserer Entwicklungen ähnliche Erfahrungen gemacht wie Ralf.
Letztlich läuft bei vielen Langläufern oft auch das Memory voll und die UNDO Logs der DB ebenso. Oder das Anwendungslog wird im Speicher aufgebläht.
Es gibt also ein paar Stellen, die evtl. Einfluss nehmen.
Ich persönlich würde jetzt nicht in jedem Loop ein Commit absetzen, sondern mit einem COMMIT Counter arbeiten, hängt alles immer auch vom Mengengerüst ab.
VG
Frank
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Das "Alteisen" ist zwei Jahre alt - die Entwicklerin ist inzwischen in einer anderen Firma tätig ;)
Ralf
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Ob der Commit innerhalb oder ausserhalb des Loops ausgelöst wird, kommt doch auch auf die fachliche Anforderung an. Wenn ich die Möglichkeit brauche, dass bei einer fehlerhaften Buchung, alle anderen Buchungen auch nicht durchgeführt werden, dann muss ich Rollback/Commit nach dem Loop machen.
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Das ist grundsätzlich richtig, aber erstens in diesem Falle nicht nötig und wenn es keine andere Möglichkeit gibt, hat man ein Problem. Fakt ist: Das Programm war mit einem COMMIT nicht benutzbar. Und wenn es erst dadurch benutzbar wird, dass ich den COMMIT in den LOOP schreibe, dann muss ich das erstmal konstatieren.
Ralf
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
Die Frage ist, ob ein einfacher COMMIT WORK ausreicht oder ob es ein COMMIT WORK AND WAIT sein muss. Ich weiß nicht mehr genau, was es war, aber ich kann mich erinnern, zuweilen komische Effekte gehabt zu haben, wenn ich keinen WAIT gemacht habe, auch wenn die nachfolgenden Datenbankoperationen in keiner Weise mit den vorhergehenden zusammengehangen haben.
Mein subjektiver Eindruck war, dass das System sich irgendwie schwer tut, nach einem COMMIT WORK ohne WAIT weitere Operationen in die Warteschlange zu packen, während zeitgleich die vorhergehenden abgearbeitet wurden. Insofern habe ich mir angewöhnt, je nach Situation einen COMMIT WORK nur noch mit WAIT oder gar nicht zu machen. Ich hatte auch nicht das Gefühl, dass mir der WAIT jemals meine Laufzeit nennenswert verschlechtert hätte.
Mein subjektiver Eindruck war, dass das System sich irgendwie schwer tut, nach einem COMMIT WORK ohne WAIT weitere Operationen in die Warteschlange zu packen, während zeitgleich die vorhergehenden abgearbeitet wurden. Insofern habe ich mir angewöhnt, je nach Situation einen COMMIT WORK nur noch mit WAIT oder gar nicht zu machen. Ich hatte auch nicht das Gefühl, dass mir der WAIT jemals meine Laufzeit nennenswert verschlechtert hätte.
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Solcherlei Probleme konnte ich nicht feststellen.
Ralf
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Seite 1 von 1
Vergleichbare Themen
0
Antw.
Antw.
856
Views
Views
Laufzeitproblem FB IBAPI_ALM_ORDERHEAD_READ und IBAPI_ALM_OR
von thorstenwoehrle » 29.06.2006 11:54 • Verfasst in ABAP® Core
von thorstenwoehrle » 29.06.2006 11:54 • Verfasst in ABAP® Core
6
Antw.
Antw.
3735
Views
Views
Laufzeitproblem im Select (LIPS/VBUK/VBUP)
von ralf.wenzel » 18.04.2006 10:23 • Verfasst in ABAP® Core
von ralf.wenzel » 18.04.2006 10:23 • Verfasst in ABAP® Core
2
Antw.
Antw.
3126
Views
Views
3
Antw.
Antw.
380
Views
Views
2
Antw.
Antw.
8276
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.