JDownloader Community - Appwork GmbH
 

Reply
 
Thread Tools Display Modes
  #21  
Old 15.01.2011, 16:14
mi2g
Guest
 
Posts: n/a
Default

Im Anhang ein Screenshot von meinem Aktivtätprogramm.

Kann doch nicht sein, dass soviel inaktiver Speicher vorhanden ist und der freie Speicher so wenig ist?

Kann ich den inaktiven Speicher irgendwie mit einem Terminal Befehl wieder freigeben?
Reply With Quote
  #22  
Old 25.01.2011, 07:21
mi2g
Guest
 
Posts: n/a
Default

Hallo zusammen

Gibt es schon News diesbezüglich.

Dies ist ja sicher ein Problem mit hoher Priorität. oder?

Gruss mi2g
Reply With Quote
  #23  
Old 25.01.2011, 09:59
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 63,396
Default

Da es sich hierbei um ein Problem mit der Mac Java version handelt können wir diesbezüglich wenig tun. Ohne einen Mac-Entwickler können wir die Ursache hierfür auch nicht auswendigmachen und sind auf die Mithilfe der User angefordert.
Bitte testet auch mal die Nightly-Edition von JD (bitte nur Java 1.6 Leute).

Ursachen für diese Problem: Firewall/Av/Apple-Java-Update (Evtl ältere version versuchen, wenn das geht)
__________________
JD-Dev & Server-Admin
Reply With Quote
  #24  
Old 26.01.2011, 00:06
`Black
Guest
 
Posts: n/a
Default

jDownloader im 32-Bit Modus laufen lassen behebt das Problem. Das ich das nicht gleich mal probiert habe...
Reply With Quote
  #25  
Old 26.01.2011, 08:47
mi2g
Guest
 
Posts: n/a
Default

Quote:
Originally Posted by `Black View Post
jDownloader im 32-Bit Modus laufen lassen behebt das Problem. Das ich das nicht gleich mal probiert habe...
Ja wirkich?
wenn ja wie lasse ich JD im 32-Bit Modus laufen?
Reply With Quote
  #26  
Old 26.01.2011, 14:55
`Black
Guest
 
Posts: n/a
Default

Apfel+I auf jDownloader.app und dann bei "Im 32-Bit Modus öffnen" einen Haken setzen.
Reply With Quote
  #27  
Old 26.01.2011, 14:59
mi2g
Guest
 
Posts: n/a
Default

Danke schön.

Und das hat keine Nachteile?
Reply With Quote
  #28  
Old 26.01.2011, 15:38
`Black
Guest
 
Posts: n/a
Default

Hat keine Nachteile.
Reply With Quote
  #29  
Old 26.01.2011, 22:53
mi2g
Guest
 
Posts: n/a
Default

Also ich führe JD jetzt im 32bit Modus aus. Jedoch habe ich immer noch den gleichen Fehler.
Reply With Quote
  #30  
Old 27.01.2011, 10:14
cobrito
Guest
 
Posts: n/a
Default

Hab das jetzt auch im 32bit Modus getestet. Ergebnis: jDownloader frisst noch immer fleissig RAM und verursacht paging, wenn kein freier RAM mehr vorhanden ist. ABER diesmal wird der RAM periodisch wieder freigegeben. Die RAM-Verbrauchskurve hat während des Downloads somit eine Sägezahn-Form. Also fressen, freigeben, fressen, freigeben, etc.
Reply With Quote
  #31  
Old 28.01.2011, 09:53
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 63,396
Default

bitte probiert auch mal unterschiedliche themes/styles
und mit aktiviertem/deaktiviertem log/reconnect
__________________
JD-Dev & Server-Admin
Reply With Quote
  #32  
