Memory Leak

Deutsches Forum
1

Hallo Community :slight_smile:

ich habe aktuell folgendes Problem.

Ich habe eine Liste mit 1300 Eltern Artikeln, welche durchlaufen wird, auf diverse Gegebenheiten geprüft wird und dann exportiert werden soll.

Der Datensatz sieht so auf, das zuerst eine Reihe mit den Inhalten des Eltern Artikels steht und danach die Varianten (AdminVarianten)

An sich kein Problem. Jedoch verbraucht das Script um eine 4MB Große Datei zu erstellen unglaubliche 1,5 GB Ram.

Ich habe mir den Verbrauch mal angesehen und Festgestellt, das die Artikel nicht aus dem Arbeitsspeicher entfernt werden, und so stacken.

Ich habe bereits die Variable auf Null gesetzt und auch via unset (obwohl das nur die Variable leert und nicht den Speicherplatz / Zeiger)

Hat jemand eine Idee, wie das Problem behoben werden kann?
Gibt es eine destruct ähnliche Funktion, die es aus dem Arbeitsspeicher entfernt?

Danke euch vielmals :slight_smile:

2

Unset gibt schon Speicher frei. Du solltest mal debuggen an welcher Stelle genau der Speicher verbraucht wird.

3

Ohne den genauen Code zu kennen, ist das alles müßig.

Nutze die Debug Möglichkeiten des Shops per “Profile”

4

[QUOTE=leofonic;175612]Unset gibt schon Speicher frei. Du solltest mal debuggen an welcher Stelle genau der Speicher verbraucht wird.[/QUOTE]

Wenn $oArticle->getAdminVariants() aufgerufen wird.

@Thomas, im Prinzip Oxid standart funktionen

oxList -> lade alle Artikel die kein oxparentid haben
foreach schleife
oxParentArticle->getAdminVariants()

Gibt es im Backend einen Oxid Profiler?

Danke euch für die Hilfe :slight_smile:

5

Glückwunsch. Du generierst dadurch ein oxList-Objekt mit 1300 kompletten oxArticle-Objekten, die wiederum jeweils ein oxarticlelist-Objekt mit x oxArticle-Objekten der Varianten enthalten. Wo genau gibst du jetzt wieder Speicher frei?
Der OXID-Profiler funktioniert out-of-the-box nicht im Adminbereich.

6

[QUOTE=martin.wegele;175626]Glückwunsch. Du generierst dadurch ein oxList-Objekt mit 1300 kompletten oxArticle-Objekten, die wiederum jeweils ein oxarticlelist-Objekt mit x oxArticle-Objekten der Varianten enthalten. Wo genau gibst du jetzt wieder Speicher frei?
Der OXID-Profiler funktioniert out-of-the-box nicht im Adminbereich.[/QUOTE]

Genau das ist mein Problem Martin.
Ich habe bereits unset getestet, variable auf NULL (was ja nur dann mehr auf die CPU geht …), das Object aus der oxlist entfernt nach nutzung usw.
Habe Garbage Collection angetestet usw.

Leider kein Erfolg. Daher die Frage hier im Forum :slight_smile:

PS: selbst wenn ich keine oxlist nutze und die oxids aus der DB mittels record set auslese und jedes oxarticle element einzeln nach einander erzeuge bekomme ich memory probleme

7

[QUOTE=mishoo;175628]
PS: selbst wenn ich keine oxlist nutze und die oxids aus der DB mittels record set auslese und jedes oxarticle element einzeln nach einander erzeuge bekomme ich memory probleme[/QUOTE]

Hmm, das ist komisch. Wieviele Varianten sind es denn pro Elternartikel?

8

Habe mir das angesehen weil memory für meine Module auch ein Thema ist, das Problem ist wahrscheinlich dass beim Laden der Varianten Daten des Vaterartikels kopiert werden, dazu wird das Parent geladen und in eine statische Variable geschrieben, in der stehen dann irgendwann alle Parents (getParentArticle). Das Kopieren kann man mit setLoadParentData deaktivieren wenn der Code im Backend läuft.

9

[QUOTE=leofonic;175640]Habe mir das angesehen weil memory für meine Module auch ein Thema ist, das Problem ist wahrscheinlich dass beim Laden der Varianten Daten des Vaterartikels kopiert werden, dazu wird das Parent geladen und in eine statische Variable geschrieben, in der stehen dann irgendwann alle Parents (getParentArticle). Das Kopieren kann man mit setLoadParentData deaktivieren wenn der Code im Backend läuft.[/QUOTE]

Das werde ich morgen gleich einmal testen. Danke für den Tip :slight_smile:

10

[QUOTE=leofonic;175640]Habe mir das angesehen weil memory für meine Module auch ein Thema ist, das Problem ist wahrscheinlich dass beim Laden der Varianten Daten des Vaterartikels kopiert werden, dazu wird das Parent geladen und in eine statische Variable geschrieben, in der stehen dann irgendwann alle Parents (getParentArticle). Das Kopieren kann man mit setLoadParentData deaktivieren wenn der Code im Backend läuft.[/QUOTE]

Das Problem bei setLoadParentData das ich es nicht setzen kann, wenn ich getFullVariants nutze.

Ich habe es jetzt so gelöst. Das ich mir alle Varianten ID’s mittels SQL für den entsprechenden Artikel laden lasse und daraufhin immer ein oxarticle Model generiere und es entferne.

Der RAM wird damit nicht gesprengt (zum Glück)

Danke allen für die Hilfe :slight_smile: