[StefanM]

Da ich außer aus dem Jahr 2015 nichts dazu gefunden habe...

Mit zunehmender Programmlaufzeit belegt JD etliche GB RAM. Die Belegung steigt mit der Zeit immer weiter, so dass es z.B. bei einem PC mit nur 16 GB RAM irgendwann "kritisch" wird.

Abhilfe bringt ein JD-Neustart, so dass die RAM-Belegung wieder um einige GB geringer ist.

Frage:
Gibt es noch eine andere Möglichkeit - außer JD-Neustart - JD dazu zu bringen, Speicher freizugeben?

[Jiaz]

@Stefan;: Dein Screenshot von hier, https://board.jdownloader.org/showpo...postcount=3244 zeigt das JDownloader/Java maximal 2.65GB Speicher anfordern kann. Oder ist es hier ein anderes System? Bitte mal Screenshot des About Dialogs.
Hintergrund: Wenn Java zb ein Limit von 5 GB hat, aber der Prozess hier deutlich mehr zeigt, dann ist es ein Memleak außerhalb von Java/JDownloader, meist in Treiber/Firewall/AV.
Im About Dialog ist zu sehen wieviel Speicher maximal genutzt werden kann, das bitte prüfen.
Mittels Xmx Parameter kann der JVM das obere Limit gesetzt werden, siehe https://support.jdownloader.org/Know...vmoptions-file

Java gibt by default keinen Speicher mehr an das OS ab, da es ja ein oberes Limit hat bis zu dem es Speicher nutzen darf.
Mittels entsprechender Konfiguration/Parameter lässt sich die JVM so konfigurieren, das ungenutzter Speicher wieder ans OS *abgegeben* wird.
siehe zb
geekyhacker.com/2019/01/04/jvm-does-not-release-memory/
baeldung.com/gc-release-memory

[StefanM]

Originally Posted by Jiaz

@Stefan;: Dein Screenshot von hier, **External links are only visible to Support Staff**... zeigt das JDownloader/Java maximal 2.65GB Speicher anfordern kann. Oder ist es hier ein anderes System? Bitte mal Screenshot des About Dialogs.
Hintergrund: ...

Danke für die Infos!

Schon vor Jahren - als die PCs noch weniger RAM hatten - habe ich gelesen, dass JD als "Speicherfresser" verschrien war. Dabei hatte ich es so verstanden, dass JD selbst das Problem darstellte. Ob die Aussagen richtig waren, weiß ich nicht.

Anbei die gewünschten Screenshots nach nur 1 Std JD-Laufzeit ohne "Action". Werde jetzt aber mal über die Zeit dokumentieren.

Die Konfiguration, mit Hilfe derer man das "Abgeben" von Speicher erreichen kann, werde ich demnächst mal testen.

Frage 1:
Welche Java-Version würdest du denn empfehlen? Ich hatte bisher den Eindruck, dass die "alte" Version 1.8.0 noch die geringste "Belastung" darstellt. Es stehen ja bei JD insgesamt 4 Versionen (17, 11, 1.8) zur Verfügung + das auf dem System installierte, zwischen denen man auswählen kann.

Frage 2:
Adaptiert sich das Java im Ordner .\JDownloader2\jre an den installierten Arbeitsspeicher? Denn ich habe die Installationen (Erstellen des JD-Programm-Ordners) auf einem anderen System vorgenommen mit 12 GB RAM und auf einem System mit 16 GB RAM hat sich der Memory-Max-Wert wohl um genau diese 33,3 % erhöht. Dasselbe muss passiert sein, als ich in dem 12 GB-System vor Kurzem den Speicher gegen 16 GB ausgetauscht habe.

[Jiaz]

Originally Posted by StefanM

Frage 1:
Welche Java-Version würdest du denn empfehlen? Ich hatte bisher den Eindruck, dass die "alte" Version 1.8.0 noch die geringste "Belastung" darstellt.

Alle drei genannten Versionen sind LTS, werden also noch eine Zeit lang mit Updates versorgt. Eine wirkliche Präferenz kann ich da nicht wirklich aussprechen. Ich nutze Java 1.8 und Java 17. Java 1.8 ist halt die *älteste* Variante, aber Java11/17 haben mit CompactString (geeksforgeeks.org/compact-strings-in-java-9-with-examples/) Support halt einen Vorteil und brauchen hier pro String *quasi* nur die Hälfte des Speichers.

[Jiaz]

Originally Posted by StefanM

Frage 2:
Adaptiert sich das Java im Ordner .\JDownloader2\jre an den installierten Arbeitsspeicher?