Old 29.01.2011, 18:29
`Black
Guest
 
Posts: n/a
Default

Also das mit dem 32-Bit hat bei mir komischerweise nur einmal funktioniert, jetzt habe ich den Fehler wieder... Log deaktivieren / aktivieren hilft auch nicht, automatischen Reconnect verwende ich nicht, an den Themes liegt es auch nicht.
Habe aber noch festgestellt, dass nicht bei einem neuen Part der Ram gefressen wird, sondern genau dann, wenn ein Part fertiggestellt ist, wird exakt die Größe des Parts in den inaktiven Ram geschrieben.
Reply With Quote
  #33  
Old 04.02.2011, 10:45
cobrito
Guest
 
Posts: n/a
Default

Die sägezahnartige RAM-Freigabe im 32bit Modus war auch bei mir nur eine einmalige Angelegenheit. Das Problem bleibt also nach wie vor bestehen.

Quote:
Habe aber noch festgestellt, dass nicht bei einem neuen Part der Ram gefressen wird, sondern genau dann, wenn ein Part fertiggestellt ist, wird exakt die Größe des Parts in den inaktiven Ram geschrieben.
DAS finde ich eine sehr interessante Aussage. Ich lehne mich jetzt einmal weit aus dem Fenster und behaupte, das Problem liegt an einem Programmierfehler. Wenn bei der Fertigstellung eines Parts RAM in genau dessen Größe freigegeben wird (Mac-typisch in den inaktiven Speicher; dazu komme ich noch), heißt das, dass der ganze Part zuvor im RAM gepuffert war.

Ich hab jetzt nicht in den Sourcecode geschaut, nehme aber an, dass die Abarbeitung eines Parts so läuft:

1) Eine Datenstruktur (Byte-Array?) in der Größe des Part wird angelegt (also dafür RAM alloziert).
2) Beim Downloaden wird diese Datenstruktur sukzessive befüllt.
3) Gleichzeitig wird der Inhalt der Datenstruktur auf die Platte geschrieben (logischerweise von vorne beginnend).
4) Ist alles heruntergeladen und auch alles auf die Platte geschrieben, wird die Datenstruktur (und damit der RAM) freigegeben.

Die Bemerkung von `Black spricht dafür, dass es etwa so funktioniert. Jedenfalls wäre das Ressourcen-Verschwendung, da ein Buffer in Größe des ganzen Parts viel zu groß ist. Es reicht ein wesentlich kleinerer Buffer, der zyklisch mit dem zu downloadenden Material befüllt bzw. beim Schreiben auf die Festplatte entleert wird. Ist zwar programmiertechnisch schwieriger zu handeln, allerdings wird nur so jDownloader nicht zu einem RAM-fressenden Ungetüm.

Warum der RAM nicht jeweils gleich freigegeben, sondern in den inaktiven Bereich gelegt wird, erklärt sich mir dadurch, dass Mac OS der Ansicht ist, dass freigegebener RAM eines Programms, das noch läuft, wahrscheinlich wieder gebraucht werden kann. Daher nicht die komplette Entsorgung, sondern nur die "partielle" Freigabe. Da Windows das RAM-Management wohl anders handhabt, gibts dort dieses Problem nicht.

Ich hoffe, ich habe mich verständlich genug ausgedrückt. Und natürlich will ich niemanden persönlich kritisieren und bin dankbar, dass ein Projekt wie jDownloader in freiwilliger Arbeit gratis für die Anwender erstellt wird.
Reply With Quote
  #34  
Old 09.02.2011, 09:33
cobrito
Guest
 
Posts: n/a
Default

Ach ja, als workaround kann man den inaktiven Speicher auch selbst freigeben. Wie steht **External links are only visible to Support Staff**hier. Somit spart man sich den Neustart, wenn das System lahmt. Ich habs allerdings noch nicht probiert, während jDownloader läuft. Sollte aber kein Problem geben.
Reply With Quote
  #35  
Old 09.02.2011, 09:36
cobrito
Guest
 
Posts: n/a
Default

Oh, keine externen links erlaubt?
Kurzanleitung fürs Freigeben des inaktiven RAM:
1) Die von Apple veröffentlichten "Apple CHUD Tools 4.6.2" herunterladen und installieren.
2) Im Terminal den Befehl "purge" eingeben
Reply With Quote
  #36  
Old 10.02.2011, 12:23
cobrito
Guest
 
Posts: n/a
Default

So, das hat mir jetzt keine Ruhe gelassen. Nachdem ich getestet habe, dass der purge-Befehl problemlos gestartet werden kann, auch während jDownloader läuft bzw. downloaded, hab ich mir einen automatischen Workaround gebastelt.

Auf meinem Download-Ordner liegt nun eine Ordneraktion, die automatisch ein shell-script triggert, sobald eine neue Datei im Ordner angelegt wird. Das shell-script liest den derzeitigen freien RAM aus und führt purge aus, wenn der freie RAM einen bestimmten Schwellenwert (zB. 256 MB) unterschreitet. Purge gibt den inaktiven RAM frei und jDownloader hat wieder genug RAM, um sich breit zu machen.

