ABAP-bezogenes Hauptspeicherproblem

Alles rund um die Sprache ABAP®: Funktionsbausteine, Listen, ALV
5 Beiträge • Seite 1 von 1
5 Beiträge Seite 1 von 1

ABAP-bezogenes Hauptspeicherproblem

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Hallo zusammen,

ich habe ein Programm, das viele Werte zeitraumsgenau einliest. In meinem Falle sind es Planstellen, aber da ich weiß, dass die meisten hier mit MM mehr anfangen können als mir HCM, sagen wir mal, es seien Materialien. Nehmen wir an, ein Material X habe 10 Attribute (Name, Werkszugehörigkeit, Verkaufspreis ...). Jedes einzelne davon kann sich im Laufe der Zeit ändern. Wenn ich also eine Liste machen möchte, die vom 01.01.2017 bis zum 31.12.2017 das Material mit all seinen Attributen darstellt, dann muss ich das Jahr in Teilzeiträume zerhacken. Jedes Mal, wenn (mindestens) eines der Attribute seinen Wert ändert, brauche ich eine neue Tabellenzeile.

So weit verständlich? Dann geht es weiter: Die Liste soll nicht nur ein Material umfassen, sondern viele Materialien. Bei jedem Material, dessen Attribute sich innerhalb des Jahres nicht verändert haben, reicht mir eine Zeile, deren Spalten halt die Attribute enthält. Bei allen anderen Materialien enthält die Liste mehrere Zeilen für dasselbe Material mit entsprechendem Beginn- und Endedatum.

Einfaches Beispiel:

Code: Alles auswählen.

Material       von           bis         Att 1   Att 2   Att 3
X            01.01.2017    30.06.2017     AA      BB      CC
X            01.07.2017    31.12.2017     FF      BB      CC
Y            01.01.2017    31.12.2017     DD      UU      KK
Jetzt will ich so eine Liste in einer internen Tabelle aufbauen. Jedes Attribut steht in einer anderen, beginn- und endedatumbehafteten Datenbanktabelle. Die Zeiträume der verschiedenen Attribute können sich natürlich beliebig überlappen. Es kann auch sein, dass ein Attribut für ein Material in einem bestimmten Teilzeitraum gar nicht definiert ist. All dies gilt es, zeitraumgerecht in der internen Tabelle abzumischen. Die Aufgabe hat natürlich eine gewisse Komplexität.

Ich habe das so gelöst, dass ich zuerst das erste Attribut für das gesamte Jahr (also ggf. mehrere Teilzeiträume) in eine interne Tabelle AUSGANGSTABELLE einlese. Dann mache ich einen LOOP über die AUSGANGSTABELLE, lese das zweite Attribut dazu (wobei ich die Zeiträume aus AUSGANGSTABELLE ggf. in zusätzliche Teilzeiträume zerhacken und zu diesem Zweck vervielfältigen muss) und lege das Ergebnis in einer Zieltabelle B ab.

Dann mache ich einen einfachen Befehl AUSGANGSTABELLE[] = B[]. REFRESH B. und mache wieder einen LOOP über die AUSGANGSTABELLE, lese das dritte Attribut dazu und lege wieder in B ab. Das Ganze wiederhole ich so oft, bis ich sämtliche Attribute eingelesen habe.

Ob es performant ist, nach jedem Attribut per AUSGANGSTABELLE[] = B[]. den gesamten Tabelleninhalt umzukopieren, möchte ich an dieser Stelle gern außen vor lassen. Ich habe diesen Weg gewählt, weil er mir am besten geeignet schien, die enorme Komplexität mit den vielen einander überlappenden Teilzeiträumen der einzelnen Attribute beherrschbar zu machen.

Das Ganze funktioniert auch. Bei großen Materialanzahlen laufe ich aber in das Problem, dass ich einen Dump der Form TSV_TNEW_PAGE_ALLOC_FAILED "Kein Speicher für Erweiterung einer internen Tabelle mehr verfügbar" bekomme. Dass die Tabelle selbst so groß geworden ist, dass sie nicht mehr in den Speicher passt, kann ich mir nicht vorstellen. Meine Befürchtung ist, dass ABAP beim Umkopieren des Tabelleninhalts (wobei ja immer der alte Inhalt von AUSGANGSTABELLE durch den neuen ersetzt wird), den vom alten Tabelleninhalt belegten Speicher nicht direkt freigibt, sondern zunächst noch belegt lässt. Da es in meinem Programm weit mehr als nur 10 Attribute gibt, die dieserart abgemischt werden, ist meine Befürchtung, dass auf diese Weise viele herrenlose Kopien des Tabelleninhalts im Speicher entstehen. Die würden vermutlich früher oder später vom Garbage Collector abgeholt werden. Doch vorher kommt es bereits zum Dump.

Wie kann ich das vermeiden? Sollte ich jedesmal zwischendurch einen FREE-Befehl absetzen? Das wäre performancemäßig noch schlimmer, und ich meine irgendwo gelesen zu haben, dass auch FREE nicht direkt freigibt, sondern die Sache nur dem Garbage Collector anheimstellt.

Vielleicht gäbe es ja auch eine bessere Variante als das Umkopieren? Sie muss nur halt programmiertechnisch beherrschbar sein, ohne dass die Komplexität (oder die Programmlaufzeit) aus dem Ruder läuft.

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: ABAP-bezogenes Hauptspeicherproblem

Beitrag von Daniel (Specialist / 314 / 68 / 44 ) »
Wie viele Zeilen hat denn deine Tabelle und wie lang ist Sie?

Re: ABAP-bezogenes Hauptspeicherproblem

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
Das einfachste wird sein, du liest und verarbeitest die Daten paketweise (SELECT ... PACKAGE-SIZE)
Dabei musst evtl. aufpassen, dass du keine "halben Blöcke" verarbeitest, also sicher stellt, dass du alle Zeiträume zu einem Material im Zugriff hast.

Re: ABAP-bezogenes Hauptspeicherproblem

Beitrag von black_adept (Top Expert / 3946 / 105 / 886 ) »
Hallo a-d-t,

zunächst würde ich erst mal nachschauen, ob deine Annahme überhaupt stimmt. Wenn SAP halbwegs schlau den Kernel implementiert hat versuchen die bestimmt selber den GC aufzurufen bevor neuer Speicherbereich alloziiert werden soll. Schlimmstenfalls kannst du ja selber nach jedem Umkopieren den GC anstoßen wenn du glaubst, dass dies das Problem sei ( Klasse CL_ABAP_MEMORY_UTILITIES ) . Aber ich fürchte, dass es sich einfach um ein Speicherleck in deinem Programm handelt und du eben doch nicht alles löscht.

Insgesamt hört sich deine Begründung mit dem "herrenlosen" Speicher aber schon arg hergeholt an. Selbst wenn durch das FREE abgeräumte Memory noch rumgeistert - durch das neue Befüllen werden die Speicherbereiche doch wieder von vorne an aufgefüllt/überschrieben, so dass du höchstens so viel Speicher da vergeudest wie die größte aller bisher verwendeten Tabellen.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: ABAP-bezogenes Hauptspeicherproblem

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Hallo black_adept,

ich bin zwar nicht a-d-t, aber davon abgesehen hat sich Deine Einschätzung als richtig erwiesen. Es war ein Speicherleck (= Codingbug) infolge einer Endlosschleife, die mir eine interne Tabelle grenzenlos vollgeknallt hat.

Aber manchmal hilft es halt, seine Gedanken neu zu ordnen, wenn man ein Problem strukturiert runterschreibt. Insofern vielen Dank für eure Aufmerksamkeit!

Seite 1 von 1

Vergleichbare Themen

5
Antw.
10029
Views
Kundeneigene ABAP-Muster Vorlage im ABAP-Editor anlegen
von Stentor » 19.07.2005 11:10 • Verfasst in Basis
6
Antw.
4620
Views
ABAP Workbench und ABAP Dictionary - für Einsteiger
von schnonus » 03.04.2008 10:39 • Verfasst in ABAP® für Anfänger
3
Antw.
15663
Views
ABAP 7.02 - Neues Feature - Pragmas in ABAP
von foessleitnerj » 09.01.2013 17:02 • Verfasst in Tips + Tricks & FAQs
3
Antw.
3446
Views
OLE und ABAP: Aufruf von Excel-VBA Prozeduren aus ABAP
von OnkelSAP » 26.05.2010 09:45 • Verfasst in ABAP Objects®
2
Antw.
3037
Views
ABAP Objects oder ABAP Referenz
von Gast » 23.06.2005 15:52 • Verfasst in ABAP® für Anfänger

Über diesen Beitrag


Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch

Aktuelle Forenbeiträge

SELECT CHAR16 in CHAR12-Feld
vor 2 Stunden von Patrick1982 gelöst 5 / 61
alv_grid aktualisieren
vor 7 Stunden von Egzon gelöst 4 / 83

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Aktuelle Forenbeiträge

SELECT CHAR16 in CHAR12-Feld
vor 2 Stunden von Patrick1982 gelöst 5 / 61
alv_grid aktualisieren
vor 7 Stunden von Egzon gelöst 4 / 83

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 4 Wochen von Lucyalison 1 / 134
Group Items auf einer Filterbar
vor 5 Wochen von Bright4.5 1 / 170