JDownloader Community - Appwork GmbH
 

Reply
 
Thread Tools Display Modes
  #1  
Old 26.06.2022, 19:01
StefanM's Avatar
StefanM StefanM is offline
JD VIP
 
Join Date: Oct 2020
Posts: 310
Default Poblem: Arbeitsspeicher

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?
Reply With Quote
  #2  
Old 27.06.2022, 10:51
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 76,793
Default

@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
__________________
JD-Dev & Server-Admin
Reply With Quote
  #3  
Old 27.06.2022, 12:35
StefanM's Avatar
StefanM StefanM is offline
JD VIP
 
Join Date: Oct 2020
Posts: 310
Default

Quote:
Originally Posted by Jiaz View Post
@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.
Attached Thumbnails
About1.jpg   About2.jpg   TaskMgr2.jpg   About3.jpg   TaskMgr3.jpg  


Last edited by StefanM; 27.06.2022 at 12:42.
Reply With Quote
  #4  
Old 27.06.2022, 15:06
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 76,793
Default

Quote:
Originally Posted by StefanM View Post
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.
__________________
JD-Dev & Server-Admin
Reply With Quote
  #5  
Old 27.06.2022, 15:08
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 76,793
Default

Quote:
Originally Posted by StefanM View Post
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/
__________________
JD-Dev & Server-Admin
Reply With Quote
  #6  
Old 27.06.2022, 15:36
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 76,793
Default

@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!
__________________
JD-Dev & Server-Admin
Reply With Quote
  #7  
Old 27.06.2022, 17:35
StefanM's Avatar
StefanM StefanM is offline
JD VIP
 
Join Date: Oct 2020
Posts: 310
Default

Quote:
Originally Posted by Jiaz View Post
@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.


Quote:
Originally Posted by Jiaz View Post
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:
Quote:
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?

Last edited by StefanM; 27.06.2022 at 17:40.
Reply With Quote
  #8  
Old 27.06.2022, 17:50
StefanM's Avatar
StefanM StefanM is offline
JD VIP
 
Join Date: Oct 2020
Posts: 310
Default Free Memory...

@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
Attached Thumbnails
Free Memory.jpg  

Last edited by StefanM; 27.06.2022 at 17:52.
Reply With Quote
  #9  
Old 27.06.2022, 18:25
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 76,793
Default

Quote:
Originally Posted by StefanM View Post
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*.

Quote:
Originally Posted by StefanM View Post
Hiernach sieht es ja so aus, als muss ich nichts dazu anpassen
Korrekt, das Feature is Default aktiviert.

Quote:
Originally Posted by StefanM View Post
Aktuell: Reduzierung um 1,2 GB
Reduziert wo? Also woher nimmst du diese Info?

Quote:
Originally Posted by StefanM View Post
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.

Quote:
Originally Posted by StefanM View Post
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.
__________________
JD-Dev & Server-Admin

Last edited by Jiaz; 27.06.2022 at 18:31.
Reply With Quote
  #10  
Old 28.06.2022, 17:26
StefanM's Avatar
StefanM StefanM is offline
JD VIP
 
Join Date: Oct 2020
Posts: 310
Default

Quote:
Originally Posted by StefanM View Post
@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
Quote:
Originally Posted by Jiaz View Post
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?
Reply With Quote
  #11  
Old 28.06.2022, 17:35
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 76,793
Default

@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.
__________________
JD-Dev & Server-Admin
Reply With Quote
  #12  
Old 28.06.2022, 17:36
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 76,793
Default

Quote:
Originally Posted by StefanM View Post
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.
__________________
JD-Dev & Server-Admin
Reply With Quote
  #13  
Old 28.06.2022, 17:39
StefanM's Avatar
StefanM StefanM is offline
JD VIP
 
Join Date: Oct 2020
Posts: 310
Default

Quote:
Originally Posted by Jiaz View Post
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?
Reply With Quote
  #14  
Old 28.06.2022, 17:41
StefanM's Avatar
StefanM StefanM is offline
JD VIP
 
Join Date: Oct 2020
Posts: 310
Default

Quote:
Originally Posted by Jiaz View Post
Ja, aber die Bitness muss passen.
Das ist klar. Habe ohnehin immer beide (64 bit und 32 bit) installiert, weil das eine Programm will dies, das andere Programm will das...

Wobei inzwischen auch z.B. MediathekView sein eigenes Java mitbringt. Die sind nur später damit angefangen...
Reply With Quote
  #15  
Old 28.06.2022, 17:44
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 76,793
Default

Quote:
Originally Posted by StefanM View Post
@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.
__________________
JD-Dev & Server-Admin
Reply With Quote
  #16  
Old 28.06.2022, 17:53
StefanM's Avatar
StefanM StefanM is offline
JD VIP
 
Join Date: Oct 2020
Posts: 310
Default

Quote:
Originally Posted by Jiaz View Post
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.
Reply With Quote
  #17  
Old 28.06.2022, 17:58
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 76,793
Default

@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.
__________________
JD-Dev & Server-Admin
Reply With Quote
  #18  
Old 28.06.2022, 18:14
StefanM's Avatar
StefanM StefanM is offline
JD VIP
 
Join Date: Oct 2020
Posts: 310
Default

Quote:
Originally Posted by Jiaz View Post
Für *schon geladen* und co Zwecke empfiehlt sich ein Eventscripter Skript welches mittels Datenbank/Dateien auf der Platte die Prüfung macht.
Gibt es denn so ein Script schon?
Ich will bei mgpai nicht noch eine Baustelle aufmachen. Denn das Import-Script läuft bei mir ja noch gar nicht
Reply With Quote
  #19  
Old 28.06.2022, 18:18
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 76,793
Default

Quote:
Originally Posted by StefanM View Post
Gibt es denn so ein Script schon?
Ich will bei mgpai nicht noch eine Baustelle aufmachen. Denn das Import-Script läuft bei mir ja noch gar nicht
Ja, da gibt es was. Such mal mit dem Stichwort History. Das arbeitet über Hilfsdateien auf der Platte. Leider ist es unter Windows nicht so einfach eine *echte* Datenbank mit REST-API zu installieren/nutzen, sonst wäre da viel mehr schönes möglich.
__________________
JD-Dev & Server-Admin
Reply With Quote
  #20  
Old 28.06.2022, 18:21
StefanM's Avatar
StefanM StefanM is offline
JD VIP
 
Join Date: Oct 2020
Posts: 310
Default

Quote:
Originally Posted by Jiaz View Post
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.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

All times are GMT +2. The time now is 20:22.
Provided By AppWork GmbH | Privacy | Imprint
Parts of the Design are used from Kirsch designed by Andrew & Austin
Powered by vBulletin® Version 3.8.10 Beta 1
Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.