Und da eine neue Datei (=ein neuer part) immer dann begonnen wird, wenn ein alter beendet ist, ist das vom Timing her ganz okay.

Das shell-script ist ganz einfach:
Code:
#!/bin/bash
threshold=$1
current=`top -l 1 | grep Phys | cut -d " " -f 10 | cut -d M -f1`
if [ $current -lt $threshold ];
	then
		purge
fi
Die Ordneraktion ebenfalls:
Führe das shell script "/Volumes/Daten/Stefan/Downloads/jDownloader/purgeScript 256" aus.

Funktioniert perfekt. Freilich bleibt es ein Workaround - lieber wär es mir, wenn die jDownloader Jungs das Problem lösen würden.

Last edited by cobrito; 10.02.2011 at 12:26.
Reply With Quote
  #37  
Old 10.02.2011, 12:41
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 63,396
Default

Auf unsrem iMac kann ich keinerlei Probleme feststellen.
Bitte mal genau beschreiben was das Problem ist? der wachsende Virtuelle Speicher liegt an Mac und nicht an JD/Java.
__________________
JD-Dev & Server-Admin
Reply With Quote
  #38  
Old 10.02.2011, 15:26
cobrito
Guest
 
Posts: n/a
Default

Dann hast du vielleicht keinen großen Download (mehrere GB) als Test genommen.

Also nochmal das Problem:
Für jeden Part wird RAM in der Größe des Parts alloziert. Ist der Part fertig runter geladen, wird der allozierte Speicher wieder frei gegeben (Java Garbage Collection). So weit, so gut. ABER: Unter Mac OS ist es so, dass der Speicher nicht komplett frei gegeben wird, sondern als inaktiv gekennzeichnet wird. Dahinter steckt die Heuristik, dass kürzlich benötigte Daten vielleicht rasch wieder gebraucht werden. Der inaktive Speicher wird es dann wieder hergenommen, wenn kein freier mehr verfügbar ist. So sollte es sein. Zweites ABER: So ist es bei uns allen nicht. Wird ein neuer Part begonnen, wird der Speicher nicht aus dem inaktivem, sondern aus dem freien RAM genommen. Da es den aber nicht mehr gibt, fängt das System kräftig zu pagen an.

Das ist wie du sagst, im Grunde kein Problem vom JD oder von Java, sondern von der Speicherverwaltung von Mac OS. Interessant ist nur, dass der Speicher komplett frei gegeben wird, wenn man im JD den Part von der Platte entfernt. Vielleicht existiert doch noch irgendein Pointer auf die Datenstruktur für den Part?

Was ihr tun könnt: Meiner Meinung nach ist es kein guter Programmierstil, dass ihr für jeden Part Speicher in dessen Größe anfordert. Nachdem eh alles sofort auf die Platte geschrieben wird, reicht ein kleiner Puffer. Dann hätte man diese Probleme mit dem inaktivem Speicher gar nicht.
Reply With Quote
  #39  
Old 10.02.2011, 16:35
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 63,396
Default

Quote:
Originally Posted by cobrito View Post
Was ihr tun könnt: Meiner Meinung nach ist es kein guter Programmierstil, dass ihr für jeden Part Speicher in dessen Größe anfordert. Nachdem eh alles sofort auf die Platte geschrieben wird, reicht ein kleiner Puffer. Dann hätte man diese Probleme mit dem inaktivem Speicher gar nicht.
tja, ich würde dir zustimmen, falls das so wäre
jedoch nutzen wir max 2mb (default ist 512kb) buffer pro connection und das wars.

ich kann wie gesagt das problem auch bei einer 8gbyte file nicht nachvollziehen. bin aber noch immer auf ursachenforschung und mögliche ursachen.

ich bitte euch die nightly zu testen, da dort eine andere art speicher genutzt wird.
__________________
JD-Dev & Server-Admin
Reply With Quote
  #40  
Old 10.02.2011, 17:01
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 63,396
Default

okay, anscheinend hat apple probleme mit bytebuffers diese werden in neuern jd versionen auch nicht mehr verwendet (siehe nightly). aktuell hilft wohl nur der workaround mit purge.
__________________
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 09:46.
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 - 2019, Jelsoft Enterprises Ltd.