Speicheroptimierung bei großen Datenbanken

Issue #4 resolved
Atze Danjo created an issue

Liegt an Quick-Info-Panel, wenn dieses deaktiviert ist, gibt es keine Probleme.

Comments (11)

  1. Atze Danjo reporter

    Habt ihr noch Probleme bzgl. des Speicherverbrauchs? Habe seit längerem mal wieder die Datenbank mit ~47k Filmen geöffnet und was ich auch tue, der Speicherverbrauch bleibt bei 250 - 500 MB. QuickInfo-Panel ist aktiviert.

  2. tbengel

    Füge mal in einer Session 15 Filme hintereinander zu und schaue mal ob sich das Programm beim Speichern merklich verlangsamt (bis hin zum Stillstand) ...

  3. tbengel

    Ich teste es heute mal mit meine realen Daten ..., möglicherweise hast Du eine "Mörder-Maschine" am Start ;-)

  4. MxO2204

    Also, ich denke, das hängt vom verwendeten System ab. Mein Laptop ist mit einem Core i7 und 16 GB Speicher relativ performant. Aber auch bei mir wird das Speichern so ab dem 50. / 60. Film merklich langsamer, jeder weitere hinzugefügte Film verlangsamt das Einpflegen deutlich mehr. Der belegte Arbeitsspeicher geht dann lt. Task Manger von anfangs um die 140 MB hoch auf knapp über 1000 MB. Bei 1060 MB ist dann jedoch Schluss, ich nehme mal an, dass hier das Java Memory Management anfängt, Platz freizuschaufeln, und das benötigt dann die längere / lange Zeit bis der Film eingepflegt ist. Jetzt 2x getestet, einmal mit Sortierung aufsteigend angezeigt, einmal absteigend, gleiches Verhalten. Mein große Test DB hat ca. 7K Filme..

    Auch die Größe der DB ist wichtig. Wenn ich jetzt eine winzige DB zum Testen nehme, mit 20 Filmen am Anfang, dann kann ich vermutlich mehrere 100 Filme einpflegen. Denn dann ist der Speicherverbrauch anfangs bei ca. 100 MB und steigt nur ganz langsam an. Nach 100 hinzugefügten Filmen hab ich aufgehört, denn der Speicher war da immer noch bei ca. 120 MB..

    Wenn ich an meine aktive Support Zeit zurückdenke, gabs da immer wieder Probleme mit dem Java Heap Space, Und so Parameter wie -Xms128M -Xmx256M etc. mit denen man das einstellen konnte. Denke mal wir sind hier bei einer Grenze von 1 GB, wo die Probleme beginnen. Vielleicht könnt ihr mal in die Richtung schauen.

  5. tbengel

    Habe es gerade unter Real-Bedingungen (habe einiges nachzuholen) ausgetestet:

    Windows 7 Intel(R) Core(TM) i7-3770 CPU @ 3.40GhZ 16 GB Arbeitsspeicher

    Start Arbeitsspeicher der javaw.exe: 724 MB nach 8. Film deutlich langsamer beim speichern, hier die genauen Werte:

    nach 8. Film -> 1.194.252 nach 9. Film --> 1.212.856 nach 10. Film --> 1.216.088 nach 11. Film --> 1.220.488

    der 11. Film ging gar nicht mehr zu speichern bzw. der Film wird zwar gespeichert, aber das Bearbeiten-Fenster verschwindet nicht. CPU-Auslastung währenddessen für die javaw.exe 88%. Dann das Bearbeiten-Fenster geschlossen und das Quick-Info-Panel in den Einstellungen deaktiviert. Beim Versuch wieder neu hochzufahren, hat sich das Programm aufgehangen (Arbeitsspeicher war immer noch bei 1.220.488, als wenn dieser selbst nach dem Ende des Programm nicht freigegeben wurde. Dann über Task-Manager die javaw.exe gekillt und danach läuft alles wieder und alle 11 eingegebenen Filme sind vorhanden.

    Was mir aufgefallen ist, dass er während des Speichervorgangs mehrfach in den Quick-Info-Panel springt und diese dort aktualisiert, als wenn er dort mehrere Filme durchlaufen würde und diese versucht anzuzeigen und dies wird das Problem sein, den ohne Quick-Info-Panel gibt es keinerlei Probleme.

    Ich glaube, du musst für die Test-Datenbank noch Cover hinzufügen, da die reine Textmenge für Testzwecke nicht ausreichend ist.

  6. tbengel

    Selber Computer, die gleiche Session ...

    42 Filme hintereinander und keinerlei Speichern-Wartezeiten Arbeitsspeicher javaw.exe (nach 42 neuen Filmen): 817.676 Einziger Unterschied: QuickInfo-Panel ist deaktiviert.

    Das QuickInfo-Panel ist der Speicherfresser!!! Er gibt den belegten Speicher nicht wieder frei ... Wenn diese Ursache gefunden ist, ist auch das Speicherproblem gelöst.

  7. Atze Danjo reporter

    mh.. Ist schon komisch, dass ich vor 2 Monaten noch keine Probleme hatte das Problem nachzuvollziehen. Selbe Hardware, selbe Datenbank, anderes Ergbebnis...

    Debian 9 AMD QC-4000 @ 1.3 Ghz 8 GB RAM Heapsize 2GB

    Der Screenshot ist nach dem hinzufügen von 20 Filmen. Bei meinen letzten Tests vor ca. 2 Monaten habe ich es kaum geschafft 15 hinzuzufügen.

    visualvm.png

  8. tbengel

    ... aber das Quick-Info-Panel war bei dem neuen Test aktiviert, oder ;-)) ... ... vielleicht gibt es ja nun eine Einstellung bei Dir, die genau dafür verantwortlich ist, dass es nun klappt ... Schicke mir mal Deine config.txt, dann mache ich den Test nochmal mit Deinen Einstellungen ...

  9. Atze Danjo reporter

    Ich lass das mal hier, für Zukunfts-Ich

    Habe nochmal 2 Tests gemacht mit jeweils 50 Filmen, aber 30 Filmen kann ich die Problematik nachvollziehen. Habe mir denn mal den Heap Dump angesehen und dabei ist mir aufgefallen, dass die Anzahl der Instanzen von GUIaddMovie der Anzahl der seit dem Start hinzugefügten Filme entspricht. Da ich immer wieder den gleichen Film hinzugefügt habe, kam auch jedes mal die Frage, ob man Film trotzdem hinzufügen möchte, davon gibt es ebenfalls entsprechend viele Instanzen. Außerdem gibt es 210 Instanzen von GUIMovieDetails, die (nach Stichproben) alle auf das Quickinfo-Panel zurückzuführen sind.

  10. Log in to comment