Interessant, Swap obwohl 16 GB RAM

Nein, geht ja auch gar nicht, er schrieb richtigerweise von "sabotieren", was natürlich mitklingen läßt, da wäre Absicht dabei. An das glaube ich aber zuletzt.

Die Adobe-Anwendungen sind fette Brocken, deren Kerne eigene C++-Libraries für so ziemlich alles außer GUI und Betriebsystem-Interaktion sind (weil sie die Idee, das Zeugs cross-platform anzubieten, auf dem Weg verfolgen, was seine Vor- und natürlich auch gewaltige Nachteile hat).

Unter OS X haben sie natürlich immer auf Carbon gesetzt (sonst hätte der Wechsel von MacOS 9 auf MacOS X seitens Adobe damals gar nicht erst stattgefunden sondern Adobe gäbe es heute nur noch unter Windows und OS X aus der Perspektive graphisches Gewerbe eine reine Privatleute-Plattform).

Eigentlich hatte Apple mal angekündigt, auch via Carbon einen 64-Bit-Weg aufzuzeigen (Carbon64), dann kam aber das iPhone, Apple hat Entwicklerresourcen von OS X abgezogen und auf iOS geschmissen und in Folge wurde dann Carbon64 heimlich, still und leise beerdigt. Und bei Adobe konnten sie dann Mannmonate Entwicklung in die Tonne treten und standen erneut vor der Wahl, den Mac als Plattform aufzugeben oder sämtliche Anwendungen nach Cocoa zu portieren (was aus Adobes Sicht mit ihren cross-platform-Libaries erstmal nur Nachteile und keine gravierenden Vorteile bringt, siehe und auch )

Das nur so als grundlegende Erläuterung, warum Adobe aus externer Perspektive so elend lahm ist darin, OS X Core Technologien zu adaptieren. Einfach weil's bei der Aufgabenstellung cross-platform und ihrem Ansatz, das Problem anzugehen und der Komplexität des Ganzen, nicht so verdammt einfach ist.

Was Marcel bzgl. Speicherverwaltung angesprochen hat, war glaub ich Folgendes: In einem UNIX kannst Du auf eine Datei, die auf Platte liegt, auch via "memory mapped files" zugreifen. Da ein UNIX eh einen quasi unbeschränkt großen virtuellen Adreßraum hat und im Grunde genommen eh immer egal ist, ob eine Speicherseite im RAM oder auf Platte liegt, könnte man einfach als Programm ein 100 MByte großes TIFF schon mal in den virtuellen Adreßraum einblenden und wenn Photoshop dran drauf zugreifen will, kommt es zu "Seitenfehlern" und das UNIX unter der Haube schaufelt unbemerkt von der Anwendung den Inhalt des TIFFs von der Platte ins RAM (hat Marcel selbst schöner hier schon mal erklärt: )

Das wäre ein "moderner" Ansatz, Adobe nutzt(e) stattdessen andere/veraltete APIs, liest die Datei von Platte in den Speicher, was den Disk-Cache auf den Plan ruft und irgendwie für sinnlosen Datentransfer zwischen verschiedenen Bereichen von Platte und RAM sorgt (das ist das, was Marcel als antiquiert bezeichnet -- vermute ich) und sichert am Ende das Ganze auch wieder über irgendwelche APIs zurück auf Platte.

Der Ansatz hat aber eben auch den großen Vorteil, dass sowas bspw. dann noch "im Netzwerk" (also in konkreten Netzwerken auf AFP- und SMB-Basis wie sie bei Millionen Adobe-Kunden existieren und in Gebrauch sind) inkl. Locking funktioniert, nicht an solchen Benachrichtigungs-Mechanismen wie FSEvents (wichtig für Spotlight und TimeMachine bspw.) vorbeirauscht, etc.

Soweit meine Vermutung, was Marcel diesbzgl. meinte. Ich bin auf dem Gebiet (low-level UNIX) im Gegensatz zu ihm aber so gut wie ahnungslos, daher meine Einlassung mit maximaler Vorsicht betrachten.

Jedenfalls wäre interessant, sich das heute, wo nun alle Adobe-Programme komplett auf Cocoa portiert sind, mit dem Memory-Verhalten nochmal genauer anzugucken. Ich spiel grad nebenher mit den interessanten Tools hier rum (teils als Code-Samples bzw. fertige Binaries, teils bordeigene Tools wie vmmap mal so erklärt, dass man auch was checkt), der Erkenntnisgewinn läßt aber bzgl. virtual memory noch auf sich warten. Aber das nächste Projekt, wo man gezwungen wird, sich das im Detail ins Hirn zu schrauben, kommt bestimmt...

War das nicht die kleine häßliche Schwester von SoftRAM ?

Nein, das war wirklich sinnvoll. Brachte Speicherkompression und swapping für System 7-9

In Grenzen. Und für Sparfüchse. Man hat fehlendes RAM gegen CPU-Last eingetauscht (irgendeinen Haken mußte die Sache ja haben). Das hat in manchen Bereichen wirklich geholfen (v.a. die "Virtual"-Techbologie von Connectix, die da auch drinsteckte) aber nachdem die RAM-Preise schon zu Zeiten von RAM Doubler 2 recht drastisch runtergegangen sind (die 256 MByte in meinem damaligen Retusche-Arbeitspferd haben keine 25.000,- DM mehr gekostet ) hatte ich damit nur in meiner Ausbildungsklitsche kurz zu tun. Schon in dem Laden darauf wurden Milchmädchen- durch Kosten-/Nutzen-Rechnungen ersetzt und in dem Metier konnte ich zum Glück bis zum heutigen Tag bleiben

Hach, Nostalgie... 4 MByte RAM...

Mir ist da noch eine Frage eingefallen.

Wenn tatsächlich Swap verwendet wird und Daten aus dem Swap gebraucht wird, muss dann der Kram wirklich erneut in dem physikalischen RAM kopiert werden? Kann das OS eigentlich einen Teil der Festplatte - genauer gesagt die Swap File - als einen Teil des RAMs betrachten?

Weil eigentlich wäre es ja beknackt, dann einen Teil des RAMs auf die HDD zu kopieren und einen Teil der Swap File in den RAM zu kopieren.

Das ist ein Punkt, der mir noch nicht klar ist.

Studi mit LC III und CAD-Anwendung… Immerhin schon eine 80 MB Festplatte
Was soll ich sagen - ich war jung und brauchte das Geld für Wichtigeres

Das passiert ja wirklich nur in Situationen, in denen definitiv zu wenig physisches/reales RAM da ist. Dann muß natürlich irgendwie Platz geschaffen werden, d.h. Kram, der unnütz RAM verbraucht, aus diesem verfrachtet werden. Aber das sollte nur passieren, wenn Dein RAM notorisch unterdimensioniert ist. Und nochmals der Hinweis auf . Interessant, wie Mavericks' VM-Verwaltung von iOS "gelernt" hat bzw. partiell inspiriert wurde.

Erinnerst Du Dich an meinen Screenshot von vorgestern? Nachdem das amoklaufende Programm dafür gesorgt hat, dass allen anderen Programme RAM weggeswapped wurden, hatte ich über 5 GB free. Und 39,67 GB Page-Outs. Jetzt 2 Tage später wird natürlich permanent Zeugs von Platte zurück ins RAM geholt. Aber da immer noch genügend free+inactive da ist, selbstverständlich deshalb nichts, was jetzt im RAM wäre, rausgeswappt.

Deshalb immer noch identische Anzeige bei Page-Outs (und wie schon so oft geschrieben: Die Anzeige bzgl. "Swap used" völlig irrelevant. Der dynamic_pager hat wohl zwischendrin in den paar swapfiles unterhalb /var/vm rumoptimieren können und deshalb belegen die jetzt paar hundert MByte weniger. Aber das ist völlig irrelevant)

Bei meinem aktuellen Nutzungsverhalten wird sicherlich in den nächsten Tagen noch mehr wieder von Platte zurückgeswappt werden (Illustrator und InDesign muß ich später bspw. noch nutzen, die laufen beide seit 3 Wochen und haben paar Dokumente "aktiv") aber die nächsten Page-Outs werden voraussichtlich erst in paar Wochen wieder auftreten. Aber vermutlich ratzt mir die Kiste vorher ab (ist halt auch Testkiste für Netzwerk-Relevantes) und dann kommt dem Ganzen ein Neustart bevor...

Ich hätte mir damals definitiv keinen Mac leisten können bzw. wollen. Hmm... grad überlegt, den einzigen Apple, den ich mir privat zugelegt habe, war mal ein IIc aus nostalgischen Gründen. Die ganzen Macs wurden allesamt beruflich angeschafft...

Mmmh, meine Frage hast du mir trotzdem nicht beantwortet.

Irgendwie ist das seltsam. Vorhin startete der Bildschirmschoner und als ich eine Taste gedrückt habe, tat sich ne Weile nix.

Dann warf ich einen Blick in die Aktivitätsanzeige und entdecke dies:
das andere ist von MenuMeters

was'n da los?!

"Irgendwas" hat da vor Kurzem nach massig RAM gelechzt, was dann zum Rausschwappen von über 6 Gbyte geführt hat und wohl selbst Programme wie loginwindow betroffen haben dürfte (daher dann evtl. auch Verzögerung bei Beendigung des Bildschirmschoners -- was ins RAM gehört und auf Platte ist, braucht dann halt kurz (SSD) oder lang (HD) um wieder zurückgeholt zu werden.

Ich hatte sowas Ähnliches ja vorgestern, wo ein kleiner Task, der Amazon-EBooks nach ePUB konvertieren sollte, hohlgedreht hat. Nach Abschuß desselben dann ähnliches Bild.

Mmmh, ich hab was in der Konsole entdeckt.

Was heißt das denn hier?

Das ist jetzt ohne Kontext eine kleine Reizwortgeschichte ohne Sinn und Verstand

Die Meldung deutet auf "low water mark" hin: (weder Zeit noch Lust, mir das anzulesen )

Nein, ganz entschieden nein! Apple hat vorsätzlich Carbon64 gegen die Wand gefahren, als lag nicht an fehlenden Resourcen! Apple wollte, daß jeder für 64Bit Applikationen Cocoa nutzen muß. Freundlicherweise hat man das allen Entwickler zum letztmöglichen Zeitpunkt mitgeteilt, währen der WWDC. Schlechtere Kommunikation kann man nicht praktizieren.
Memory Mapped Files sind nur unter bestimmten Rahmenbedingungen sinnvoll zu nutzen. Wenn man ohnehin auf die komplette Datei zugreift - wie bei EBV - ist es nicht sinnvoll auf mmap() zurückzugreifen. Hinzu kommt, daß man bei einem Multisockelsystem wegen der NUMA Problematik gezielt Speicher auf NUMA-Knoten allozieren muß, damit die Performance hoch ist. Unterläßt man es ist die Performance beim Bearbeiten der Daten schlechter. Das Problem hat Apple mit dem neuen MacPro auf die Apple typische Art und Weise gelöst, in dem sie den zweiten Sockel abgeschafft haben. Auch eine Möglichkeit das Problem zu lösen.
Das ist nicht modern (eingeführt mit 4.3 BSD bzw. SVR4). mmap() ist eine alte Systemfunktion, und wegen ihrer Probleme (z.B. Beschränkung auf 32Bit Adreßraum bei 32Bit Applikationen) nur für bestimmte Probleme geeignet. Da aber mmap neuer ist als read() ist es von Anfang an so implementiert worden, daß weniger Kopien im Speicher angelegt wurden. Aber das ist auch mehr von historischen Interesse, da auf read() mittlerweile effizienter implementiert wird.
Bresink spricht von Seitenflattern, das kann aber nur dann auftreten, wenn der Arbeitsspeicher nicht mehr ausreicht oder das OS übelste Bugs in der VM Verwaltung hat. Hat man ausreichend Speicher, kann es kein Seitenflattern durch eine schlecht programmierte Applikation geben.
Nein, das war eine effizientere Implementation des Swaps unter System 7.x Die Apple eigene Routine war ziemlich übel und nicht wirklich brauchbar. Genauso interessant war SpeedDoubler, das hat den Schrott von 68k Emulator auf PowerMacs von Apple durch einen brauchbaren Emulator ersetzt. Die Performance war dramatisch besser! Erst viel später war Apple in der Lage eine ähnliche Performance mit dem 68k Emulator zu erreichen.

Nein, die Swap Datei (bei anderen UNICES sind Swap Partitionen üblicher, weil bei denen die Performance besser ist) ist eine Datei in der ausgelagerte Speicherseiten abgelegt werden können. Unter UNIX ist der Arbeitsspeicher grundsätzlich in virtuelle Speicherseiten aufgeteilt. Das war zwar nicht von Anfang an so, aber die virtuelle Speicherverwaltung ist in UNIX sehr alt. So alt, das zu Zeiten von 68000 Macs in UNIX Maschinen keine 68000 sondern 68010 oder 68012 verwendet wurden, weil diese eine PMMU ansteuern konnten wozu der 68000 nicht in der Lage war. Eine virtuelle Speicherseite kann nun einem Programm zugeteilt aber noch nicht angelegt sein (memory overcommitment), im Hauptspeicher liegen oder in einer Swap Datei oder Partition. Das OS fängt nur dann an Seiten aus dem Hauptspeicher auszulagern, wenn mehr physikalischer Speicher benötigt wird als tatsächlich vorhanden ist. Braucht dann ein Programm wieder Daten, die sich in ausgelagerten Seiten befinden, dann werden diese Seiten wieder in das physikalische RAM geladen. Zuvor müssen natürlich andere Seiten aus dem Hauptspeicher ausgelagert werden.

Wenn die Sache schlecht läuft kann es zum Seitenflattern kommen, d.h. das System ist faktisch nur noch damit beschäftigt Seiten hin und herzuschieben und kommt nicht mehr dazu effektiv irgend etwas zu tun.

Man kann in Applikationen durch spezielle Systemfunktionen verhindern, daß bestimmte Speicherbereiche überhaupt ausgelagert werden können. Diese Speicherbereiche verbleiben immer im RAM und werden niemals ausgelagert.

gfhfkgfhfk

Danke für die Antwort.

Übrigens, ich habe das Programm MenuMeters deinstalliert, zudem habe ich den Inhalt von /private/var/vm, /private/tmp, /private/var/tmp via sudo rm gelöscht. Seitdem rennt das System.

Etwas Offtopic (aber nur etwas) - manchmal™ funktioniert die Theorie

Peter

Äh, nicht ganz.

Ich musste den Mac einmal im Sicheren Systemstart starten und habe dabei auch gleich mal den Inhalt von /Library/Caches und /System/Library/Caches geleert.

Irgendwas hat sich da verschluckt.

Wie auch immer. Sie haben 2006 auf der WWDC Carbon64 angekündigt, die Developer Seeds enthielten ein 64-bittiges Carbon, Adobe fing damit an, Photoshop darauf zu portieren... und dann kam die 10.5-Verzögerung und die Abkündigung von Carbon ein Jahr später :

Mein Einwurf war auch eher an den kleinen gemeinen uninformierten Adobe-Basher gerichtet (aber der liest hier eh schon lange nicht mehr mit, falls er es je getan haben sollte ). Danke für die restlichen Ergänzungen/Korrekturen.

Wie meinen? Scusa, ich verstehe Zusammenhang Screenshot zusammen mit Kommentar nicht

Äh, wie zu erwarten. Wenn Du ein System hast, dessen Virtual Memory Implementierung gerade einen Teil des genutzen Speichers auf Platte auslagert und dann diese Dateien löscht, dann ist das so, als ob Du im laufenden Betrieb RAM-Riegel aus dem Mac reißt: Das kann nur nach hinten losgehen (außer bei fetten UNIX-Servern aber sowas sind Macs halt nunmal nicht).

Dito für Dateien unterhalb /tmp -- die sollte man auch nicht einfach so löschen, denn auf die greifen Programme oder Dienste ggf. noch zu. /tmp sollte man nie im laufenden Betrieb "bereinigen" sondern ganz simpel durch Neustart, sollte man auf neurotischen Systempflege-Quatsch stehen: Denn nur dann kommt man auf die abstruse Idee, ausgerechnet dort aufräumen zu wollen.

Ja, vor Angst. 😱

Man beachte zudem (man hier):

/var/tmp/ temporary files that are kept between system reboots
/var/folders/ per-user temporary files and caches

Und wie kommt man in den für den betreffenden $USER richtigen /var/folders-Ordner?
Der betreffende Pfad steht entweder in der Umgebungsvariable $TMPDIR drin uns lässt sich im Terminal per
auslesen.
Oder, wenn diese Umgebungsvariable leer (also nicht gesetzt) ist, kann der Pfad zum benutzerspezifischen Temp-Verzeichnis direkt per
ermittelt werden.

Äquivalent in Bezug auf das benutzerspezifische Cache-Verzeichnis:

Äh: nein.

Ich habe diese Dateien nach einem Neustart gelöscht, nachdem der Swap auf 0 gesunken ist. Vorher wäre das ja beknackt.

Und was soll der unwissende User jetzt damit anfangen? Ohne Ergänzung, dass er da besser auch immer schön die Finger davon läßt, denn dort einfach was im laufenden Betrieb zu löschen, geht im Regelfall genauso nach hinten los wie unterhalb /var/tmp.

Für ggf. noch Mitlesende: Es kommt ab und an vor, dass in diesen Verzeichnissen (die dynamisch unterhalb /var/folders angelegt) werden, Dateien liegen bleiben und fortan zwar nichts Böses tun (denn der Ablageort wird bei jedem Systemstart neu ausgewürfelt, d.h. "Altlasten" stören nie!) aber einfach Platz wegnehmen.

Wie kriegt man die jetzt weg? Entweder indem man manuell dort herumfuhrwerkt (und dann meist irgendwas falsch macht) oder indem man aus der Recovery Partition heraus alles unterhalb /var/folders abräumt. Oder indem man das einzig Sinnige macht: Sich überhaupt nicht um den ganzen Quatsch kümmern und alle 2-3 Monate mal einen "Sicheren Systemstart" durchführen (der räumt auch sowas ab).

Wenn sich nur die schlichte Erkenntnis endlich mal durchsetzen würde, dass ein simpler Neustart mit gedrückter -Taste seit spätestens OS X 10.4 nahezu alle typischen/bekannteren Mac-Probleme kuriert und auch präventiv/periodisch durchgeführt sinnvoll ist und als Holzhammer-Methode meist funktioniert (im Gegensatz zu "Rechte Reparieren", "PRAM zappen" und noch viel schlimmer "Systempflege mit Halb- oder Nullwissen" -- also irgendwelche blöden Optimierungstools laufen lassen)

Die swapfile-Dateien unterhalb /var/vm überleben eigentlich keinen Neustart. D.h. wenn da noch "alte" liegen, dann ist irgendwas faui. Wenn das frische waren, dann war's ein Fehler, die zu löschen. Und bzgl. "beknackt". Das hier ist ein Forum, hier lesen Leute mit, Google indiziert Zeugs, was hier geschrieben wird, binnen Minuten. Und der normale Leser kapiert aufgrund der Materie eh nur die Hälfte bis 10%, steht aber für gewöhnlich auf das Dümmste, das man am Mac machen kann: "Systempflege" von Hand.

Es geht (mir) bei Ergänzungen/Korrekturen/Anmerkungen nicht immer nur um den konkreten Diskurs sondern darum, Mitleser ggf. noch aufzuschlauen. Und in diesem Kontext: Finder weg von /var/vm. Immer! Als User hast Du da nie und sogar niemals nie irgendwas zu suchen. Außer Du bist Kernel Hacker und optimierst den dynamic_pager.

Ich habe diese Schritte deswegen unternommen, weil wie gesagt, bei der oben angezeigten Arbeitslast bzw. RAM-Auslastung hatte ich nie einen Swap. Irgendetwas oder irgendjemand muss die Speicherverwaltung durcheinander gebracht haben. Ich nicht, sondern irgendein Programm. Wahrscheinlich war dies MenuMeters und wohl ein korrupter Cache.

Denn nach dem Löschen und einen Sicheren Systemstart reagiert das System insgesamt viel schneller.

Nein, nein, nochmals nein. OS X basiert auf einem unixoiden Kern, die Speicherverwaltung ist Sache des Kernels. Prozesse -- egal, ob sie Caches anlegen oder nicht und auch völlig egal, was sie sonst so machen -- können beim Kernel um RAM betteln. Und wenn der Kernel das für OK hält, kriegen sie das (und in solchen Situationen kann dann Speicher anderer Prozesse -- inaktiven zu dem Zeitpunkt natürlich -- rausgeswappt werden).

Das ist alles. Irgendein Prozeß wollte viel RAM, hat das bekommen, und fertig. Passiert und passierte auf Millionen Macs und fertig. Die Leute, die den dynamic_pager deaktiviert haben, merken es nicht, obwohl ihnen der Rechner dann auch mal einfriert, weil sie die Ursachen auf irgendwas anderes schieben (der Mensch funktioniert halt nunmal so), die die ihren Mac im Auslieferungszustand betreiben, bemerken evtl. was, weil der Rechner langsamer wurde bedingt durch Swapping (und zum hundertsten mal: Wer eine SSD im Rechner hat, bemerkt vermutlich noch nicht mal das).

Bei Dir wurde kurzzeitig mal geswappt. Na und? Irgendein Prozeß hat hohlgedreht. Das hat keine Nachwirkungen. Nur wenn sowas andauernd passiert (und nochmal: Vor 10.9 ist da nur und wirklich nurnurnur die Anzeige bei Page-Outs in Klammern relevant), dann muß man sich Gedanken machen. Bzgl. RAM aufrüsten oder Analyse, was da regelmäßig hohldreht. Ansonsten ignoriert man sowas, weil's völlig wurscht ist (außer Du hast noch 10.4 am Laufen, da gab's einen Bug dergestalt, dass Memory-Alloziierung eines beliebigen Prozesses das System zum Absturz bringen konnte)

Das einzige echte Problem bist Du , weil Du in die Aktivitätsanzeige glotzt und dort auf "Verwendeter Swap" schielst und dann auf blöde Ideen kommst. Ich würde an Deiner Stelle MenuMeters so einstellen, dass nur die CPU-Last angezeigt wird (und ggf. Netzwerk-Durchsatz) und ich würde die Aktivitätsanzeige so einstellen, dass Du nichts mehr bzgl. VM mitbekommst (erst nach Update auf 10.9 wieder, denn da zeigt die Aktivitätsanzeige keinen verwirrenden Quatsch mehr an)

So what? Das ist die wunderbare Wirkung des Neustarts, wenn vorher irgendwas aus dem Ruder lief.

Thomas Kaiser:

Nun wische Dir mal wieder den Schaum vorm Mund weg und atme mal wieder locker durch die Hose.

Gar nichts. Der Hinweis hat sich nicht an den unwissenden Nutzer gerichtet, sondern ist von mir zur allgemeinen Info bzw. dann auch eher als Hinweis in Deine Richtung (in der stillen Annahme, dass Du's eh schon weißt) oder, da er ja sowieso schon am /tmp-Verzeichnis rumgefuddelt hat, an dom_beta gerichtet gewesen.

Ja.
Das setzt sich wahrscheinlich nur deshalb als allgemeine Erkenntnis nicht durch, weil niemand drüber redet und aufklärt, was dabei nun alles passiert im Einzelnen, und was damit konkret erreicht werden kann.
Ein "Tue das mal, passt scho!'" ist zuwenig als Erklärung. Eine solche "Erklärung" ist dann nämlich genauso wenig informativ und zielführend wie der zurecht von Dir bemängelte Hinweis des "Lass' mal die Rechte reparieren", ohne dabei aber zu sagen und zu wissen, was das denn genau dabei macht und im Endeffekt bedeutet.

Der durchschnittliche Apple-Benutzer sollte nicht künstlich dumm gehalten werden à la "Brauchst Du nicht zu wissen", auch wenn das jahrelang Apple Policy gewesen ist – er ist intelligenter und aufnahmefähiger als manche ihn halten. Und man kann ihm durchaus zumuten, zu wissen, wie einzelne Teile des von ihm benutzten Systems funktionieren und welche Bedeutung, welchen Sinn sie haben. Und in diesem Sinn möchte ich meine kleine Ergänzung, meinen kleinen Info-Hinweis bitte verstanden wissen.

Die benutzerspezifischen Temp- und Cache-Verzeichnisse unterhalb von /var/folders/ haben vor allem den Sinn, dass sie eben benutzerspezifisch angelegt sind und deren Pfad nicht vorhersagbar vorherbestimmt ist. Letzteres hat Sicherheitsgründe, die mit einem Pfad, dessen einer Pfadanteil durch einen Zufallsstring angelegt ist, auf diese Weise umgesetzt werden. Die Pfade für die Benutzerprofile in Mozilla Firefox und Thunderbird sind zu diesem Zweck auf ziemlich gleiche Weise randomisiert.

Auch die benutzerspezifischen Font-Cache-Dateien sind im benutzerspezifischen Cache-Pfad unterhalb von /var/folders zu finden. Soweit ich informiert bin ist z.B. ~/Library/Caches bzw. ~/Library/Caches/TemporaryItems aus Sicherheitsgründen nicht mehr der empfohlene Ort 1. Wahl, um von Programmen generierte Caches und temporäre Dateien abzulegen, so sollen z.B. auch bei Downloads auftretende temporäre Dateien lieber unter /var/folders abgelegt werden als sonstwo.

Natürlich ist das, was Du da mit dem sog. "Sicheren Systemstart" per Neustart mit gleichzeitig gedrückter -Taste anempfiehlst, eine gute Holzhammer-Methode, mal mit einem Schlag aufräumen zu lassen. Trotzdem wäre es wohl hilfreich, dass der Benutzer weiß, was dieser Holzhammer im Einzelnen nun alles bewirkt, bevor er mit ihm draufhaut.

Ich hingegen hatte diese Holzhammer-Methode des "Sicheren Neustarts" und was sie im Einzelnen alles tut gar nicht im Sinn, als ich obigen Eintrag geschrieben habe. Ich wollte nur dezent drauf hinweisen, dass es neben /tmp diese (nicht ganz unwichtigen) Verzeichnisse auch noch gibt. Mehr wollte ich gar nicht. Ich wollte keine Handlungsanweisung oder Handlungsempfehlung geben, so wie Du vielleicht gemutmaßt haben magst.

Schön, mal wieder ein "echter sierkb". Kaum ergänzt man einen Beitrag inhaltlich, muß er es als persönlichen Angriff nehmen und von der inhaltlichen Ebene auf eine persönliche abgleiten.

Um auf diesem Niveau zu bleiben: Wenn jemand schon fälschlicherweise unterhalb /tmp rumlöscht, das in einem Forum (das ist ein Ort, in dem sich nicht nur zwei privat unterhalten sondern Dritte -- via Google&Co. ggf. in nicht zu unterschätzender Anzahl -- mitlesen) als hilfreich preist und dann jemand anderer ohne entsprechenden Warnhinweis weitere Pfade ergänzt, unterhalb deren neurotische Systempfleger dann ggf. auch manuell irgendwas kaputtmachen, dann hat Letzterer einfach nur einen Scheißtipp abgegeben, der mehr schadet als nutzt. Das darfst Du jetzt getrost persönlich und nicht als inhaltliche Ergänzung nehmen.

Es wäre ratsam, sich die ganzen Beiträge durchzulesen, damit den Kontext kennt und nicht einfach so irgendetwas so umsetzen.

Aber es gibt Leue, da kann man sich die Finger wund tippen und/oder sich den Mund fusselig reden, die lernen nix daraus, außer, sie laufen selbst gegen die Wand.

Thomas:

Ich bin ganz entspannt und habe nicht vor, auf die persönliche Ebene abzugleiten. Vielmehr habe ich in dieser Richtung umgekehrt den Eindruck gehabt, deshalb mein einleitender Satz mit Zwinker-Smiley.

Und: keine Sorge, ich mache Dir Deinen göttlichen Platz hier schon nicht streitig. Alles, was ich sage, ist scheiße, ich weiß, und alles was Du sagst, ist gut, toll und von göttlicher Unfehlbarkeit. Ergänzt man Dich oder einen Thread, in dem Du Dich König wähnst (Du sollst keine anderen Götter haben neben mir), reagierst Du mimosenhaft und divenhaft zickig, als hätte man Dich oder was Du geschrieben hast, infragegestellt. So wie jetzt. Ich kann darüber bzw. über Deine Reaktion grad' nur lachen. Du bist für mich diesbzgl. so vorhersehbar geworden. Kindisch, sowas. Tut mir leid. Dabei sind wir beide inhaltlich bei sovielen Dingen gar nicht auseinander, und ich stimme Dir innerlich sehr oft zu.

Wir sind Off-Topic. Zurück zum Thema.

Ähm nein.

Es wurde offensichtlich alles ausgelagert, was nicht System ist/war. Insofern merkwürdig. Habe deswegen auch Menumeters rausgeschmissen und die anderen Schritte durchgeführt.

Ich kann mich dem nur uneingeschränkt anschliessen
obwohl alles was Herr Kaiser angeht ist schon etwas merkwürdig hier ...
ich nehme mal an dass er ohne Mühe die meisten Beiträge hier kreiert (wie das jetzt mit dem Inhalt aussieht davon rede ich jetzt mal lieber nicht )
und sehr oft frage ich mich dann doch wo die Essenz ist oder ob es einfach nur um der lieben Diskussion willen schreibt - oftmals an den Haaren (oder per copy - paste eingefügte) Schachtelsätze sind die aus irgendeinem Wikipedia-Beitrag zu sein scheinen ?

1+

Naja, glaub, was Du willst. Dann ist bei Dir eben etwas Wundersames geschehen. Die Bedeutung von "kurzzeitig" ist Dir aber schon klar? Das heißt nicht "wenig" sondern "über einen kurzen Zeitraum hinweg".


Das ist kein Widerspruch. Ein beliebiger unprivilegierter Prozeß, der RAM anfordert bis der Arzt kommt, sorgt nunmal dafür, dass anderen gerade inaktiven Prozessen der Speicher rausgeswappt wird. Und wenn der Prozeß dann beendet wurde oder sich selbst beendet hat, sieht's genau so aus wie bei Dir (oder wie bei mir vor paar Tagen): Massig RAM auf einmal "free", alle laufenden Prozesse haben einen Großteil ihres Speichers auf Platte und nicht im RAM. In Folge wird ein Wechsel zu diesen Programmen folglich ein wenig Verzögerungen mit sich bringen, weil erst wieder reingeswappt werden muß.

So funktioniert Swapping eben -- alles völlig normal nach einer solchen Situation. Im nachhinein wirst Du auch nicht mehr rausfinden können, welcher Prozeß da Speicher alloziiert hat wie nichts Gutes (außer er ist gecrasht, dann findest Du in den üblichen Verzeichnissen evtl. einen Hinweis).

Auf alle Fälle sind solche Maßnahmen wie manuelles Herumlöschen unterhalb /var/vm, /var/tmp und sonstigen temporären Systemverzeichnissen immer hochgradig schädlich, wenn man nicht genau weiß, was man tut. Lieber den richtigen Weg nehmen:

Für mich jetzt hier Endstation. Für weitere Rückfragen wirst Du auf die Expertise der anderen noch Mitschreibenden zurückgreifen müssen

Tja, nur hat ganz offenbar Thomas schlicht mehr Ahnung als die meisten hier. Ich kenne diesen Effekt selber (meistens beruflich und hat mit den oft gruseligen Untiefen von Windows zu tun): Ich bekomme es aus den Hirnen aus manchen einfach nicht raus, daß gewisse Dinge einfach schlicht nicht mehr notwendig sind, weil es das System einfach besser kann, oder eben das manche Dinge noch genauso schlimm oder schlimmer sind, wie zu NT-Zeiten. Ist ein Sinnloser Kampf gegen Windmühlen. Leider wirkt sowas immer schnell besserwisserisch und herablassend.

PaulMuadDib:

Ich würde mir hier mal mehr ein kollegiales und achtungsvolleres Mit- und Nebeneinander wünschen statt dieses ständige Gegeneinanderboxen und "Er oder ich".

Ich habe gegen Thomas' fachlich fundierte Ausführungen überhaupt nichts – ganz im Gegenteil: auch ich erfreue mich daran und schätze sie sehr und stimme ihm innerlich und auch manchmal nach außen hin sichtbar oft zu, und ich will ihn darin auch gar nicht stören und unterbrechen.
Ich jedenfalls bin mir keiner bösen Absicht meinerseits bewusst, mag es nur nicht, zu jeder Gelegenheit von oben herab abgemeiert zu werden, als hätte ich den Papst höchstpersönlich beleidigt, nur weil ich mich zu Wort gemeldet und leise und doch recht zurückhaltend ohne mich in den Vordergrund drängen zu wollen, ergänzt habe, dass es neben A auch noch B gibt (und eigentlich richtete sich meine ursprüngl. Ergänzung von oben dann doch eher in Richtung dom_beta als in Richtung Thomas, das habe ich aber bereits obig deutlich gemacht). Wenn dann jemand so empfindlich reagiert wie Thomas oben (und es ist ja nicht das erste Mal, dass er mir gegenüber so reagiert und mich so abkanzelt), dann fällt mir eigentlich nicht mehr viel dazu ein, als darüber lachen zu können, weil's total kindisch ist. Als hätte ich ihm im Sandkasten seine schöne Sandburg kaputtgetreten. Habe ich aber nicht! Habe ich auch nicht vorgehabt oder je vor!

Im Gegenteil: ich freue mich sehr, dass er hier sein Fachwissen kompetent zum Besten gibt und schließe mich der Kritik an ihm, die andere hier vorbringen, ausdrücklich nicht an (auch nicht, was seine langen Texte angeht, bin ich damit dann also nicht alleine), und bei so einigen Themen sind er und ich Brüder im Geiste und wissen und/oder denken gleich oder zumindest ähnlich (bei einigen Themen hat er mir gegenüber einen Wissensvorsprung, den ich allerdings gerne zu schätzen weiß, ich lerne gerne, ich sauge gerne Wissen auf) und haben auch gleiche oder ähnliche Argumente. Warum das nicht erkennen und offen gemeinsam an einem Strang ziehen und sich gegenseitig unterstützen und ergänzen statt gegeneinander zu arbeiten?

Ich habe ich das schon mal gesagt und auch angeboten, ihm diesbzgl. eine Hand gereicht. Ich würde das begrüßen, würde mich darüber sehr freuen. Gerne von sofort an. Meine Türe steht offen, meine Hand ist gereicht. Schon seit längerem. Und eigentlich weiß Thomas das auch, ich habe es ihm gegenüber schon mal per PM mitgeteilt, wenn ich mich nicht falsch zurückerinnere. Antwort darauf von ihm bisher: zu meinem Bedauern leider keine.

Ich habe jahrelang genau solche Kritik auf mich gezogen und ziehe sie wohl bis zum heutigen Tag auf mich, die Thomas von wolf1210 und auch in anderen Threads von anderen auf sich gezogen hat. Wie oft wurde und wird mir genau dasselbe vorgeworfen wie jetzt ihm? Von daher möchte ich mich hiermit gerne schützend vor ihn stellen. Ich teile diese Kritiken ausdrücklich nicht und bin sehr zufrieden mit dem, was er schreibt und mit dem, wie er es schreibt, habe daran nichts auszusetzen, begrüße es sogar sehr.

Wir sind schon wieder Off-Topic. Warum eigentlich?

Nein, Fehler 404 in deinem Link

Bei allem theoretischem Herbeireden über Instabilitäten und möglichen Problemen. Hier ein aktueller Uptime-Screenshot bei deaktiviertem Swapping. OS läuft merklich geschmeidiger und keinen Deut anfällig. Genutzte App ist TinkerToolSystems. Mac läuft im Dauerbetrieb. Grafikprogramme, Virtuelle Maschinen, die ganze Bandbreite des Alltags wird genutzt.


Was so alles theoretisch problematisch sein mag, ist schön drum zu wissen. Danke für die theoretischen Informationen. Ich verwende derweil die Vorteile deaktivierten Swappings. Ganz praktisch und ohne Probleme. Swapping Null. Abstürze und Probleme Null. Fluppendes OS.

PS: Purge verwende ich ebenfalls dann und wann, weil einige alte Programme Speicher nicht freigeben (auch mit aktiviertem Swap). Auch keine Probleme. Löppt bestens, wie man an der Uptime sieht.

12,7 GByte frei....Gut, dass du die hast

Unnötig.

Ich habe heute mehrere GB mit ClamXAV gescannt, dabei lief nicht nur der RAM voll, sondern es wurde auch Swap angelegt. Nach einer halben Stunde hat sich das aber wieder normalisiert. Anwendung von purge & Co. überflüssig.

Und hätte er nicht RAM im Überfluß sondern reichlich aktive Prozesse, die 12,70000001 GByte mehr brauchen würden, wäre der Zusammenhang zwischen Theorie und Praxis (Kiste friert ein) endlich klar. So ist das nur ein schicker "Anscheinsbeweis", dass ein Rechner mit viel zu viel RAM, der eh nicht swappen würde, kein Problem trotz kruden Änderungen bekommt, weil er eh nicht swappen würde (mal aufs formal Logische runtergebrochen).

Würde Marcel Bresink oder irgendwer anders mit C-Kenntnissen mitlesen, könnte man sicher in Minuten ein Programm bereitstellen, das RAM alloziiert ohne Ende. Und dann wäre auch völlig klar, was passiert, wenn man den dynamic_pager austricksen will: Freeze. Ich hab sowas noch wegen der Arbeit an einem 10.4-Artikel hier aber nur als PowerPC-Binary 10.4 konnte man nämlich auch noch als unprivilegierter User trotz aktiviertem Swapping an die Wand fahren, wenn man mehr Speicher alloziiert hat, als RAM+Platte hergegeben haben...

Der Computer-Gott behüte Dein System vor einer Speicheranforderung über dessen RAM hinaus. Amen.

Jener Computer-Gott arbeitet zu seinem Glück bei Apple (wollte das eigentlich zum "mitdenken" aufsparen, kipps aber jetzt trotzdem ab, weil Sch***-Datenbank-Migration fertig und ab ins Bett). Als der XNU-Kernel auf iDevices gelangte, kam die Aufgabenstellung dazu, wie mit "low memory"-Situationen umzugehen ist, weil dort kein Swap existiert. Lösung: dies&das&sonstnochwas (siehe Link) und im ärgsten Fall werden inaktive Prozesse einfach gekillt.

Und genau das kam inzwischen zurück zu OS X: Alles haarklein in dem neulich schon geposteten Link beschrieben: (für die Querleser ab memorystatus/jetsam).

D.h. die Chancen stehen sogar sehr gut, dass selbst bei deaktiviertem Swap die Kiste ab 10.9 (ggf. schon 10.8) keinen freeze mehr hinlegt sondern vorher einfach Prozesse wegkillt und aktive speicheralloziierende Prozesse einbremst (denn sowas wie "Prozesse, die keinen Speicher freigeben" gibt's unter Windows 3.1 oder System 7 aber nicht in OS X. Prozesse haben nix zu sagen, der Kernel ist Chef und dreht ihnen bei Bedarf den Saft ab).

Ändert aber nix daran, dass es irgendwie schräg ist, den Beweis führen zu wollen, eine Kiste, die eh nie das swappen anfangen würde, liefe besser, weil man Swapping deaktiviert habe. Wäre interessant, die Ausgabe von zu bekommen, falls Tersteegens Mac 10.9 fährt und zwischenzeitlich nicht neu gebootet wurde (warum siehe Link oben)

Jede Speicheranforderung muß von einer Applikation überprüft werden, weil das OS einen Nullzeiger zurückliefern kann. Seitdem es Memory Overcommitment gibt, wird die Speicheranforderung sofort bestätigt und nicht mehr überprüft, ob das System ausreichend VM zur Verfügung stellen kann. Aus diesem Grund wird erst beim Zugriff auf Speicherseiten geprüft, ob diese physikalisch angelegt werden können. Allerdings sollte in so einer Situation niemals ein OS einfrieren, das ist Sch****. Ferner sollten nicht wahllos Prozesse gekillt werden, sondern der Verursacher dessen Speicheranforderung Probleme hervorrief. Das ist seit vielen Jahren Standard für POSIX Systeme - nur OSX hielt sich nicht dran. Sterben in Schönheit wurde halt bevorzugt.

Es sei an dieser Stelle daran erinnert, daß es in der Vergangenheit Exploits gab, die out of Swap Situationen eines POSIXs Systemen gezielt erzeugt haben, um dann z.B. eine Rootshell zu bekommen. Daher setzt man überlicherweise auf anderen UNICES ulimits, damit eine Applikation das nicht mehr machen kann. Etwas weniger Naivität bei OSX Anwendern und Admins wäre wünschenswert.
"Vergißt" der Programmierer das free weiß auch OSX nicht wie es den Speicher freigegeben kann. Es kann nur komplette Prozesse aus dem System entfernen und dessen Speicehr freigegeben.

Hä? Das ist doch seit 10.4 Sache des launchd, der entsprechende "ResourceLimits" entsprechend vererbt, wenn man sie nicht selbst für Dienste/Programme justiert, siehe ?

Ja und? Deshalb wird purge auch nicht sinnvoller, denn das hat nichts mit den Speicherressourcen von Programmen/Prozessen zu tun sondern räumt den Disk-Cache ab, was dann anschl. hübscher aussieht, weil dann mehr bei free und weniger bei inactive steht. Oder worum geht's grad? Mir immer noch darum, dass man mit der Vorstellung, OS X hätte die Speicherverwaltung von Windows 3.1 (dann wäre "viel free" durchaus sinnig) an Bord, nicht wirklich weit kommt...

Gegen Memory Leaks hilft auch kein purge oder etwa doch?

BTW: Als ich mir 10.4 Server angeschaut habe, musste ich ja sehr amüsiert zur Kenntnis nehmen, dass Apples servermgrd an genau dem krankte. Und die "Lösung": Der beendete sich einfach selbst wenn grad keine Clients mittels "Server Admin.app" drauf zugegriffen haben im Vertrauen darauf, gleich im Anschluß vom launchd neugestartet zu werden. Im Log fand sich mehrfach täglich sowas da:

Gegen die eigentliche Ursache nicht, da hast Du recht. Aber gegen die (Folge-)Wirkung, so jedenfalls meine (äußerst widerwillig!) gemachte Erfahrung unter Lion. Besonders, wenn die Speicherverwaltung bzw. die Garbage Collection versagen und nicht richtig aufräumen. Unter Lion zum Beispiel. Dort (und nur dort) war z.B. ich gezwungen, regelmäßiger den purge-Befehl abzusetzen. Um ständiges Swapping bis zum Anschlag, damit einhergehende hohe HD-Last und CPU-Last und damit einhergehende durchdrehende Lüfter wieder zur Raison zu bringen (trotz 4GB RAM, trotz ausreichend Platz auf der HD). So gut wie immer genau dann, wenn im Hintergrund Spotlights mdworker zugange war. Nie vorher gehabt sowas in so einem Extrem. Und auch nie nachher. Und dass die Speicherverwaltung bzw. das Aufräumen im Speicher unter Lion einen Knacks hatte, das dürfte bekannt sein, und darüber ist auch einiges zu lesen gewesen, da häuften sich so einige Beschwerden, das hatte sich dann Gott sei Dank mit Mountain Lion wieder gebessert und ist meinem Empfinden nach unter Mavericks wieder gänzlich verschwunden, Mavericks läuft bei mir sehr rund und zu meiner großen Zufriedenheit.

tja, aber so:

Mmh, apropos Auslastung.

Momentan sind 133 MB frei; 53 MB Swap werden verwendet.