RAM-Stresstest

Ich spezifiziere ein neues MacBook Pro und möchte wissen, wie viel Arbeitsspeicher mein Arbeitspensum benötigt. Ich mache meine Entwicklungsarbeit auf einem 2011er iMac mit 16 GB RAM und möchte wissen, ob ich so viel Speicher für mein neues MBP benötige, da RAM nicht aufrüstbar ist.

Ich habe eine 8-GB-RAM-Disk und eine zufällige 7-GB-Datei erstellt, um den Speicherdruck auf meinem Mac zu sehen:

diskutil erasevolume HFS+ 'RAM Disk' `hdiutil attach -nomount ram://16777216`
dd if=/dev/urandom of=temp_7gb bs=1 count=0 seek=7g

Zu meiner Überraschung hatte es fast keine Auswirkungen auf das Speicherdruckdiagramm im Aktivitätsmonitor! Mache ich das richtig? Wie kann ich simulieren, dass mein aktueller Mac nur 8 GB Arbeitsspeicher hat?

Ich wäre vorsichtig, mir 2019 einen Rechner mit „nur 8 GB“ RAM zu kaufen. Während das heute für die meisten Dinge sicher ausreicht, muss man in 2-5 Jahren rechnen. Mit der Bedeutung von schwerem JavaScript auf Websites und jedem, der beschissene Elektron-Apps schreibt, wird RAM eine wertvolle Ressource sein.
@klanomath Es soll eine 7-GB-Datei mit zufälligen Bytes erstellt werden. Ich habe es aus irgendeinem Forum gestohlen, damit es möglicherweise nicht das tut, was ich will
@MikeHenderson: Dieser Befehl überspringt die ersten 7 GB der Datei ( seek=7g) und schreibt dann 0 Blöcke ( count=0) der Größe 1 Oktett ( size=1). Mit anderen Worten: Es wird überhaupt nichts geschrieben. Es wird lediglich eine Sparse-Datei mit einem 7G-Loch am Anfang und ansonsten ohne Inhalt erstellt. Die Gesamtgröße der Datei ist vernachlässigbar (im Grunde nur die Metadaten zur Beschreibung des "Lochs").
Möchten Sie, dass dieses neue MBP Sie ein paar Jahre lang hält? Bleiben Ihre Arbeitslast und Ihre Software für diese Zeit genau gleich? Immer überschätzen
Nur zur Info: MacPerformanceGuide.com : Die Anforderungen und technischen Kompetenz seines professionellen Fotografen fließen in seinen technisch aufschlussreichen, detaillierten Bericht und Kommentar zu Mac-Hardware und -Betriebssystem ein. Ich besuche diese Seite häufig.

Antworten (1)

Terminal öffnen, eingeben:

sudo nvram boot-args="maxmem=8192"

und neu starten. Dadurch wird der Arbeitsspeicher auf 8 GiB begrenzt. Beginnen Sie jetzt, Ihren Mac mit der üblichen Arbeitslast zu verwenden.

Um die vollen 16 GiB-RAM wieder zu aktivieren, geben Sie einfach ein sudo nvram -d boot-argsund starten Sie erneut.

Ihr dd-Befehl wird nicht wie beabsichtigt funktionieren, da die Anzahl der geschriebenen Blöcke 0 ist (count=0) und die Blockgröße 1 Byte (bs=1) wäre. Soweit ich das beurteilen kann, wird im Dateisystemkatalog nur eine "Datei" mit der Größe von 7 GiB erstellt, aber es werden überhaupt keine Daten in die Datei selbst geschrieben. Wenn der Zählwert 1 wäre (count=1), würde 1 Byte Zufallsdaten an die Datei temp_7gb (seek=7g) angehängt.

Das Ziel (of=temp_7gb) ist zweifelhaft. Es erstellt eine Datei im Arbeitsverzeichnis. Sie müssen entweder zuerst in ein Dateisystem auf der RAM-Disk (z. B. cd /Volumes/RAM-Disk/) wechseln, um die Datei dort zu erstellen, oder direkt auf das RAM-Disk-Gerät schreiben (von=/dev/devX).

