napp-it/OmniOS Performance

esquire1968

Experte
Thread Starter
Mitglied seit
30.03.2015
Beiträge
170
Hi!

Bei mir läuft napp-it als VM auf einem Server mit ESXi 6.7.
16 GB RAM sind der VM zugewiesen.
Als Pool habe ich 6x 4 GB HDD zu einem Raid-Z2 zusammengefasst.
Ein weterer Pool besteht aus 1x 8 GB HDD.
GB Netzwerkverbindung.

Ich habe den Eindruck, dass die Performance nicht optimal ist, habe allerdings im Netz keine Vergleichswerte gefunden.

Ich habe 3 Tests gemacht: ATTO Diskbenchmark und in napp-it izone 1g sowie DD Bench.
Kann mit jemand etwas zu meinen Werten sagen?

Danke vorab.

Thomas
 

Anhänge

  • 2018-12-15_ATTO_storage_LAN.jpg
    2018-12-15_ATTO_storage_LAN.jpg
    120,9 KB · Aufrufe: 141
  • 2018-12-15_Storage_iozone_1g.jpg
    2018-12-15_Storage_iozone_1g.jpg
    81,1 KB · Aufrufe: 92
  • 2018-12-15_Storage_DDbench.jpg
    2018-12-15_Storage_DDbench.jpg
    53,6 KB · Aufrufe: 82
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Knapp 120 MB/s bereits ab 64KB Blockgröße ist bei einem 1G Netzwerk schlicht perfekt.

Beim Schreiben im Raid-Z kann man je Datenplatte sequentiell bei realer Last ca 80-180 MB/s je Platte rechnen, abhängig von der Größe des Schreibcaches und der Qualität der Platten. Der Schreibcache hat 10% vom RAM also 1,6 GB. Die Schreibrate von 390 MB/s ist also sehr gut bei 4 Datenplatten. Mit mehr RAM käme man noch auf bessere Werte von vielleicht bis 500 MB/s. DD zeigt ähnliches.

Readwerte sind vom RAM Lesecache beeinflußt und Peterchens Mondfahrt.

Interessant wäre noch die Ausgabe des Menüs Pools > Benchmark.
Das kann mehrere Workloads auch mit sync enabled machen. Da sieht man dann was der Pool wirklich kann, also nicht nur sequentiell sondern bei kleinem random io.

Vergleichswerte siehe https://napp-it.org/doc/downloads/optane_slog_pool_performane.pdf
 
Zuletzt bearbeitet:
Hier noch das Ergebnis des Tests.

2018-12-15 23_09_05-Storage __ ZFS appliance.jpg

SYNC ist auf "Standard" gestellt.

pools.jpg
 
napp-it legt zum Test ein eigenes Dateisystem an und setzt da sync selbstständig.

578 MB/s sequentielle Schreibrate ist das was man aus einem Array aus 4 Datenplatten erhoffen darf. 25 MB/s sync Schreibrate, also kleine wahlfreie Schreibaktionen ist das was man bei Platten befürchten muss.

Bei einem SMB Filer nutzt man daher meist kein sync. Wenn das ein VM Datastore ist oder man perfekte Sicherheit braucht (kein Datenverlust des RAM Schreibcaches beim Crash) so könnte man eine Intel Optane ab 800P als Slog nehmen. Die sync Schreibrate kann dann bis 500 MB/s steigen. Ein Optane only Pool schafft sogar 800 MB/s (praktisch 10G Netzperformance)
 
Der Pool besteht aus 6 Platten! Nehme an, das ändert nichts.

Wenn ich richtig verstehe, ist die Empfehlung SYNC auf disabled zu stellen! Bei allen 3 Pool (auch rpool)?

pools.jpg
 
Für eine erste Performancebetrachtung zählen nur die Datenplatten.
Wenn man von einem Raid-0 aus 4 Platten ausgeht und eine 5te für Raid-Z1 oder zwei für Raid-Z2 hinzufügt, so werden die nur genutzt um die Redundanzinformationen zu erhalten. Dazu fällt der Rechenaufwand fürs Raid an. Es wird also in jedem Fall langsamer wenn man 6 Platten Z2 mit 4 Platten Raid-0 vergleicht.

ZFS schreibt über den RAM Schreibcache. Das sind bis zu 4 GB Daten die verloren sind wenn es einen Crash beim Schreiben gibt. Wenn man das tolerieren kann, dann kann man sync ausschalten. Wenn nicht dann muss man mit dem Performanceverlust leben oder ein schnelles Slog mit Powerloss Protection einsetzen.
 
Wie oft kommt es zu einem Crash? Da ich eine USV in Betrieb habe sollte das Risiko doch eher gering sein, oder?

Kann ich SYNC im laufenden Betrieb einfach deaktivieren?

Würde als Slog diese Optane passen?
Intel Optane SSD 800P 58GB ab sterreich
 
Zuletzt bearbeitet:
Slog-Größe? Ich rechne (BSD nutzend) so: max. Netzwerk-Datenstrom * max. Sekunden bis zum nächsten ZFS Write-Checkpoint (längstens also default 5sec, kann man aber tunen). Plus etwas Sicherheitsreserve.

Ich hab 10GB-Netzwerk, ESXI-intern geht natürlich je nach CPU mehr. Auf meinem Filer hab ich den Pools daher je eine 25GB-Vdisk als Slog spendiert. Vdisk deshalb, weil in meiner letzten Config die 900p noch nicht durchzureichen ging.
Mit 6.7U1 müsste das ggf. gehen, dann müsste ich aber etwas umkonfigurieren, da ich auf der 900P auch die Storage-VM drauf hab. Und die 900P hat genug "Bumms", um auch virtualisiert als Slog dienen zu können.
 
Ein Slog schützt den RAM-Schreibcache

Der RAM-Schreibcache bei Open-ZFS hat per default 10% RAM, max 4GB. Als Daumenregel sollte das Slog doppelt so groß sein. Ab 8GB ist man also dabei. Bei Solaris rechnet man 10s Schreiben übers Netz. Mit 10G liegt man also ähnlich.

Ich nehme meist 20GB als Slog. Da ist man immer auf der sicheren Seite und kann den Rest optional als L2Arc nehmen. Ansonst sind die Optane ab 800P sehr gut geeignet. 900P und 4800 sind etwas schneller, Der Hauptunterschied liegt in der erlaubten Schreibmenge. Für einen Hochlast-Produktivserver wäre die 800P mit garantierten 365 TB eventuell etas zu klein. Die 4800 ergänzt das dann noch um garantierte Powerloss Protection.

Für ein Lab-System hat man mit der Optane 800-58 in jedem Fall ein fast perfektes Slog
 
Na wir sind ja hier im Herimserver-Bereich, ich selber hab einen DELL T20.

Dann benötige ich noch eine entsprechende PCIe-Adapterkarte (gibts hier empfehlungen?) und das einzige was noch zu beachten wäre, ist dann wahrscheinlich, dass ich den oberen PCIe-Port dafür verwende, weil der untere nur x4 kann.

Also werd ich mir zu Weihnachten eine Optane 800-58 schenken :-)
 
Die Optane 800P ist PCIe 3.0 x2
PCI-e -> M.2 Adapterkarte ist unkritisch.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh