JDownloader Community - Appwork GmbH
 

Reply
 
Thread Tools Display Modes
  #21  
Old 18.07.2017, 13:29
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 50,022
Default

Natürlich geht der Speicherverbrauch bei mehr erlaubten Speicher auch in die Höhe.
Du sagst mit dem Parameter ja, wieviel Speicher Java zum Arbeiten nutzen darf, was dann natürlich auch genutzt wird!
Java nutzt Garbage Collection und solange noch genug Heap frei ist (was ja durch dein oberes Limit eingestellt wird) so gibt es ja keinen Grund CPU Zeit fürs Aufräumen zu vergeuden.

Du kannst natürlich mit entsprechenden Java Paramtern viel an der Speicherverwaltung drehen, zb das freier Speicher wieder freigegeben wird, aber bedenke das all diese Sachen natürlich auch auf die CPU schlagen und damit auf die Performance.

Ist JDownloader abgestützt im Sinne von *sich beendet* oder hat es nur nicht mehr reagiert? Das sind große Unterschiede! Denn hohe CPU Last ist ein eindeutiges Zeichen das Java viel CPU für die Speicherverwaltung braucht, sprich du zuviel verlangst für zuwenig Speicher.
Sobald du nahe dem 2GB bewegst würde ich dir eher zu einer 64Bit JVM raten!

Ich kann auch gerne mal via Teamviewer *drauf* schauen, schick mir einfach ID und PW an support@jdownloader.org
__________________
JD-Dev & Server-Admin
Reply With Quote
  #22  
Old 19.07.2017, 03:43
baracus baracus is offline
Ultra Loader
 
Join Date: May 2012
Posts: 49
Default

vielen dank für das angebot,
das sich das speichermanagment so verhält war mir nicht klar, daher hab ich jetzt erstmal wieder die optionsdatei auf standart gestellt, sodass bei start es erstmal 150mb/260mb/1,3gb so aussieht.
will jetzt erstmal beobachten wie sich das im alltag verhält, und im vergleich setzt ich den speicher dann noch mal hoch

Quote:
Denn hohe CPU Last ist ein eindeutiges Zeichen das Java viel CPU für die Speicherverwaltung braucht, sprich du zuviel verlangst für zuwenig Speicher.
interessant, dh der cpu muss dann sozusagen den fragmentierten speicher hin und her rödeln bzw managen und JD zuweisen? ich dachte gerade dadurch das man den fest zugesagten oberwert schön grosszügig hoch ansetzt wird dieses problem genau entlastet, dh das eh ein grosser teil im RAM resierviert ist, und dann gibts ja auch noch die auslagerungsdatei bzw virtuellen speicher, der ist ja höher eingestellt als RAM ist, und vielleicht bin ich mit 6GB RAM auch gerade so an der grenze wenn man jd+browser intensiver nutzt, mal schauen ob ich da mal upgrade
übrigens war JD-speicher heute auch schonmal ÜBER 2gb angewachsen, also knapp 2,5gb

übrigens HATTE ich ja die 64bit java installiert, ich hatte ja mit einem schlag alles umgestellt auf 64bit (browser + JAVA + JD2) mit der hoffnung das wenn browser und oder JD stark beansprucht werden diese nicht schlapp machen +nicht mehr ansprechbar sind, passiert jetzt nicht so oft aber ab und an haut man browser oder JD so voll das man es übertreibt, und für solche fälle dachte ich....mit 64bit soll ja mehr RAM adressierbar sein daher.... mal schauen
Reply With Quote
  #23  
Old 19.07.2017, 09:52
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 50,022
Default

Mit 64Bit kannst du mehr Speicher nutzen, ja.
Java nutzt Garbage Collection, sprich man muss nicht selbst um die Speicherverwaltung kümmern. Man gibt der JVM eben bestimmte Parameter mit, unter anderem wieviel maximal Speicher genutzt werden darf. Und in diesem Raum mit entsprechenden Parametern arbeitet dann Java. Dazu gehört Speicher verwalten, aufräumen, defragmentieren usw.
Und einfache Downloads welche letztendlich nur aus einer URL bestehen, brauchen wenig Speicher.
Downloads, zb Yt, haben aber viel meta informationen wie namen, verfügbare Qualitäten, zusätzliche informationen für den Download usw...und brauchen entsprechend auch ein vielfaches mehr Speicher.

Somit hängt es primär von den Downloads ab ob man Millionen von Links mit wenig Speicher oder 10-100k Links mit viel Speicher verarbeiten kann
__________________
JD-Dev & Server-Admin
Reply With Quote
  #24  
Old 19.07.2017, 22:11
baracus baracus is offline
Ultra Loader
 
Join Date: May 2012
Posts: 49
Default

ja, mir ist ja eben auch aufgefallen das er bei video sachen wie youtube deutlich länger braucht als zb bei nem sharehoster uploaded link um zu sammeln.. würde es die sache speicher mässig denn erleichtern wenn man in den plugin youtube einstellungen einfach alles deaktivert bzw alle "ERLAUBTE MEDIEN TYPEN" halt bis auf video 480p zb wirklich alles deaktivert? speicher hinsichtlich gesprochen? dh jd müsste sich den gar nicht mehr durch die ganzen metadaten wühlen ? oder doch?


PS was ich gerade beobachtet habe wie wir schon vermutet hatten sobald der speicher an die maximal eingestellte grenze geht, geht die cpu belastung nach oben und JD reagiert fast nicht mehr , hängt also direkt mit dieser situation zusammen, RAM wäre zwar noch vorhanden aber der bereich der für JAVA vorgesehen ist ist komplett ausgenutzt, werd wohl ein bischen rumprobieren müssen

PSS wie ist denn das mit der youtube anzahl videos sache wird man das lösen können?

Last edited by baracus; 20.07.2017 at 08:49.
Reply With Quote
  #25  
Old 20.07.2017, 11:11
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 50,022
Default

Du kannst in den Einstellungen-Plugins-nach youtube und dort fast crawling
weiter beschleunigen kann man das nicht wirklich.
Du kannst noch den Thumbnail weglassen, in den Plugineinstellungen unten bei Best Images

Ja, das Problem mit den Playlisten ist in der aktuellen Version behoben
__________________
JD-Dev & Server-Admin
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 18:08.
Provided By AppWork GmbH | Privacy | Imprint
Parts of the Design are used from Kirsch designed by Andrew & Austin
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.