dd ist ein Tool, das eher Festplatten-I/O misst als CPU-Last/-Geschwindigkeit oder Speicherverbrauch/-druck.

Mit einer cleveren Kombination von dd-Operanden können Sie es immer noch verwenden, um CPU-Last/Speichernutzung zu simulieren.

  1. if=/dev/urandom or if=/dev/zerohängen mit der CPU-Geschwindigkeit zusammen
  2. of=/dev/nulldie Festplatte wird nicht beteiligt sein.
  3. bs=xbestimmt die Speichernutzung (x ist fast proportional zur Speichernutzung)
  4. count=ygibt Ihnen Zeit, Dinge zu testen

Beispiele:

dd if=/dev/urandom of=/dev/null bs=1 count=1000

misst hauptsächlich den Systemaufruf-Overhead (einschließlich aller Spectre / Meltdown-Abschwächungen, die Ihr Kernel verwendet, wodurch Systemaufrufe langsamer werden als früher). Kryptografisch starke Zufallszahlen erfordern ebenfalls erhebliche Berechnungen, aber 1 Systemaufruf pro Byte wird dies dominieren. Der Speicherbedarf ist gering (auf meinem System ca. 400 kB)

dd if=/dev/urandom of=/dev/null bs=1g count=10

misst hauptsächlich die CPU-Geschwindigkeit, da viele Zufallsdaten berechnet werden müssen. Der Speicherbedarf ist hoch (auf meinem System etwa 1 GB). bs=1mwäre ungefähr gleich, würde aber viel weniger Speicher verbrauchen.

dd if=/dev/zero of=/dev/null bs=1g count=10

misst hauptsächlich die Speicherbandbreite (hier ~7 GB/s) für den /dev/zeroTreiber des Kernels, der einen memsetKernel-Speicherplatz in ddden Puffer von einfügt. Der Speicherbedarf ~= Puffergröße, die viel größer ist als alle Caches. (Einige Systeme mit Iris Pro-Grafik verfügen über 128 MB oder 256 MB eDRAM; Tests mit bs=128m vs. bs=512m sollten diesen Unterschied zeigen.)

Der Treiber des Kernels /dev/nullverwirft die Daten wahrscheinlich, ohne sie überhaupt zu lesen, sodass Sie nur die Schreibbandbreite des Speichers messen und nicht abwechselnd schreiben und lesen. (Und der Systemaufruf-Overhead sollte vernachlässigbar sein, wenn nur ein Lese- und Schreibvorgang pro 1 GiB gespeichert wird.)

dd if=/dev/zero of=/dev/null bs=32k count=100000

misst hauptsächlich die CPU-Cache-Schreibbandbreite (hier ~13 GB/s) und den Systemaufruf-Overhead. Die CPU hat nicht viel zu rechnen (Nullen!); der Speicherbedarf ist gering (auf meinem System ca. 470 kB).

Die Größe des L1d-Cache beträgt 32 KB. Sie würden denken, bs=24kes wäre schneller (weil es problemlos in L1d passt, anstatt mehr Räumungen zu haben, weil der Puffer von dd nicht das einzige in L1d ist), aber ein erhöhter Systemaufruf-Overhead pro kopiertem kB könnte es noch schlimmer machen.

Der L2-Cache ist 256 KB groß, der L3-Cache 3 bis 8 MiB. bs=224ksollte ziemlich gute Bandbreite sehen. Sie können ddjeden Kern parallel ausführen und die Bandbreite wird skaliert, da L2-Caches im Gegensatz zu gemeinsam genutztem L3 und DRAM pro Kern privat sind. (Auf Xeon-Systemen mit vielen Kernen sind mehrere Kerne erforderlich, um die verfügbare DRAM-Bandbreite zu sättigen, aber auf einem Desktop/Laptop kann ein Kern ziemlich nahe kommen.)

Der 2011er iMac des OP hat eine CPU mit integriertem Speichercontroller, wie alle x86-CPUs seitdem. Die DRAM-Bandbreite ist nicht unbedingt die gleiche wie die Bandbreite zur Southbridge, und das Lesen /dev/zeroin 1-GB-Blöcken bringt den Kernel meistens nur dazu, ein großes Memset zu machen. (Und das Ergebnis verwerfen). en.wikipedia.org/wiki/Intel_QuickPath_Interconnect hat ein Diagramm, das zeigt, dass QPI für System <-> DRAM oder CPU ist, nicht für CPU <-> DRAM.
Und übrigens, bs=32kEngpässe beim Systemaufruf-Overhead sowie die minimalen Kosten eines 32-kB-Memsets. Mit der Minderung von Spectre + Meltdown ist der Overhead für Systemaufrufe erheblich höher. 13 GB/s sind lächerlich niedrig für Cache-Write-S/W auf einem Kern. Obwohl die L1d-Größe = 32 KB beträgt, wird ddder Durchsatz wahrscheinlich sinken, wenn Sie ihn auf 24 KB verkleinern, sodass Sie mit größerer Wahrscheinlichkeit alle L1d-Treffer erhalten, keine Räumungen. Oder gehen Sie nach oben, wenn Sie es vergrößern bs=224k(knapp unter der L2-Größe von 256 KB). Dies sind die Cache-Größen von Intel seit Nehalem.
@PeterCordes :-) Beim Schreiben des dd-Nachtrags war mir klar, dass einige Einschätzungen vielleicht gewagt sind . Bevor ich es an die Antwort anhängte, habe ich tatsächlich den verlinkten Wikipedia-Artikel besucht, weil ich nicht wirklich wusste, wie moderne CPUs mit dem Hauptspeicher verbunden sind (ich wusste: kein FSB + NB mehr). Am wichtigsten – ich hatte es auf der Zunge, aber ich brauchte jemanden, der es erwähnte – sind die Worte system-call overhead . Ich werde versuchen, die Antwort zu verbessern - Sie können dasselbe tun (mit mehr Fachwissen als ich).
Alles klar, Änderungsvorschlag hinzugefügt. Ich habe goldene Abzeichen in [Performance], [x86-64] und [CPU-Architektur] drüben auf Stack Overflow, also können Sie sich wahrscheinlich auf mich verlassen :)
@PeterCordes In Anbetracht der Gewichtung zwischen der Boot-Args-Antwort (4%) und der DD-Exkursion (96%) (das Ergebnis eines schlampigen Forumsartikels: Mike Hendersons Kommentar: ... Ich habe es aus einem Forum gestohlen, also kann es nicht sein mach was ich will ), wir müssen die Frage jetzt abändern ;-)
xD. Ja, das ist ein bisschen ein Nebengleis. Und hat wirklich nichts damit zu tun, Speicher vom Betriebssystem zu stehlen. Vielleicht sollte es einfach entfernt werden, wenn es eine ähnliche Antwort auf unix.SE oder so gibt. Das OP hat nur ddeine Datei bekannter Größe auf einer Ramdisk erstellt, ohne zu hoffen, dass dd selbst Speicher belegen würde. (Nicht komprimierbare Daten von urandom besiegen zswap oder was auch immer, wenn MacOS das tut; ich kenne MacOS überhaupt nicht gut) Oh, außer dass sie versucht haben, eine Sparse-Datei zu erstellen. /Gesichtspalme. (Anscheinend unterstützt MacOS das Speichern von Sparse-Dateien auf HFS+, obwohl HFS+ selbst dies nicht tut)
@PeterCordes Ich sollte den Forumsartikel finden und dort den dd-Teil als Kommentar hinzufügen. Der vorgeschlagene dd-Befehl ( dd if=/dev/urandom of=temp_7gb bs=1 count=0 seek=7g) ist nutzlos. Es wird nichts geschrieben (count=0) und das richtige Ziel (entweder cd auf RAM-Disk oder ein gültiges von (of=/dev*X*/)) fehlt.
Ja genau. Es muss count=1eine Sparse-Datei erstellen, damit es nicht einmal das wahrscheinlich nutzlose Ding macht. Es muss überhaupt nicht gesucht werden, um tatsächlich Null zu füllen, wiebs=1m count=$((7*1024))
RAM-Stresstest
AntwortenHierDatenschutz-Bestimmungen1y, 0v