Programm wird langsam nach einiger Zeit
7 Beiträge
•
Seite 1 von 1
7 Beiträge
Seite 1 von 1
Hallo Kollegen,
wir haben in der Produktion eine Z-TC die mit der Zeit langsam wird. Startet man die neu, ist sie schnell wie gewünscht.
Der erste Verdacht ist natürlich, dass interne Tabellen voll laufen und somit Lesezugriffe sich auf die Performance auswirkt. Daher habe ich einen Logger geschrieben der immer mal wieder den aktuellen Speicherverbrauch loggt. Da ist keine Auffälligkeit zu erkennen.
Es wird jedoch viel mit Screens gearbeitet (Call Screen, Leave Screen, ...). Der Dynpro-Stack läuft aber auch nicht voll, sonst gäbe es ja eine Exception.
Hat jemand noch eine Idee woran es liegen könnte, dass die TCs langsam werden?
Ich freue mich über jegliches Feedback! :)
LG
wir haben in der Produktion eine Z-TC die mit der Zeit langsam wird. Startet man die neu, ist sie schnell wie gewünscht.
Der erste Verdacht ist natürlich, dass interne Tabellen voll laufen und somit Lesezugriffe sich auf die Performance auswirkt. Daher habe ich einen Logger geschrieben der immer mal wieder den aktuellen Speicherverbrauch loggt. Da ist keine Auffälligkeit zu erkennen.
Es wird jedoch viel mit Screens gearbeitet (Call Screen, Leave Screen, ...). Der Dynpro-Stack läuft aber auch nicht voll, sonst gäbe es ja eine Exception.
Hat jemand noch eine Idee woran es liegen könnte, dass die TCs langsam werden?
Ich freue mich über jegliches Feedback! :)
LG
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von black_adept (Top Expert / 4089 / 127 /
940
)
»
Wie und über welche Daten ermittelst du den aktuellen Speicherverbrauch?
Beitrag
von DeathAndPain (Top Expert / 1944 / 257 /
413
)
»
Ganz blöde Frage: Was ist "eine TC"? Ein Transaction Code? Ein Table Control? Was ist es, das da bei euch langsam wird?
Interne Tabellen kann man auch anders checken. Du könntest das Programm einfach mal debuggen, wenn es langsam geworden ist. Dann schaust Du Dir im Debugger an, wieviele Einträge eure internen Tabellen jeweils haben (einfach die am Anfang mit DATA definierten internen Tabellen durchgehen und schauen, ob da Ausreißer mit unrealistisch hoher Zeilenzahl dabei sind). Oder Du gehst mal eine Zeitlang mit F5 und F6 durch und schaust, ob Du Befehle oder Codeblöcke (Unterroutinen) finden kannst, bei denen der Zeitverlust auftritt. Möglicherweise ist die Zahl der Einträge ja auch im Rahmen (dessen, was programmtechnisch benötigt wird), aber die Programmierung ist schlampig old-fashioned, alles mit Standardtabellen und sequentieller Suche? Dann wäre die richtige Lösung relativ offensichtlich.
Bei "LEAVE SCREEN." aufpassen: Damit beendet man nicht einen CALL SCREEN! Wenn ihr also abwechselnd CALL SCREEN und LEAVE SCREEN macht, dann wird der entsprechende Stapel immer größer, logisch. Um nach einem CALL SCREEN wieder ordnungsgemäß hinter den CALL SCREEN zurückzukehren und den Stackeintrag wieder abzubauen, muss es
lauten.
Interne Tabellen kann man auch anders checken. Du könntest das Programm einfach mal debuggen, wenn es langsam geworden ist. Dann schaust Du Dir im Debugger an, wieviele Einträge eure internen Tabellen jeweils haben (einfach die am Anfang mit DATA definierten internen Tabellen durchgehen und schauen, ob da Ausreißer mit unrealistisch hoher Zeilenzahl dabei sind). Oder Du gehst mal eine Zeitlang mit F5 und F6 durch und schaust, ob Du Befehle oder Codeblöcke (Unterroutinen) finden kannst, bei denen der Zeitverlust auftritt. Möglicherweise ist die Zahl der Einträge ja auch im Rahmen (dessen, was programmtechnisch benötigt wird), aber die Programmierung ist schlampig old-fashioned, alles mit Standardtabellen und sequentieller Suche? Dann wäre die richtige Lösung relativ offensichtlich.
Bei "LEAVE SCREEN." aufpassen: Damit beendet man nicht einen CALL SCREEN! Wenn ihr also abwechselnd CALL SCREEN und LEAVE SCREEN macht, dann wird der entsprechende Stapel immer größer, logisch. Um nach einem CALL SCREEN wieder ordnungsgemäß hinter den CALL SCREEN zurückzukehren und den Stackeintrag wieder abzubauen, muss es
Code: Alles auswählen.
LEAVE TO SCREEN '0'.Hallo,
danke schonmal für die Antworten!
Eine TC ist in meinem Sprachgebrauch eine Transaktion. :)
Wie gesagt, in der Größe (Speicherbelegung) der Variablen gibt es keine großen Änderungen die so einen Performanceeinbruch rechtfertigen würde.
danke schonmal für die Antworten!
Eine TC ist in meinem Sprachgebrauch eine Transaktion. :)
Ich ermittle alle Globalen Variablen des Programms und lese den Speicherverbrauch mit cl_abap_memory_utilities=>get_memory_size_of_object aus.black_adept hat geschrieben: ↑19.05.2020 11:01Wie und über welche Daten ermittelst du den aktuellen Speicherverbrauch?
Wie gesagt, in der Größe (Speicherbelegung) der Variablen gibt es keine großen Änderungen die so einen Performanceeinbruch rechtfertigen würde.
Das ist leider nicht möglich, weil ich nicht an den Rechner drankomme und im Testsystem ein entsprechendes Beispiel zu konstruieren nicht möglich ist.DeathAndPain hat geschrieben: ↑19.05.2020 12:07Interne Tabellen kann man auch anders checken. Du könntest das Programm einfach mal debuggen, wenn es langsam geworden ist. Dann schaust Du Dir im Debugger an, wieviele Einträge eure internen Tabellen jeweils haben (einfach die am Anfang mit DATA definierten internen Tabellen durchgehen und schauen, ob da Ausreißer mit unrealistisch hoher Zeilenzahl dabei sind). Oder Du gehst mal eine Zeitlang mit F5 und F6 durch und schaust, ob Du Befehle oder Codeblöcke (Unterroutinen) finden kannst, bei denen der Zeitverlust auftritt. Möglicherweise ist die Zahl der Einträge ja auch im Rahmen (dessen, was programmtechnisch benötigt wird), aber die Programmierung ist schlampig old-fashioned, alles mit Standardtabellen und sequentieller Suche? Dann wäre die richtige Lösung relativ offensichtlich.
Danke nochmal für den Hinweis. Ist auch so implementiert, war nur von mir falsch ausgedrückt.DeathAndPain hat geschrieben: ↑19.05.2020 12:07Bei "LEAVE SCREEN." aufpassen: Damit beendet man nicht einen CALL SCREEN! Wenn ihr also abwechselnd CALL SCREEN und LEAVE SCREEN macht, dann wird der entsprechende Stapel immer größer, logisch. Um nach einem CALL SCREEN wieder ordnungsgemäß hinter den CALL SCREEN zurückzukehren und den Stackeintrag wieder abzubauen, muss es
lauten.Code: Alles auswählen.
LEAVE TO SCREEN '0'.
Beitrag
von DeathAndPain (Top Expert / 1944 / 257 /
413
)
»
Nachher ist es keine globale interne Tabelle, sondern eine, die in irgendeiner Unterroutine mit dem Befehl STATICS deklariert wurde... 😁Ich ermittle alle Globalen Variablen des Programms und lese den Speicherverbrauch mit cl_abap_memory_utilities=>get_memory_size_of_object aus.
Tja, das ist dann wohl ein Fall von "Wasch mich, aber mach mich nicht nass": Du sollst das Problem lösen, aber man will Dir dazu keine Debug-ohne-Replace-Rechte einräumen. Aus meiner Sicht muss da von Deiner Seite die Reaktion kommen, dass Du das Problem nicht beseitigen kannst, wenn man Dir nicht die Möglichkeit einräumt, es auf geeignete Weise zu analysieren.Das ist leider nicht möglich, weil ich nicht an den Rechner drankomme und im Testsystem ein entsprechendes Beispiel zu konstruieren nicht möglich ist.
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Noch ein paar Fragen:
Läuft die Transaktion im Hintergrund oder ist es eine Dialoganwendung?
Werden "nur" Dynpros verwendet oder auch GUI-Controls?
Werden Befehle wie SUBMIT oder CALL FUNCTION ... DESTINATION 'NONE' darin verwendet?
Läuft die Transaktion im Hintergrund oder ist es eine Dialoganwendung?
Werden "nur" Dynpros verwendet oder auch GUI-Controls?
Werden Befehle wie SUBMIT oder CALL FUNCTION ... DESTINATION 'NONE' darin verwendet?
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
Beitrag
von black_adept (Top Expert / 4089 / 127 /
940
)
»
Misst du auch CL_ABAP_MEMORY_UTILITIES=>GET_TOTAL_USED_SIZE?
Seite 1 von 1
Vergleichbare Themen
3
Antw.
Antw.
10589
Views
Views
Zeit/Datum je Werk in tatsächliche Zeit umrechnen!
von hsiebert » 27.08.2007 11:23 • Verfasst in ABAP® für Anfänger
von hsiebert » 27.08.2007 11:23 • Verfasst in ABAP® für Anfänger
1
Antw.
Antw.
1630
Views
Views
PDF-Druck über ADS-Bausteine sehr langsam
von MartinZapf » 07.12.2015 14:25 • Verfasst in ABAP® für Anfänger
von MartinZapf » 07.12.2015 14:25 • Verfasst in ABAP® für Anfänger
2
Antw.
Antw.
1581
Views
Views
Join über mehrere Tabellen sehr langsam
von deejey » 21.08.2019 03:36 • Verfasst in SAP - Allgemeines
von deejey » 21.08.2019 03:36 • Verfasst in SAP - Allgemeines
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.