|
[In progress] Mac OS X 10.6.2 -> Ram läuft voll :: kein Free Ram mehr, inactive Ram is voll |
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
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 13:13. |
#2
|
||||
|
||||
welche java version? (java -version)
logfile? welches theme? mal ohne jdgrowl versucht?
__________________
JD-Dev & Server-Admin |
#3
|
|||
|
|||
neuste javaversion, und sonst alles standart
zu hause schau ich aber nochmal genauer und logfile reiche ich nach! |
#4
|
|||
|
|||
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) |
#5
|
|||
|
|||
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 |
#6
|
|||
|
|||
Ich hab das Problem nicht...
OS X 10.6.2 Java6 |
#7
|
||||
|
||||
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 |
#8
|
|||
|
|||
Here is the funny thing. When I delete downloaded files from Harddrive... Inactive RAM becomes free RAM. Interesting...
|
#9
|
|||
|
|||
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. |
#10
|
||||
|
||||
klingt nach virenscanner und firewall. diesen bitte korrekt einstellen.
__________________
JD-Dev & Server-Admin |
#11
|
|||
|
|||
Weder Firewall noch Virenscanner laufen. Einzig die Firewall im Router (SonicWall) ist an, aber daran kann es doch kaum liegen?
|
#12
|
||||
|
||||
versuch mal bitte die nightly (siehe forumssuche)
__________________
JD-Dev & Server-Admin |
#13
|
|||
|
|||
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 18:29. |
#14
|
||||
|
||||
bitte informationen üebr java version? proxy? firewall/av?
__________________
JD-Dev & Server-Admin |
#15
|
|||
|
|||
Java Version ist 1.6.0_22-b04-307-10M3261. Firewall/AV habe ich wie gesagt beides nicht, Proxy wird nicht verwendet.
|
#16
|
||||
|
||||
bitte komm mal in den supportchat und wir schaun uns das gemeinsam an
__________________
JD-Dev & Server-Admin |
#17
|
|||
|
|||
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 |
#18
|
|||
|
|||
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 13:39. |
#19
|
|||
|
|||
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? |
#20
|
|||
|
|||
Ich habe hier das selbe Problem.
Macbook 2.4ghz core2duo 4 gb ram |
#21
|
|||
|
|||
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? |
#22
|
|||
|
|||
Hallo zusammen
Gibt es schon News diesbezüglich. Dies ist ja sicher ein Problem mit hoher Priorität. oder? Gruss mi2g |
#23
|
||||
|
||||
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 |
#24
|
|||
|
|||
jDownloader im 32-Bit Modus laufen lassen behebt das Problem. Das ich das nicht gleich mal probiert habe...
|
#25
|
|||
|
|||
Quote:
wenn ja wie lasse ich JD im 32-Bit Modus laufen? |
#26
|
|||
|
|||
Apfel+I auf jDownloader.app und dann bei "Im 32-Bit Modus öffnen" einen Haken setzen.
|
#27
|
|||
|
|||
Danke schön.
Und das hat keine Nachteile? |
#28
|
|||
|
|||
Hat keine Nachteile.
|
#29
|
|||
|
|||
Also ich führe JD jetzt im 32bit Modus aus. Jedoch habe ich immer noch den gleichen Fehler.
|
#30
|
|||
|
|||
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.
|
#31
|
||||
|
||||
bitte probiert auch mal unterschiedliche themes/styles
und mit aktiviertem/deaktiviertem log/reconnect
__________________
JD-Dev & Server-Admin |
#32
|
|||
|
|||
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. |
#33
|
|||
|
|||
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:
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. |
#34
|
|||
|
|||
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.
|
#35
|
|||
|
|||
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 |
#36
|
|||
|
|||
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 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. |
#37
|
||||
|
||||
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 |
#38
|
|||
|
|||
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. |
#39
|
||||
|
||||
Quote:
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 |
#40
|
||||
|
||||
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 |
|
|