JDownloader Community - Appwork GmbH
 

Notices

Reply
 
Thread Tools Display Modes
  #1  
Old 10.11.2009, 10:08
miscarriage
Guest
 
Posts: n/a
Default Mac OS X 10.6.2 -> Ram läuft voll :: kein Free Ram mehr, inactive Ram is voll

Moin Leute!

Kennt jemand das oben beschriebene Phänomen und kennt Abhilfe? Ich hab 4GB Ram und 2,53 GHZ C2D. Mit der Zeit steigt dann auch die Zahl der PageOuts (also Ramauslagerungen auf die Festplatte). Dies passiert auch bei meine Notebook (2GB Ram).

Danke schonmal für eure Hilfe!

Last edited by Jiaz; 10.11.2009 at 14:13.
Reply With Quote
  #2  
Old 10.11.2009, 14:13
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 79,290
Default

welche java version? (java -version)
logfile?

welches theme?
mal ohne jdgrowl versucht?
__________________
JD-Dev & Server-Admin
Reply With Quote
  #3  
Old 11.11.2009, 16:00
miscarriage
Guest
 
Posts: n/a
Default

neuste javaversion, und sonst alles standart

zu hause schau ich aber nochmal genauer und logfile reiche ich nach!
Reply With Quote
  #4  
Old 17.11.2009, 11:34
Gamewalker
Guest
 
Posts: n/a
Default

Ich hab das Problem nicht, was genau machst du?

Java aktuell ist momentan:
java version "1.6.0_15"
Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219)
Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02-90, mixed mode)
Reply With Quote
  #5  
Old 16.03.2010, 18:46
MichalM.Mac
Guest
 
Posts: n/a
Default

Hi

I habe gleiche Probleme. Ich sprechne Deutsch nicht gut... so..

I have exactly same problem. Downloading files from Rapidshare causes Inactive RAM to go sky high. Bacisly, there is no free RAM, only inactive and Mac is extremly slow. Even if you quict jD, there is no inmediate difference. After some time, OS eventualy clears out inative RAM.

I have Mac OS X 10.6.2 with lates Java Available through software update.
MPB SR 2.4 GHz, 4GB RAM
Reply With Quote
  #6  
Old 18.03.2010, 18:34
BMP
Guest
 
Posts: n/a
Default

Ich hab das Problem nicht...
OS X 10.6.2
Java6
Reply With Quote
  #7  
Old 23.03.2010, 01:59
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 79,290
Default

java can only use up to 512mb ram, if it uses more, then the memleak comes from different place (firewall, antivirus) and you must check settings there (add java to exclude list will help)
__________________
JD-Dev & Server-Admin
Reply With Quote
  #8  
Old 12.04.2010, 01:26
MichalM.Mac
Guest
 
Posts: n/a
Default

Here is the funny thing. When I delete downloaded files from Harddrive... Inactive RAM becomes free RAM. Interesting...
Reply With Quote
  #9  
Old 04.12.2010, 18:35
`Black
Guest
 
Posts: n/a
Default

jDownloader 0.9.580
Mac OS X 10.6.5
Java 1.6 Update 3

Gleiches Problem hier... mit jedem neuen Part werden etwa 100MB mehr inaktiver Ram genutzt und nicht wieder freigegeben. Erst wenn ich die Parts von der Festplatte lösche (oder das System neu starte), wird der Ram freigegeben. Ziemlich nervig, da das ganze System nach einer Zeit extrem langsam wird, wenn jDownloader läuft.
Reply With Quote
  #10  
Old 06.12.2010, 10:34
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 79,290
Default

klingt nach virenscanner und firewall. diesen bitte korrekt einstellen.
__________________
JD-Dev & Server-Admin
Reply With Quote
  #11  
Old 07.12.2010, 17:28
`Black
Guest
 
Posts: n/a
Default

Weder Firewall noch Virenscanner laufen. Einzig die Firewall im Router (SonicWall) ist an, aber daran kann es doch kaum liegen?
Reply With Quote
  #12  
Old 07.12.2010, 17:32
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 79,290
Default

versuch mal bitte die nightly (siehe forumssuche)
__________________
JD-Dev & Server-Admin
Reply With Quote
  #13  
Old 07.12.2010, 19:17
`Black
Guest
 
Posts: n/a
Default

Leider auch mit der Nightly das gleiche Problem.

Edit: Bei der Nightly gibts ja unter OS X unten jetzt im Docksymbol so einen Badge wie bei neuen Mails. Was zeigt der genau an? Aktuell laufende Downloads oder die Anzahl der zur Laufzeit abgeschlossenen Downloads?

Last edited by `Black; 07.12.2010 at 19:29.
Reply With Quote
  #14  
Old 07.12.2010, 20:06
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 79,290
Default

bitte informationen üebr java version? proxy? firewall/av?
__________________
JD-Dev & Server-Admin
Reply With Quote
  #15  
Old 07.12.2010, 20:55
`Black
Guest
 
Posts: n/a
Default

Java Version ist 1.6.0_22-b04-307-10M3261. Firewall/AV habe ich wie gesagt beides nicht, Proxy wird nicht verwendet.
Reply With Quote
  #16  
Old 08.12.2010, 11:08
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 79,290
Default

bitte komm mal in den supportchat und wir schaun uns das gemeinsam an
__________________
JD-Dev & Server-Admin
Reply With Quote
  #17  
Old 04.01.2011, 12:53
cobrito
Guest
 
Posts: n/a
Default

Ist das Problem von `Black zu lösen gewesen?

Bei mir ist es das gleiche Spiel. Für jeden neuen Part wird RAM gefressen - allerdings nicht aus dem inaktiven, sondern aus dem freien. Ist der aufgebraucht, fängt das System zu Pagen an (obwohl einige GB an inaktivem RAM vorhanden wären). Da ich eine SSD verwende, merke ich zwar keinen Geschwindigkeitseinbruch, aber die vielen Schreibzyklen auf der SSD stimmen mich bedenklich.

MacBook Pro mi OS X 10.6.5
i7 2,66 GHz
8 GB RAM
Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-10M3261)
Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03-307, mixed mode)
Kein Virenscanner, aber Little Snitch läuft. Eine Deaktivierung bringt aber auch nichts.

Gibts weitere Einsichten zu diesem Problem?

LG und Danke,
Stefan
Reply With Quote
  #18  
Old 04.01.2011, 12:55
cobrito
Guest
 
Posts: n/a
Default

Ach ja, bei mir ist es ebenfalls so, dass der inaktive RAM freigegeben wird, wenn ich die parts von der Festplatte lösche. Aber nicht händisch (dann ändert sich im RAM nichts), sondern via jDownloader.

Last edited by cobrito; 04.01.2011 at 14:39.
Reply With Quote
  #19  
Old 05.01.2011, 02:07
`Black
Guest
 
Posts: n/a
Default

Nein, ist noch nicht gelöst und nervt weiterhin sehr. Der Ram wird natürlich aus dem freien genommen und dann in den inaktiven gepackt, der dann nicht wieder freigegeben wird, es sei denn, man löscht die Parts von der Festplatte. Ich meine (kann mich auch irren), dass der Ram auch von selbst freigegeben wird, allerdings passiert das erst sehr lange (Stunden) nachdem jDownloader schon wieder geschlossen ist. Immer funktioniert das aber nicht von selbst.

@Jiaz
Kannst du sagen, wann du im Chat bist in den nächsten Tagen?
Reply With Quote
  #20  
Old 12.01.2011, 11:52
mi2g
Guest
 
Posts: n/a
Default

Ich habe hier das selbe Problem.

Macbook 2.4ghz core2duo
4 gb ram
Reply With Quote
  #21  
Old 15.01.2011, 17: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, 08: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, 10:59
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 79,290
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, 01: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, 09: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, 15: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, 15:59
mi2g
Guest
 
Posts: n/a
Default

Danke schön.

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

Hat keine Nachteile.
Reply With Quote
  #29  
Old 26.01.2011, 23: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, 11: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, 10:53
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 79,290
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, 19: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, 11: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, 10: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, 10: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, 13: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 13:26.
Reply With Quote
  #37  
Old 10.02.2011, 13:41
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 79,290
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, 16: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, 17:35
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 79,290
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, 18:01
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 79,290
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 12:20.
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 - 2024, Jelsoft Enterprises Ltd.