Interessant, Swap obwohl 16 GB RAM

Dann weißt Du es offenbar besser als dieser Verantwortliche von Apple selbst, und er redet Unsinn und Du Sinn. Fragt sich dann nur, warum er bei Apple in der Position ist in der er ist und Du nicht an seiner statt.

ca:

Inwieweit? Wenn ein Apple-Verantwortlicher (Java-Verantwortlicher bei Apple) wie Mike Swingler sagt: "Beachte das nicht, das ist ein Relikt aus vergangener Zeit, ist in der Neuzeit wirkungs- und bedeutungslos" und Apple dazu sogar offizielle und über die Jahre und Betriebssystemversionen hinweg inhaltlich verlängerte Support-Dokumente herausbringt wie z.B. dieses hier

Apple Support Dokument TS1448: Mac OS X: Meldungen des Festplatten-Dienstprogramms zum Reparieren der Zugriffsrechte des Volumes, die Sie einfach ignorieren können

die im Prinzip dasselbe sagen, dann wird da wohl Einiges dran sein, und das wird sich einer wie Mike Swingler, der es eigentlich wissen sollte, wohl nicht einfach so aus den Fingern gesogen haben – subjektives Empfinden eines außenstehenden Laien wie music-anderson zum Trotz.

P.S.:
Ich bemerke grad', dass ca seinen Beitrag, auf den ich mich grad' bezogen hat, waährend ich diesen hier geschrieben habe, zurückgezogen hat. Ich lasse diese Replik trotzdem stehen, da es offenbar notwendig scheint, meinen vorangegangenen Beitrag zu begründen bzw. zu erläutern.

Bzgl. 1st-Level-Support: Es ist dessen Aufgabe, Anfragende erstmal "das Offensichtliche" erledigen zu lassen, was minimalen Aufwand auf Supporter- und beliebigen Aufwand auf User-Seite erzeugt (das ist definitionsgemäß halt nunmal die Aufgabe von 1st-Level-Support, um die 2nd-Level-Leute, die dann auch Ahnung im Detail haben, für Probleme, die sich durch "Voodoo" nicht lösen lassen, zu schonen). Zudem sind 1st-Level-Supporter auch nur Menschen.

Es ist letztlich eine Frage des Wissens und der Methodik. Wenn man weiß, was "PRAM zappen" heutztage nur noch bewirken kann (siehe johns Auflistung der 4 verbleibenden Sachen: Es löscht Lautstärkeeinstellungen und das voreingestelte Startvolume. Schon Bildschirmauflösungs ist irrelevant weil seit 'zig Jahren in den "ByHost"-Prefs abgelegt und das Löschen eines panic.logs ist einfach nur dämlich), dann weiß man in welcher Situation es einzig und alleine hilfreich sein kann: Boot-Probleme. Und da kann es nur einen klitzekleinen Teil der möglichen Ursachen angehen, weshalb es nur in ganz speziellen Situationen überhaupt in der Situation hilfreich sein könnte. Und deshalb wird es auch nur als ein klitzekleiner Baustein der sinnvollen Schritte in so einem Szenarium genannt: . D.h. blind "PRAM zappen" ist immer dümmer als zielgerichtetes Vorgehen bei Boot-Problemen anhand der Checkliste bei Apple (die man übrigens simpel durch googlen nach "apple boot problem" findet -- und das aus gutem Grund!)

Den bescheuerten Ruf, PRAM-Gezappel hülfe magischerweise bei egal welchem Softwareproblem, schlechtem Wetter und sogar Pickeln und Mitessern, wird es trotzdem nicht los. Weil Leute, die das vor 20 Jahren (als die Chancen noch besser standen, damit irgendwas "zu richten") mal als Holzhammer-Methode "gelernt" haben, nicht müde werden, diesen Quatsch immer und immer wieder als Heilbringer zu propagieren.

Und das trifft identisch auch auf "Rechte Reparieren" zu. Es gab historisch bedingt zwei reale Gründe, warum das mal notwendig war: Dual-Boot mit MacOS 9 und Apples in der Anfangszeit bescheuertes PackageMaker-Framework, das in Zusammenarbeit mit unansachtsamen Entwicklern dafür sorgen konnte, dass nach Installation irgendwelcher Software, die Apples .pkg-Format nutzte, Eigentümerschaften/Berechtigungen von Systemverzeichnissen nicht mehr stimmten.

Beide Ursachen sind heute nicht mehr existent. Berechtigungen und Eigentümerschaften verstellen sich auch nirgends einfach so von selbst. Und das, was dieses "Rechte Reparieren" anrichten kann, ist eh brutal beschränkt (weil es nur ein paar Apple-Installer-Receipts -- das sind "Quittungen", in denen hinterlegt ist, was mit welchen Permissions zum Installationszeitpunkt im System aktiv war -- auswertet und nur das, was da verzeichnet ist, überhaupt anfaßt) und völlig untauglich, beliebige echte Permission-Probleme (die heutzutage gerne mal mit ACLs oder im User-Ordner, wo "Rechte Reparieren" eh nicht hinlangen kann, auftreten) zu lösen. Zudem war's sogar kontraproduktiv, weil "Rechte Reparieren" in Situationen, in denen Apple durch ein Security-Update irgendwo Berechtigungen nachträglich restriktiver setzte, den Security-Fix rückgängig machte.

Kurz: Es ist heutzutage Schwachsinn. Und der einzige Grund, warum sich dieser Schwachsinn hält, sind Foren in denen Leute, die bei irgendwelchen Problemen alle Holzhammer- und Voodoo-Methoden parallel abfeuern (und dann meist noch einen Neustart hinterher, der das eigentliche Problem aus der Welt schafft), am Ende behaupten, es wäre "Rechte Reparieren" gewesen, das ihren Rechner wieder heile gemacht hätte.

Die einzig sinnvolle durch Laien bzw. ohne Problemanalyse durchzuführende Systempflege-Maßnahme, die man gerne auch präventiv einsetzen kann, ist "Sicherer Rechnerstart". Den Mac mit gedrückter -Taste booten, die internen Checks und Aufräumaktionen durchlaufen lassen, wenn man ein konkretes Problem haben sollte, prüfen, ob's im "sicheren Modus" auch auftritt (Apple-Anleitung: ) und am Ende nochmal normal booten.

Yep, und Marcels Aussage bringt es treffend auf den Punkt: "Bitte bloß nicht den Anweisungen in diesem Thread folgen!"

Im Ernst: Das kann konzeptionell nicht funktionieren, OS X geht einfach davon aus, einen größeren virtuellen Adreßraum zu haben als das physisch eingebaute RAM und wenn der mal zur Neige geht und man den dynamic_pager deaktiviert hat, dann friert die Kiste einfach ein und man muß hart neustarten. Will man das verhindern, muß man das machen, was ein Computer viel besser kann: Den Speicher verwalten, also selbst ein Auge drauf haben, wieviel RAM welche Programme wann haben wollen.

Für sowas bin ich zu alt, SSD in den Rechner (gerne in klein und als Fusion-Drive) und fertig. Eine SSD minimiert negative Swapping-Effekte durch die um Welten schnelleren wahlfreien Zugriffe nahezu völlig und selbst Adobe-Monolithen, die auf HD-basierten Systemen mit zu wenig RAM bei Programmwechseln für 30-60 Sekunden "SAT1-Ball" sorgen, machen keinen Ärger mehr. Und man hat die Gewißheit, dass auch mal ein Programm amoklaufen kann (RAM alloziieren wie nix Gutes) und nichts passiert. Dem Anscheinsbeweis "Bei mir ist das immer gutgegangen", kann ich nach inzwischen jahrzehntelanger Supporterfahrung leider eh nichts mehr abgewinnen

Ich kann einem Bekannten auch nie ausreden, die Finger solche Placebo-Tools zu lassen. Der guckt sich dann auch immer irgendwelche Anzeigen an, von denen er das meiste nicht wirklich versteht. Er meint dann oft: "Aber danach wars wieder besser". Ich frage ihn dann immer wie seine Testreiehe aussieht. Und für wieviele Stunden dieser "Effekt" anhält.

Meine Devise für sowas: Nicht dauernd auf "nutzlose" Zahlen starren, sondern den Rechner einfach benutzen. Let the machine do ist!

Und wenn wenn wirklich ein Problem vorhanden ist, dieses dann im Einzelfall analysieren, statt zu stochern.

Naja, ich habe im Laufe der Jahre sehr viele *I*X Systeme genutzt, OSX ist in Bezug auf die virtuelle Speicherverwaltung das eindeutig schlechteste System. Wenn der physikalische Speicher unter OSX knapp wird, hakelt das System. Und genau dieses Verhalten kenne ich von den anderen *I*X Systemen eben nicht, da ist nur die Applikation betroffen, bis sie wieder im Speicher ist. Solaris lief da bisher am rundesten, solange man ausreichend Swap hatte, merkte man faktisch nichts.

Apple sollte endlich das Problem lösen und nicht schon wieder Gimmicks wie ein neues OSX Design einführen.

Also bei den Sparc Stations an denen ich früher gearbeitet habe konnte man beim Neuzeichnen der Fenster unter OpenWindows in Zeitlupe zuschauen, wenn die Maschine unter extremer Speicherlast stand. Von "faktisch nichts" konnte da keine Rede sein.
Das Ganze System hatte damals eine gewisse Grund-Trägheit, die ich unter OS X so nicht kenne - auch nicht, wenn die Wanne voll ist.

Zur Memory Clean Diskussion: Ich glaube (Ahnung habe ich keine), dass das nicht wirklich was bringt, gerade nach dem Thread hier.
Allerdings muss ich (nach rein subjektiver Einschätzung) sagen, dass (auch unter 10.9) bei sehr geringem RAM von 4GB er durchaus hilfreich sein kann, nämlich wenn ich alle Standard Programme offen habe (Safari, Mail, iTunes, ...) und dann InDesign öffnen will. Dann muss ich die anderen eh schließen, sonst ist vernünftiges arbeiten nicht drin. Und wenn ich drei Stunden in InDesign arbeiten will, bringt mir auch Safari im InactiveRAM nichts (habe durchaus verstanden, was der macht). Natürlich dauert das Starten der Programme nachher etwas länger, das Starten von InDesign geht nach schließen UND MemoryClean aber wesentlich schneller als ohne letzteres (subjektiv). Die Arbeit damit auch.

Natürlich würde die Speicherverwaltung den InactiveRAM mit der Zeit "löschen" und für ActiveRAM zur Verfügung stellen, aber warum diesen Effekt nicht von Anfang an nutzen?


Wer ausreichend Speicher hat, dem bringt das sicherlich nichts. Wer aber nur zwischen Programm A und B wählen kann, kann die Abläufe mMn schneller gestalten.

Ich kenne es noch im Multiuser Betrieb unter Solaris 8 mit diversen SUN Rays auf einer Ultra E420 mit 4 CPUs und 4GB RAM. OpenWindows gab es zu diesem Zeitpunkt schon lange nicht mehr.

Also, ich kann ein Erlebnis bestätigen, wo mir ein PRAM / SMC Reset tatsächlich geholfen hat.

Ja und? Ich nicht nur ein- sondern zigmal! Und jetzt?

Nur... was hat ein PRAM-Reset bitte sehr mit einem SMC-Reset zu tun (das sind grundverschiedene Sachen und das eine geht eh nicht, wenn das andere geht, denn PRAM/PMU, NVRAM/SMC)? Also was hast Du jetzt eigentlich gemacht? In jedem Fall schon mal einen Neustart (das ist meist der Vorgang, der das Gros der Software-Zickereien eliminiert) und dann irgendwelche Tastenkombinationen gedrückt.

Und selbst wenn Dein kombinierter PRAM/SMC-Reset irgendwas bewirkt haben sollte... was bitte sehr hat das mit dem zu tun, was Du verkürzt zitiert hast und auf was Du Dich beziehst?

Jede dieser Maßnahmen hat in ganz speziellen Situationen ihre Berechtigung (gehabt). Was leider nur so idiotisch ist, ist dass das als Allheilmittel für alles Mögliche propagiert wird. Interessanterweise ja das PRAM-Zappeln noch mehr als SMC-Reset, obwohl der heuzutage in weit mehr Fällen hilfreich ist.

Mir hat PRAM zappen früher (so vor 15 Jahren) regelmäßig bei Bildschirmproblemen ("schwarzer Bildschirm" nach Monitorwechsel) geholfen und noch früher ab und an bei AppleTalk-Herumgezicke. Beides heutzutage völlig unmöglich, NVRAM-Reset bringt nur noch was bei esoterischen Problemen bzgl. Wahl des Boot-Volumes (wenn irgendwas in der EFI-Firmware klemmt).

Und PMU- (so hieß das bei PowerMacs) bzw. SMC-Reset (SMC seit den Intel-Dingern) hat schon diverse Probleme bzgl. plötzlich abschaltender Macs oder Akkuladeverhalten behoben.

Und? Deswegen ist es trotzdem idiotisch, falls irgendwer in einem Forum nach einem Software-Problem fragt, ihm erstmal das übliche "Hast Du schon PRAM gezappt, Rechte repariert und Hühnerblut bei Vollmond verspritzt?!?!" entgegen geworfen wird. Die Welt wäre ein klein bisschen schöner, wenn stattdessen die sinnvolle Anregung "Schon einen Safe Boot probiert?" käme -- der hilft nämlich wirklich heutzutage und das auch noch quasi präventiv (weil er einen Dateisystemcheck nebst ggf. Reparatur des Startvolumes nebenher durchführt)

Er meint sicherlich eines von beiden, und wenn es ihm geholfen hat, ist es doch gut.

Ich bezog mich auf deine Aussage, dass PRAM/SMC Reset nur Hokuspokus sein soll, was nicht stimmt.

Und ja, ein Allheilmittel ist es definitiv nicht. Als jemand, der das Apple Support Team schon fast auswendig kennt, weiß ich das

Übrigens, Auslagerungen im Sinne von "Verwendeter Swap" ist prinzipiell nichts Schlechtes:

Quelle:

Ok, Threadende erreicht. Ich fragte, ob Du nun PRAM-/NVRAM- oder SMC-Reset gemacht hast (das eine hat nichts aber auch gar nichts mit dem anderen zu tun, denn Ersteres löscht heutzutage überwiegend irrelevante Sachen in nicht-flüchtigem RAM und das Letztere setzt einen Controller, der unterhalb des Betriebsystems agiert, zurück). Was kommt: Keine Antwort.

Von SMC-Reset schrieb ich vorher nirgends und auch nichts von Hokuspokus -- ganz im Gegenteil mehrfach erläutert, was welcher Affengriff genau tut. Und dass es genau deshalb einfach ein totaler Schwachsinn ist, bei egal welchem Problem, das man mit dem Mac hat, sofort nach "PRAM-Reset" zu rufen. Weil der heutzutage nur noch in extrem seltenen "Kiste will nicht vom richtigen Volume starten"-Situationen überhaupt irgendeine Wirkung zeigt.

Aber egal, nach unserer Erfahrung richtet der mit der PRAM-Zappelei einhergehende Neustart normalerweise schon die Probleme, die man dem ach so bösen PRAM zuschreibt (das es wie gesagt seit den Intel-Macs gar nicht mehr gibt -- nur so am Rande wegen der Legendenbildung erwähnt).

Aber dieser Blödsinn wird wohl nie aussterben und Leute, die heute neu zum Mac kommen und nie im Leben irgendwas mit PRAM oder den in der OS X Anfangszeit üblichen regelmäßigen Berechtigungsproblemen zu tun hatten, werden angestachelt durch Forenhalbwissen irgendwann auch bei egal welchem Problem ihr Heil in dem dusseligen Affengriff und ritueller "Rechtereparatur" suchen anstatt auf den viel sinnigeren "Sicheren Systemstart" (Neustart mit gedrückter -Taste) konditioniert zu werden, der seitens Apple die für OS X neu entwickelte und im Gegensatz zum PRAM- und Rechte-Geblödel wirksame Variante von Holzhammer-Systempflege ist.

Danke, Thomas.

(Wir kämpfen im Support und beim Training oft gegen solche Mythen, alte Gewohnheiten und Irrglauben, gegen komische Tools und "ich weiß es besser als die Apple-Entwickler".)

Danke für den Nachtrag. Was man aber bedenken muß, dass unabhängig davon, dass Marcels Ausführungen bzgl. "genutzer Swap ist nix Schlechtes" komplett richtig sind, es aus User-Perspektive darum geht, was man eigentlich sieht. Sprich: Was zeigt einem die Aktivitätsanzeige und was bedeutet es eigentlich.

Und da hat sich mit 10.9 an der Stelle vieles bzw. bzgl. der Anzeige "Swap used" einfach mal eben alles geändert.

Vor 10.9 zeigt die Aktivitätsanzeige da den kumulierten Platz an, den die swapfile-Dateien unterhalb /var/vm belegen (und warum diese Größe irrelevant ist, kann man in Marcels Ausführung, die Du zitiert hast, im Detail nachlesen -- in frühen OS X Versionen wurde das auch immer mehr, erst irgendwann, ich glaub zu 10.3-Zeiten, hat Apple dann eine Art Swap-Bereinigung eingeführt, die den Speicherplatz unterhalb /var/vm auch irgendwann später wieder sinken ließ).

Mit 10.9 ist die Anzeige bzgl. "Swap" in der Aktivitätsanzeige aber was komplett anderes. Nicht mehr der Platz der swapfile-Dateien wird angezeigt sondern offensichtlich der real genutzte Swap-Space, der durch Page-Outs zustande kommt. Ich hab hier jedenfalls auf diversen Systemen physisch mehr als 1 GByte unterhalb /var/vm belegt gesehen (offensichtlich wurde der Platz präventiv "gebunkert" aber in der Aktivitätsanzeige immer korrekterweise nur "0 Byte" weil keine der Kisten swappt -- eben weil 10.9 mit dem RAM viel effizienter umgeht als Vorversionen).

Wie auch immer: Für den normalen User, der den Fehler macht, sich auf Null- oder Halbwissen stützend mit der Speicherverwaltung seines Macs zu beschäftigen (und dann purge&Co. auf den Leim geht), ist vor 10.9 nur relevant, was in Klammern bei "Seitenauslagerungen" auftaucht und ab 10.9 das, was bei Swap steht. Alles andere sollte ignoriert werden, da ohne tieferes Verständnis der Materie nur irreführend.

Keine Ahnung, warum ich immer wieder den Fehler mache, das erklären zu wollen. Vermutlich, um diesen Aberglauben zumindest bei "Meinungsmultiplikatoren" (und das sind Forenschreiberlinge ja nunmal) endlich mal auszurotten.

"PRAM zappen" ging bis zu den ersten mit PCI ausgestatteten PowerMacs. D.h. 1995 mit dem 9500er endete die PRAM-Ära. Ab dem Zeitpunkt gab's die OpenFirmware als Boot-Basis der Macs, gab's das NVRAM und gab's im MacOS komplett andere Routinen, um die vielen Sachen, die vormals im PRAM untergebracht waren, nun in Dateien auf Platte wegzuspeichern.

Mit anderen Worten: PRAM zappen ist seit dem PowerMac 9500 a) Schwachsinn, weil nunmehr bis auf ganz wenige Szenarien nutzlos und b) unmöglich, weil nicht mehr vorhanden, denn startend mit diesem PowerMac-Modell gibt es kein PRAM mehr. Und dass Apple das nun NVRAM und nicht mehr PRAM nannte, hatte seinen guten Grund: Um auch dem rückschrittlichsten Mac-User klarzumachen, dass das eine nichts mit dem anderen zu tun hat. Und trotzdem hält sich 19 Jahre später fröhlich der Aberglaube, dass "PRAM zappen" bei irgendwelchen Software-Problemen helfen würde.

Und dann wird ausgerechnet noch "PRAM zappen" (Ablaufdatum vor 19 Jahren und seit OS X doppelt sinnlos) mit SMC-Reset in einen Topf geworden (den SMC gibt's erst seit 2006 bzw. den Intel-Macs, in den PPC-Maschinen war architekturbedingt was völlig anderes verbaut, konkret bei den ersten Desktop- und allen Mobilmacs 'ne PMU und später bei den Desktops dann 'ne SMU ). Und das, was es eh nicht gibt (PRAM+SMC-Reset) soll dann irgendwas heile gemacht haben?!

Und genau solche unscharfen und durch nichts belegten "Erkenntnisse" nähren dann die magische Wirkung von anachronistischem Quatsch wie PRAM-Lalala und Rechte-Lülülü. Wenn man sich schon scheut, Probleme strukturiert anzugehen -- und das heißt Analyse und wenigstens den Apple-Leitfäden zur Problembehebung folgen anstatt irgendwelche rituellen Handlungen abzufeuern, die sinnlos bis kontraproduktiv sind -- dann wenigstens die einzig wirklich effiziente Holzhammer-Methode nutzen: Sicherer Systemstart, also Neustart mit gedrückter Umschalttaste! Der ist im Gegensatz zu dem anachronistischen Quatsch genau dazu entwickelt worden, aktuelle Mac-Probleme zu beheben.

Nur soviel noch zum Thema: Im Gegensatz zur OpenFirmware werden bei EFI/UEFI eine ganze Reihe von Betriebszuständen direkt ins NVRAM geschrieben. Wenn man Hackintosh Seiten durchliest, findet man Patches für normale PC UEFIs damit diese Mac kompatibel werden. Denn OSX schreibt aktiv Daten während des Betriebs in das NVRAM. Aus diesem Grund erscheint es zumindest theoretisch nicht so ganz unwahrscheinlich, daß ein Bereinigen des NVRAMs durchaus sinnvoll sein kann.

Alle PowerMacs mit OpenFirmware 1.x haben noch ein MacROM und booten über dieses. D.h. sie nutzen natürlich auch das PRAM zum Speichern von Daten. Man kann zwar bei diesen Computer bereits Daten in die OpenFirmware ablegen, das wurde aber bis auf ganze wenige Linux Bootloader grundsätzlich nicht getan. Die OpenFirmware 1.x konnte auch nur direkt XCOFF Binaries laden. Für den unwissenden Anteil der Mitleser, XCOFF ist das Binaryformat von AIX bzw. einiger älterer UNIX System V Systeme und Nachfolger des noch ältere COFF Formats. Mit System V.4 wurde ELF eingeführt, das auch fast alle neuen UNICES einsetzen. Die Ausnahmen sind AIX und OSX. Alle Macs mit OpenFirmware 1.x sind bereits Netzwerk bootfähig über die interne Netzwerkkarte, aber nur über TFTP und XCOFF Binary.

Erst mit der OpenFirmware 2.x gab es ein MacROM auf der Platte. Das betraf also erst die PowerMacs ab dem G3 b/w und MacOS 7.6 oder neuer. Die alten PowerMacs wurden aber weiterhin über das MacROM gebootet, wenn man MacOS 7.6 - 9.1 betrieb. Nur PowerMacs mit OpenFirmware 2.x wurden von Apple unter OSX unterstützt.

Toll, Wasser auf die Mühlen der PRAM-Gezappel-Beschwörer: "Na also! Irgendwas Tolles, das ich gar nicht verstehen will, macht es ja schließlich doch! Es wirkt, es muß wirken!!!"

Apple-Artikel (nochmal im Thread), zu dem, was ein NVRAM-Reset in den letzten 8 Jahren auf den Intel-Macs zurücksetzt :

• Lautstärke des Lautsprechers
• Bildschirmauflösung
• Auswahl des Startvolumes
• Informationen zum letzten Kernel-Fehler, wenn vorhanden

Da findet kein "Bereinigen des NVRAMs" statt, wenn man den Affengriff beim Neustart (und der behebt normalerweise "das Problem", nicht die Tastenkombination) drückt sondern da wird nur Lautstärke, Bildschirmauflösung und Startvolume zurückgesetzt. Und dafür gesorgt, dass nach einer Kernel-Panic kein panic.log nach dem Booten geschrieben werden kann!

Diese vier Sachen, nicht mehr und nicht weniger, bewirkt der Hokuspokus heutzutage noch im Gegensatz zur Prä-OpenFirmware-Ära vor 20 Jahren, als im PRAM relevante Betriebsparameter gespeichert und durch eben jenen Affengriff auch zurückgesetzt werden konnten.

Danke für die Ergänzung. Wie auch immer. Ob PRAM-Zappen nun seit 1995 oder erst seit 1997 Schwachsinn ist, dürfte für die Situation anno 2014 relativ egal sein

Nun, es bewirkt ja schon etwas.
Nebenbei (falls noch nicht erwähnt) sollte man einmal in die Konsole schauen je nach Erfahrung.

Trolling

16GB Ram sind ja nicht sehr viel. Zudem spielts eine Rolle ob er Swap oder nicht?

So siehts bei mir aus:

Wofür soll das eine Rolle spielen? Und wieso sollen 16 GByte "nicht sehr viel" sein? 10.9 ist effizienter bzgl. RAM und nur weil man inzwischen CPUs und Chipsätze in Macs einbaut, die so viel RAM nutzen können wie PCs schon seit Jahren, heißt das ja nicht, dass die Software plötzlich ressourcenhungriger geworden wäre. Das Gegenteil ist eher der Fall abgesehen von "spezieller Software", die nicht genug kriegen kann oder welcher bei der man durch "Skalierung in die Breite" einfach um ein gewisses Maß an physisch vorhandenem RAM nicht drumherumkommt (Virtualisierungslösungen mit entsprechender Anzahl VMs bspw.)

Mit anderen Worten: Du hast mindestens 24 GByte zu viel bei diesem Nutzungsprofil und 8 täten's auch wunderbar.

Ram kostet ja nicht mehr alle Welt, bzw. ist super billig. Also lieber mal etwas mehr. Mavericks liebt viel RAM. Es besteht ja immer noch die Möglichkeit das Mavericks den RAM Komprimiert wird wenn es knapp ist.

Ja. Bei meinem Screenshot habe ich kaum Applikationen offen gehabt. normalerweise sind durch Photoshop und Co locker 24-30GB Ram genutzt. Aber du hast schon recht. mit diesem Screenshot habe ich zu viel Ram.


Aber Alles in Allem: Swap oder nicht Swap, eigentlich kann einem das total egal sein.
Wie mit allem, kann man sich überall ein Problem machen.

Interessanterweise scheinen noch andere Dinge damit zusammenhängen. Mein Sohn hat sich wochenlang mit dem Problem herumgeschlagen, dass sich sein MacBook Pro 2012 nicht mehr automatisch mit dem heimischen WLan verbinden wollte. Nach jedem Ruhezustand oder Ausschalten musste er es manuell verbinden. Nach ausgiebigen Gugl-Recherchen und dem Befolgen der dadurch gefundenen Lösungsvorschläge, die allesamt nichts bewirkten, hat er halt auch noch den PRAM/NVRAM gezappt. Und oh Wunder: Seither ist das Problem gelöst. Bitte erklär mir, warum das nicht mit dem PRAM(NVRAM-Zappen zusammenhängen soll.

das erklärt dir apple gerne selbst:
ich hab den eindruck, dass niemand den kurzen kleinen support-artikel liest, der inzwischen zum mindestens zweiten mal hier schon verlinkt wurde.

Das schriebst Du doch schon selbst: Das ist ein Wunder. Siehe hier die Auflistung von mehr oder weniger Holzhammer-Methoden bzgl. WIFI-Problemen und dann vor allem die Kommentare: Beim einen wirkt dies, beim anderen das, beim nächsten sonstnochwas: .

Bitte nicht übel- oder persönlich nehmen. Aber diese Art "Ferndiagnose" ist völlig sinnlos bzw. hab ich beruflich schon so oft mit "Feuerwehreinsätzen" zu tun gehabt, bei denen das, was einem berichtet wurde, von dem, was wirklich passiert war und noch passiert, abweicht, dass ich ohne Blick auf die jeweilige Kiste aus Prinzip schon nichts mehr glaube.

Wenn mehr RAM in den Rechner geht, warum nicht. Allerdings hört man ja auch immer wieder, heutzutage wäre ein Mac unter 8 GByte RAM nicht mehr benutzbar, was ohne die Programmlandschaft bzw. das Nutzungsprofil zu betrachten, einfach nur Quatsch ist. Wir haben inzwischen hunderte von Client-Macs in Monitoring-Systemen hängen und grad Kisten mit 10.9 kommen auch mit "wenig RAM" (4 GByte bspw.) prima zurecht. Wohlgemerkt subjektiv (User-Meinung) als auch objektiv (Page-Outs sammeln und auswerten).

Bei den Kisten, die tatsächlich regelmäßig das Swappen anfangen, läßt sich der subjektive Leidensdruck grad beim Programmwechsel von Adobeschen Dickschiffen erstaunlich simpel durch "/var/vm auf SSD" auf null drücken. Wo beim Einsatz langsamer HDs noch 30 oder mehr Sekunden das SAT-1-Rädchen drehte, wenn man bspw. von Photoshop zu InDesign wechselte (und dann Photoshop-Speicher per Page-Outs auf Platte und ID-Speicher per Page-Ins ins physische RAM wechselte), so merkt man das Ganze de facto mit SSD nicht mal mehr.

Finde ich unglücklich formuliert, denn das könnte auch suggerieren, dass es viel RAM brauchen würde. Dem ist aber eben gerade nicht so, es kommt viel besser mit weniger zurecht, nutzt andererseits aber auch "überflüssiges" RAM mehr aus (bspw. indem es den Disk-Cache teils absurd groß werden läßt und einfach alles, was seit dem letzten Reboot je auf Platte geschrieben wurde, parallel noch im RAM vorhält, wenn Platz da ist -- toll, wenn man irgendwann wieder drauf zugreift, nutzlos, wenn nicht)

Wobei man der Fairness halber auch noch anmerken muß, dass Apples Support-Dokumente auch nicht immer zu 100% akkurat sind, teils weil veraltet, teils weil "für den DAU" verfaßt (d.h. im Zweifel komplexe Wahrheiten durch simple Wahrheiten ersetzen, die dann gerne auch mal bisserl falsch aber dafür "verständlicher" sind), teils weil's einfach gemenschelt hat und beim Verfassen der Texte geschlampt wurde oder die Flüsterpost-Strecke "Entwicklung Support" zu viel Schwund aufwies.

Sollten bspw. WLAN-Paßwörter auch im NVRAM abgelegt werden, damit nach einem Aufwachen aus dem Ruhezustand ein Einloggen ins WLAN klappt, bevor das Unlocking der Keychain stattgefunden hat (und der Fakt, dass man seit 10.7 aus der Recovery Partition gebootet sich auf einmal im WLAN befindet ohne jemals vorher ein Paßwort eingegeben zu haben, spricht an der Stelle für eine Änderung ), dann kann's natürlich sein, dass ein NVRAM-Zurücksetzen jetzt auch an der Stelle was bewirkt... und Apples Support-Dokument nicht (mehr) stimmt.

Kann aber auch sein, dass ein SMC-Reset bspw. (der im "viel hilft viel"-Modus vielleicht auch gleich noch mit erledigt wurde), ein Flag/Trigger setzt, der dann im nachfolgend gebooteten System auch für einen Reset der SystemConfiguration-Prefs sorgt. Im vorher verlinkten Thread berichteten ja auch User, dass bei ihnen ein SMC-Reset "es" gerichtet habe.

Also, wenn man viele Sachen gleichzeitig ausführen möchte, kann das schnell voll werden. Ich hätte auch nie gedacht, dass von meinen 16 GB RAM momentan 10 GB genutzt werden; wobei 5,99 GB sind gerade inaktiv.

Und beim Rest, wir haben uns verstanden

Ich habe ihn gelesen, Du aber offenbar meinen Beitrag nicht.

Danke. Ungefähr sowas habe ich hinter der schwammigen Formulierung "Zu den im NVRAM bzw. PRAM gespeicherten Daten gehören folgende..." vermutet.

Naja, der Widerspruch steckt ja in der expliziten Erwähnung von "keine Interaktion von NVRAM + Netzwerk-Settings" in Apples Support-Dokument. Ich hab mal aus dem Artikel heraus auf "Nicht hilfreich" geklickst und einen Thread bei Apple eröffnet: . Wird wohl nix bringen, am Ende der Woche werd ich das wohl parallel als Bug-Report in der Sektion "Tech Note/Q&A Problem" abkippen.

Der Witz an der Speicherverwaltung ist ja, dass die dynamisch ist und auf andere Randbedingungen anders reagiert (weniger RAM weniger Disk-Cache, früheres "Recycling" von inactive memory, ab 10.9 früheres Komprimieren der Speicherseiten inaktiver Programme, etc. pp.).

Bei dem, was Du schilderst bzw. laut Screenshot würdest Du bei Deinem Nutzungsprofil und einer SSD mit 4 GByte RAM nicht viel Unterschied merken. Vermutlich nicht mal mit einer HD, so gering wie der Speicherbedarf bei Dir ausfällt. Ich hab in meiner Kiste aktuell nur 8 GByte unter 10.8.5, aktuell 70 GUI-Prozesse (davon 3 x Adobe Creative Suite, 2 Browser mit massig Tabs und VMWare Fusion) und über 230 Prozesse komplett und komme auf sagenhafte 4,15 GByte Page-Outs -- über einen Zeitraum von 21 Tagen, d.h. durchschnittlich pro Tag werden ca. 200 MByte rausgeswappt. Lachhaft.

Das MacBook Pro wird nur neugestartet, wenn's unvermeidlich ist und selbstverständlich werden Programme nie beendet. Wofür hat man ein UNIX unter der Haube, dessen virtueller Speicherverwaltung es letztlich egal ist, ob ein Programm noch auf Datenträger oder schon im RAM ist (bzw. wieder auf Datenträger, weil rausgeswappt)?

Ich glaub nach wie vor, dass die meisten Probleme bzgl. Speicher diejenigen haben, die da irgendwas von Hand optimieren wollen und nicht verstanden haben, dass OS X einen völlig anderen technischen Unterbau wie das olle MacOS hat. Vieles, was damals Pflicht war (Programme beenden, um Speicher freizugeben bspw.) ist heute komplett kontraproduktiv.

So eine in etwa hohe Swap-Auslastung hatte ich auch mal bei meinem weißen MacBook, da habe ich auch gemerkt, dass das MacBook bei dieser großen Swapdatei wirklich ackern musste. Als ich den RAM von 4 auf 8 GB erhöht habe, wurde kein Swap mehr verwendet.

Ach menno, ich dachte, das Thema wäre schon gegessen? Du hast doch selbst Beiträge von Marcel Bresink zitiert, in denen er haarklein erläutert hat, warum das scheißegal ist, was die Aktivitätsanzeige vor 10.9 bzgl. Swap-Nutzung anzeigt.

Vor 10.9 meldet die Aktivitätsanzeige nur, wieviel Platz die swapfiles ungefähr auf dem Datenträger einnehmen:


Aber das sagt nichts aber auch gar nichts darüber aus, wieviel davon aktuell aktiv genutzt wird. Die Dinger belegen Platz, werden in der Aktivitätsanzeige angezeigt und verwirren nur. Weil komplett irrelevant. Einzig spannend vor 10.9: Was in konkreten Situationen in der Klammer bei "Seitenauslagerungen" steht. Nur wenn dort was hochschnellt, findet aktiv Swapping statt. Und nur wenn man immer in solchen Situationen Verzögerungen wahrnimmt, hat man zu wenig RAM. Sonst nicht.

Und alles, was einschließlich 10.8 seitens Aktivitätsanzeige dargeboten wird, ist offensichtlich nur für eins gut: User zu verwirren und zu falschen Schlüssen zu verleiten! Alleine deshalb würde sich ein Update auf 10.9 lohnen. Damit man endlich Leuten andienen kann, in die Aktivitätsanzeige zwengs RAM zu gucken, weil erst ab der Version kein Mist mehr angezeigt wird.

Die angezeigten Werte bei mir sind wunderbar, die 8 GByte reichen sogar trotz permanent Adobe-Krams, Browser satt und virtueller Maschinen. Ich hatte vorher mal 16 GByte drin, was totale Verschwendung war. Da waren regelmäßig mehrere GByte "free". Durchschnittlich 200 MByte Swapping pro Tag sind hervorragend. Wobei die 4,15 GByte Page-Outs vermutlich durch eine Photoshop+Lightroom-Session vor 2 Wochen zustandekamen. Also im Normalfall auch mit 8 GByte kein Geswappe RAM völlig ausreichend, "Verwendeter Swap"-Anzeige in 10.8 und Vorversionen komplett aussagelos.

Ach menno! Wir reden gerade aneinander vorbei.

Ich wollte dir doch nur sagen, dass mein MacBook damals wirklich ausgelagert hat.

Mehr nicht. Ganz rational, komplett emotionslos.

Nur eine kleine reine Info-Ergänzung:

Die Wahrheit ist, Du weißt nicht, was es bewirkt. Apple dokumentiert solche Dinge grundsätzlich nicht. Damit man das heraus bekommt, müßte man sich in die EFI und UEFI Dokumentation einlesen, anschließend gezielt das EFI der Macs debuggen, um überhaupt sehen zu können, was das NVRAM "Reset" bewirkt. Angesichts dieser nahezu vollständigen Unwissenheit, wäre ich an Deiner Stelle etwas zurückhaltender mit den Formulierungen.
Apple hat leider die penetrante Angewohnheit solche Dinge grundsätzlich nicht zu dokumentieren. Man bekommt bestenfalls nur die Spitze des Eisberges in der Apple eigenen Dokumentation zu sehen - mehr nicht.

Ein historisches Beispiel: Wo findet/fand sich bei Apple die OpenFirmware Dokumentation? Es gab nie eine öffentlich zugängliche Dokumentation!

Stimmt schon, ich halte mich a) an Apples Support-Dokumente und b) an das Wissen, dass sich konzeptionell in den letzten 2 Jahrzehnten an der Stelle nahezu alles geändert hat.

Letztlich geht's mir aber nur darum, den grad für Neulinge schädlichen Irrglauben einzudämmen, PRAM-Gezappe wäre ein probates bzw. universelles Hilfsmittel, Mac-Probleme zu lösen. Es hilft in seltenen Situationen aber es ist einfach schlimm, wenn sowas wie hier in diesem Parallelthread geschieht: . Ein mechanisches Problem in der Kopfhörerbuchse. Und was wird reflexartig empfohlen? Das PRAM zurückzusetzen.

Das ist als Allheilmittel einfach nur überkommener Quatsch, der mal eine Grundlage hatte aber eben heute nicht mehr hat. Wieviel schöner für Hilfesuchende wäre es, wenn statt "Rechte reparieren" und dem PRAM-Quatsch sich endlich der um Welten geeignetere Tipp "Sicherer Systemstart" als Universal-Holzhammer-Methode durchsetzen würde bzw. die Leute den Trouble-Shooting-Artikeln bei Apple folgen bzw. diese in Foren verlinkt werden würden.

Ich hab im Freundes- und Bekanntenkreis mittlerweile eine ziemlich hohe Mac-User-Quote. Der simple Deal, sich zwengs Mac-Support an mich wenden zu dürfen ist: "Nach jedem Crash ein Boot mit -Taste, alle paar Monate mal ein Boot mit -Taste und wenn ein echtes Problem auftauchen sollte, dann... erst einmal ein Boot mit -Taste! Wenn's dann immer noch klemmt, meld Dich!". Außer bei echten Problemen bzw. von notorischen Systempflegern, die sich ihr System kaputtoptimieren, hört man von niemand was
Apple hat leider die penetrante Angewohnheit solche Dinge grundsätzlich nicht zu dokumentieren. Man bekommt bestenfalls nur die Spitze des Eisberges in der Apple eigenen Dokumentation zu sehen - mehr nicht.

Ein historisches Beispiel: Wo findet/fand sich bei Apple die OpenFirmware Dokumentation? Es gab nie eine öffentlich zugängliche Dokumentation!
[/quote]

Irgendeine TechNote gab's doch mal... die hier IIRC: . Und auf openfirmware.org fanden sich damals auch Links zu developer.apple.com: . Aber Du hast voll und ganz recht, bzgl. Doku hing und hängt Apple gerne mal hinterher. Am krassesten finde ich ja den Status bzgl. Apples smbx-Server: Keine Doku, kein Logging, nur Apples Aussage "AFP ist tot, lang lebe SMB"

Apropos Doku: Ich hab mir gerade "Mac OS X and iOS Internals: To the Apple's Core" geshoppt und finde sowohl Tools als auch weitere Artikel auf der zugehörigen Website extrem praktisch bzw. recht interessant:

Jaha, weiß ich doch

Aber dazu taugt vor 10.9 die Anzeige bzgl. "Verwendeter Swap" immer noch nullkommanull. Siehe aktueller Screenshot. Ich hatte eben ein kleines amoklaufendes Programm hier, das RAM alloziiert hat, bis der Arzt kam (bzw. ich es abgewürgt habe -- der Screenshot entstand direkt im Anschluß). Während das Progrämmchen lief ist massiv geswappt worden: in ein paar Minuten sind satte 35 GByte weggeswappt worden (Vergleich Seitenauslagerungen vorher/nachher). Dadurch sind noch zwei 1 GByte große swapfiles hinzugekommen. D.h. "Verwendeter Swap" wird ab jetzt bis was-weiß-ich-wann (spätestens bis zum nächsten Neustart) irgendwas über 6 GByte anzeigen. Und das ist völlig irrelevant, denn das Swapping fand vorhin innnerhalb wenigen Minuten statt. Vor 10.9 ist und bleibt eben nur der Wert bzgl. Seitenauslagerungen spannend.

Für die "Memory Clean"-Fraktion sieht der aktuelle Screenshot wahrscheinlich traumschön aus: satte 5,34 GByte free. Derweil ist das das Blödste, was passieren kann weil ich nach wie vor um die 70 Programme am Start habe, die jetzt überwiegend weggeswapped wurden und daher bei einem Programmwechsel erstmal von SSD wieder ins RAM geschubst werden müssen. Hätte ich 'ne lahme HD statt SSD würde ich jetzt in Folge immer wieder echte Hänger erleben können. So sind's zum Glück nur kurze Ruckler.

BTW: In solchen Situationen kann man dann wunderhübsch per vmmap nachgucken, inwieweit das einzelne Programme betrifft, also was/wieviel von denen weggeswappt wurde, bspw. per


(wenn einen denn InDesign interessieren sollte. Alternativ zum Namen des Programms die Prozeß-ID eingeben, die auch in der Aktivitätsanzeige gelistet wird)

@ TK: So siehts bei mir aus wenn ich richtig arbeite:

Nett. Aber immer noch starkes Indiz, dass Du mit der Hälfte an RAM ebenso gut auskommen würdest (nicht, dass das sinnvoll wäre -- eher an Mitleser gerichtet, die sich grad fragen, wie sie überhaupt noch mit einer "Gurke" auskommen sollen, die "nur" 8 GByte RAM verträgt).

Fast 10 GByte File Cache zeigen recht klar, dass Mavericks halt RAM auch mal nutzt. Hättest Du die Hälfte an RAM würde der Disk-Cache deutlich sparsamer ausfallen (und die Auswirkung auf die Performance bei typischen Rechnertätigkeiten wäre trotzdem gleich null). Ich vermute auch mal ganz stark, dass Mavericks bei so viel RAM allen Programmen erlaubt, wirklich jeden Programmbestandteil direkt im RAM zu haben statt Zeugs, das eh nicht gebraucht wird, auf Datenträger zu belassen, was die Normalstrategie ist.

Was ist denn die vom RAM-Verbrauch her fetteste Applikation, die Du grad laufen hast? Wäre spannend, in der "PID"-Spalte mal deren Prozeß-ID abzulesen, dann ganz simpel via Terminal:


abzusetzen (PID natürlich durch die Zahl ersetzen). Ich krieg hier (natürlich nicht vergleichbar weil 10.8.5) bzgl. Safari bspw. Folgendes:


(ganz interessant, was sich mit 10.9 in Situationen geändert hat, wenn das System sehr wenig Speicher zur Verfügung hat: -- im Prinzip nicht für Dich, denn bei Dir ist ja das Gegenteil der Fall )

Hier der aktuelle Stand. Recht hast du... ich hätte lieber das Adobe ihr Photoshop noch etwas besser optimieren würde. Zur Zeit habe ich bei meinen Quad Core Mac Pro meist nicht mehr als 200% CPU Auslastung bei Photoshop CC.

Während Du in Photoshop arbeitest? Bist Du Speedy Gonzales? Meistens wartet doch der Rechner eh nur däumchendrehend auf den Retuscheur?

Aber was Automatisierungen angeht (wir haben einige Photoshop-Fernsteuerungen bei Kunden am Laufen): Da Öffnen/Speichern nicht so wirklich multithreaded sind und leider auch bei vielen anderen Vorgängen die Performance nicht linear zur Anzahl der CPU-Cores skaliert, gehen wir inzwischen wo's geht, dazu über, solche "remote Photoshop-Knechte" zu virtualisieren.

Ein MacPro5,1 ist 'ne recht solide Basis für ESXi/vSphere, darauf kommen dann 10.8er-VMs mit 2 vCPUs und einem Photoshop drinnen. Das Loadbalancing funktioniert Bonjour-basiert (d.h. wenn man Lastspitzen hat, bucht man paar Photoshop-Lizenzen hinzu und fährt ein paar VMs mehr hoch und die werden auch automatisch bedient) und auf dem Weg kann man einen MacPro konstant am Limit betreiben und alle CPU-Cores konstant zwischen 95% und 100% auslasten

Finalmente noch ein Nachtrag zum NVRAM-Thema. Ich hab einen Bug-Report bei Apple abgekippt bzgl. Doku-Korrektur: Radar-ID 16850617: . Mal schauen, bislang war jeder Bug-Report bei Apple mehr oder weniger sinnlos

Leider oder zum Glück kann man nicht alles automatisieren. Dort wos Sinn machen wird das bei uns auch gemacht. Zur Zeit arbeite ich an einem Photoshop File welche eine beträchtliche Grösse von 8.5 GB Grösse hat. Mein Mac (Mac Pro, Mid 2010, 2.8 Ghz Quad mit Radeon 5770, 1024 MB VRAM und 32 GB RAM, Fusiondisk) scheint froh um den vielen Ram zu sein.

Im Vergleich habe ich das gleiche PSB File auf einen neuen iMac (i7, 3.4Ghz, 16GB Ram und 2048 VRAM und Fusion Disk) hat erheblich mehr Mühe mit dem riesen File (Zeit um Filter anzuwenden, File zu öffnen und zu speichern).

Cool wäre jetzt der Vergleich zu einem krassen neuen Mac Pro zu sehen.

Hier die Auslastung mit 1 File im Photoshop geöffnet, jetzt habe ich auch mehr Compressed RAM:

Man merkt es nur leicht das so viel RAM ausgelastet ist.

Wenn ich das richtig in Erinnerung habe, schrieb Marcel Bresink mal, dass Photoshop die OSX Speicherverwaltung umgeht.

And now something completely different:
Erinnert sich noch jemand an RAM-Doubler?
Auch damals gab es schon Diskussionen um RAM.

Wie sollte (zumal unter 10.7 aufwärts) eine Anwendung das machen?

Keine Ahnung.

Hier ist der Originalbeitrag