Ja, sofern nicht durch eigene Xmx Parameter bestimmt, ermittelt Java den max Heap automatisch, siehe
stackoverflow.com/questions/4667483/how-is-the-default-max-java-heap-size-determined
blog.openj9.org/2020/04/30/default-java-maximum-heap-size-is-changed-for-java-8/

[Jiaz]

@StefanM: Also bei 16GB sehe ich jetzt maximal 3.5GB nicht als ein großes Problem an. Und laut Taskmanager hast du ja noch immer mehr als genug Speicher frei (28%). Sehe hier keinen wirklichen Handlungsbedarf?! Ansonsten würde ich dir zu Java 17 raten, da du bei vielen Links wirklich stark vom CompactString profitieren kannst!

[StefanM]

Originally Posted by Jiaz

@StefanM: Also bei 16GB sehe ich jetzt maximal 3.5GB nicht als ein großes Problem an. Und laut Taskmanager hast du ja noch immer mehr als genug Speicher frei (28%). Sehe hier keinen wirklichen Handlungsbedarf?!

Ich komme oft an die 96 oder 98 % Speicherauslastung, bei denen JD und Firefox den größten Anteil haben.

Originally Posted by Jiaz

Ansonsten würde ich dir zu Java 17 raten, da du bei vielen Links wirklich stark vom CompactString profitieren kannst!

OK, Java 17 werde ich dann noch mal testen.
Muss ich dazu auch noch was modifizieren? Habe bisher die von dir genannten Seiten erst nur quer gelesen.

Hiernach sieht es ja so aus, als muss ich nichts dazu anpassen:

Java 9 introduced the concept of compact Strings. The main purpose of the compact string is whenever we create a string object and the characters inside the object can be represented using 1 byte, which is nothing but LATIN-1 representation, then internally java will create one byte[]. In other cases, if any character requires more than 1 byte to represent it then each character is stored using 2 bytes i.e. UTF-16 representation.

Was mich auch irritiert:
Die Summe in der Spalte Memory im Task Manager scheint deutlich geringer zu sein, als das, was in % angezeigt wird. Dazu muss ich mal googlen.

Der angezeigt Wert im Task Manager ist aktuell 3,25 GB.
JD-About zeigt zeitgleich an: Usage 2,09 GB, Alloc. 2,87 GB, Max 3,53 GB
Widerspruch? Oder nachvollziehbar?

[StefanM]

@Jiaz:

Nachtrag:

Aber die Free Memory-Funktion von MemInfo (**External links are only visible to Support Staff**www.carthagosoft.net/MemInfo.php) bringt tatsächlich was.

Aktuell: Reduzierung um 1,2 GB

[Jiaz]

Originally Posted by StefanM

Der angezeigt Wert im Task Manager ist aktuell 3,25 GB.
JD-About zeigt zeitgleich an: Usage 2,09 GB, Alloc. 2,87 GB, Max 3,53 GB
Widerspruch? Oder nachvollziehbar?

Nein passt ja. Der About Dialog zeigt lediglich den Heap Speicherbereich an, welcher
grad circa 2,9GB von max 3,5GB hat. Natürlich braucht Java(das Programm selbst)
und die anderen Bereiche von Java (neben dem Heap gibt es noch weitere Speicherbereiche)
auch noch Speicher, es muss ja neben dem Daten auch irgendwo das Programm selbst liegen.
Anhand von VisualVM kannst du dich auf laufende Java Prozesse verbinden und so
mehr *sehen*, visualvm.github.io .Hier kannst du dann Heap/Metaspace oder
mittels HeapDump in den Speicher *blicken* und sehen was da wieviel Speicher *frisst* oder *belegt*.

Originally Posted by StefanM

Hiernach sieht es ja so aus, als muss ich nichts dazu anpassen

Korrekt, das Feature is Default aktiviert.

Originally Posted by StefanM

Aktuell: Reduzierung um 1,2 GB

Reduziert wo? Also woher nimmst du diese Info?

Originally Posted by StefanM

OK, Java 17 werde ich dann noch mal testen.
Muss ich dazu auch noch was modifizieren? Habe bisher die von dir genannten Seiten erst nur quer gelesen.

Nein, einfach entweder das gebündelte Java durch Java 17 tauschen oder Backup des cfg Ordners und JDownloader runter/neu installieren mit Java 17 Installer und dann cfg zurückspielen.

Originally Posted by StefanM

Ich komme oft an die 96 oder 98 % Speicherauslastung, bei denen JD und Firefox den größten Anteil haben.

Nunja, bei 16GB Speicher und max Heap von 3.5GB würde ich jetzt JDownloader irgendwie bei max 4-4.5GB sehen. Bei mir sind die Speicher*fresser* Number 1 Chrome/Firefox/Thunderbird.

[StefanM]

Originally Posted by StefanM

@Jiaz:
Aber die Free Memory-Funktion von MemInfo (**External links are only visible to Support Staff**...) bringt tatsächlich was.

Aktuell: Reduzierung um 1,2 GB

Originally Posted by Jiaz

Reduziert wo? Also woher nimmst du diese Info?

U.a. aus dem Task Manager.

Heute habe ich weitere Tests durchgeführt:
5.000 Links zum Crawlen einkopiert. Nach Klick auf Continue stieg der Wert im Task Manager schnell auf 4 GB,...
... ebenso der Max.-Wert im "About"-Fenster. Letzteres war mir neu, d.h. mir war neu, dass dieser Wert on the fly angepasst wird.

Durch den o.g. Free Memory-Befehl konnte ich den Wert auf 2,3 GB runterbekommen. Im Task Manager konnte ich aber zusehen, wie er stetig wieder stieg und nach ein paar Minuten wieder auf 4 GB war.

Während dessen war Link Collection weiter aktiv und beim Hochzählen der gefundenen Dateien.

Wenn du Screenshots brauchen solltest...
... habe ich gemacht - über den gesamten Verlauf.


PS: Ich habe gelesen, dass - wenn ich den jre-Ordner lösche/umbenenne - JD automatisch das im System installierte JAva verwendet. Könnte ich mal testen. Bringt das auch Vorteiele - oder eher Nachteile?

[Jiaz]

Originally Posted by StefanM

PS: Ich habe gelesen, dass - wenn ich den jre-Ordner lösche/umbenenne - JD automatisch das im System installierte JAva verwendet. Könnte ich mal testen. Bringt das auch Vorteiele - oder eher Nachteile?

Ja, aber die Bitness muss passen. Sprich der Launcher 64bit, dann sucht dieser auch nach einem 64bit Java auf dem System. Es gibt hier keine Vor oder Nachteile. Du kannst halt einfach die genutzte JVM damit auf die des Systems ändern. Oder du tauscht die Version im jre Ordner selbst aus.

[Jiaz]

@StefanM: Der Speicher der JVM kann bis zu bestimmten Werten/Grenzen wachsen/verbrauchen. Der Nutzung des Heaps, sowie die maximle Heap-Grenze wird hierbei im About Dialog angezeigt. Natürlich kommt es bei Aktivität (zb Crawlen) und Verschieben von Links zur Speichernutzung, vor allem bei 5000 Links. Je nach Linktyp braucht ein einzelner Link mehr Speicher als andere.

Das von dir beschriebene Verhalten ist völlig normal und auch so erwartet. Solange noch genug Speicher verfügbar ist, wird dieser auch genutzt. Erst sobald kein freier Speicher mehr da ist, muss die JVM den GC (Garbage Collector) nutzen um ungenutzten Speicher zu finden und freizugeben (nicht ans OS sondern an die JVM).

Du kannst hier entweder durch die Nutzung von Java 9 aufwärts, wie empfohlen Java 17, durch CompactStrings nochmals weniger Speicherverbrauch rausholen, oder von Hand mittels Xmx Parameter und vmptions Datei den maximalen Heap begrenzen.

[StefanM]

Originally Posted by Jiaz

Du kannst hier entweder durch die Nutzung von Java 9 aufwärts, wie empfohlen Java 17, durch CompactStrings nochmals weniger Speicherverbrauch rausholen, oder von Hand mittels Xmx Parameter und vmptions Datei den maximalen Heap begrenzen.

@Jiaz:
Die Begrenzung ist mit welchen Nachteilen verbunden?

[Jiaz]

Originally Posted by StefanM

@Jiaz:
Die Begrenzung ist mit welchen Nachteilen verbunden?

Je nach deiner Workload (vor allem Anzahl der Links) muss Java dann mehr CPU für die Speicherverwaltung aufwenden, weil ja weniger *Freiraum* vorhanden ist. Und wenn Java Out-of-Memory geht, zb mehr Links als in Speicher X passen, dann knallt es halt unkontrolliert an beliebigen Stellen. Da der Speicherverbrauch STARK vom Link selbst (also welcher Hoster) lässt sich hier keine pauschale Aussage tätigen ale X Links -> Y Speicher. Ich empfehle einfach den JDownloader frisch zu starten, dann DownloadListe und Linkgrabberliste laden zu lassen (sodass die Links sichtbar sind) und dann kannst im About Dialog sehen wieviel Speicher genutzt/alloziert/frei ist. Und daran dann deine Optimierungen entscheiden.

[StefanM]

Originally Posted by Jiaz

JIch empfehle einfach den JDownloader frisch zu starten, dann DownloadListe und Linkgrabberliste laden zu lassen (sodass die Links sichtbar sind) und dann kannst im About Dialog sehen wieviel Speicher genutzt/alloziert/frei ist. Und daran dann deine Optimierungen entscheiden.

Ja, das sind es i.d.R. unter 2 GB. Aber da du ja selbst schreibst, dass es "knallen" kann, ist das dann wohl nicht die Lösung.

Früher hatte ich nur 8 GB RAM, das oft fast vollständig genutzt wurde mit "moderater" Nutzung der Auslagerungsdatei.

Jetzt habe ich 16 GB RAM. Sieht toll aus, wenn noch nichts läuft, da ist die prozentuale Nutzung tatsächlich wie erwartet nur halb so hoch.

Aber sobald ein paar Programme laufen, sieht es genau so bescheiden aus, wie zuvor bei 8 GB RAM. Firefox und JD sind die "Hauptschuldigen".

Thunderbird belegt bei mir i.d.R. unter 500 MB.

Das alles ist auch nicht PC-abhg. Ist bei all meinen PCs so.

[StefanM]

Originally Posted by Jiaz

Du kannst hier entweder durch die Nutzung von Java 9 aufwärts, wie empfohlen Java 17, durch CompactStrings nochmals weniger Speicherverbrauch rausholen, ...

Habe gerade mal Java 11 reinkopiert aus einer anderen Testinstallation.

Jetzt braucht JD schon im Start 2,7 GB, also deutlich mehr als mit 1.8. Das hatte ich auch noch so in Erinnerung von früheren Tests, weshalb ich ja wieder auf 1.8 gegangen war.

Lasse JD jetzt mal damit laufen, testweise. Aber...
... glaube eher, dass das Speichermäßig schlechter sein wird.

[Jiaz]

Originally Posted by StefanM

Habe gerade mal Java 11 reinkopiert aus einer anderen Testinstallation.

Jetzt braucht JD schon im Start 2,7 GB, also deutlich mehr als mit 1.8. Das hatte ich auch noch so in Erinnerung von früheren Tests, weshalb ich ja wieder auf 1.8 gegangen war.

Du kannst nicht durch den Speicherverbrauch am Start auf den Speicherverbrauch schließen Du musst immer
den *wirklichen* Verbrauch sehen und nicht was grad an Speicher alloziert ist. Java kann auch 4 GB haben und dennoch 4GB *frei* sein. Mittels visualvm kannst du den Heap und dessen Größe/Belegung schön beobachten.
Nochmals, wenn Java bis x GB Speicher nutzen darf (max Heap) dann gibt es für Java keinen Grund das nicht aus zu tun.

Außerdem hat sich zwischen 1.8 und 11 und 17 auch viel am GC getan und die Defaults an den Parametern ändern sich natürlich auch. Daher kannst nicht einfach die Java Version tauschen und erwarten das gleiche/bessere Werte kommen.

[StefanM]

Originally Posted by Jiaz

Du kannst nicht durch den Speicherverbrauch am Start auf den Speicherverbrauch schließen Du musst immer
den *wirklichen* Verbrauch sehen und nicht was grad an Speicher alloziert ist.

Ist schon klar! Deshalb lasse ich ja jetzt auch noch einmal einen längeren Test laufen.
Dennoch ist der Start schon mal "schlechter". Denn das fehlt dem OS, egal ob Java das nur reserviert hat oder benötigt.

Wie auch immer, ich werde morgen mehr dazu berichten.

Nachtrag:
Aber wenn ich mich recht erinnere, bietet ihr bei der Web-Installation nur 1.8 an? Wenn das noch so ist, geht es um den Traffic? Weil deutlich kleiner?

[Jiaz]

Originally Posted by StefanM

Nachtrag:
Aber wenn ich mich recht erinnere, bietet ihr bei der Web-Installation nur 1.8 an? Wenn das noch so ist, geht es um den Traffic? Weil deutlich kleiner?

Nein, Traffic ist nicht der Grund, sondern 1.8 ist eben noch immer die *langlebigste* Stabile Version. Java 11 und Java 17 sind *relativ* *frisch* und da haben viele neue Features Einzug gehalten, welche auch alle irgendwo die Möglichkeit von Instabilitäten/Inkompatibilitäten bietet.

[Jiaz]

@StefanM: JDownloader nicht als *Archiv/History* nutzen und nur jene Links in der Liste haben welche man auch laden will, dann ist das mit dem Speicherverbrauch auch kein wirkliches Problem. Für *schon geladen* und co Zwecke empfiehlt sich ein Eventscripter Skript welches mittels Datenbank/Dateien auf der Platte die Prüfung macht. Versuch mal Java 17, damit müsste der Grundverbrauch schon deutlich kleiner sein.