[Sammelthread] ZFS Stammtisch

[pwnbert]

@pwnbert

• 5400 RPM: ~70–90 IOPS
• 7200 RPM: ~80–120 IOPS
• Enterprise (15k SAS): ~150–250 IOPS (Maximum)

Die 700-800 IPOS per Raid z.B:
Reads: Acht HDDs × 100 IOPS = ~800 IOPS

Das ist mir zu ungenau.
Ich poste die Screens nochmal hier rein.

WD Extern:

MG10 22tb:

Man sieht, dass die RND4k Q32T1 stark kleiner sind - meine Frage ist, ob das egal ist, oder ob das stört bzw. WANN das stört.

Sequentiell ist wohl gleich, RND4k Q1T1 ist auch gleich.
128k (für ZFS Standard) müsste ich noch testen, kann man bei CDM imho einstellen.

SVDEV (M.2) hätte ich allerdings in dem VDEV (als Smallblock <64 und Metadata) - würde die M.2 theoretisch die ganzen RND4k "abfangen"?

 

[gea]

Wie sagte mein Messtechnik Prof:
Wer misst, misst Mist

oder
was ist schneller, ein Fahrrad oder ein Porsche

Antwort: Das Fahrrad ist schneller (im freien Fall vs dem Porsche auf der Straße)

Was ich damit sagen will, ist dass Messergebnisse immer nur für bestimmte Rahmenbedingungen bewertet werden können, meist sogar nur im direkten Vergleich zu anderem Gerät bei gleichen Einstellungen z.B. ssd vs hd, nie absolut. Die iops sagen ja nur output per second. Ist ein output nun ein random Byte, ein random 4K physical Disk Datenblock oder ein ZFS Block in recsize (128K bis 1M). Dadurch ergeben sich bei gleichen iops riesig unterschiedliche Datentransfers.

Wenn man absolute Werte sucht, landet man schnell bei den ca 100 physikalisch möglichen iops bei hd, 1000 bis 10000 bei ssd und >100000 bei NVMe wobei da nur Intel Optane das bei beliebigen Rahmenbedingungen erreichte, normale NVMe können bei steady write oder mixed read/write auch mal viel schlechter sein als eine gute ssd die laut Datenblatt eigentlich viel schlechter sein sollte,

Zu special vdev
Da zählt nur wie groß der ZFS Datenblock in recsize ist im Vergleich zur small blocksize, damit der Block auf hd statt ssd landet, hat nichts mit iops oder Testeinstellungen in Chrystal zu tun sondern da zählt nur die physikalische Datenstruktur.

Ansonst
Die Erfahrung lehrt, dass man schon 30% und mehr braucht, damit man eine schnellere IT Technik als solche "spürt". Etwas schneller ist ok wenn es nicht viel mehr kostet, sonst nicht.

 

[pwnbert]

Wie sagte mein Messtechnik Prof:
Wer misst, misst Mist

Nene, ich denke nicht, dass das Mist ist.

Die WD hat ne Frimware für die Verwendung in externen Festplatten drauf, auch wenn sie genetisch ne Ultrastar ist.
Ich bin mir relativ sicher, dass man hier etwas "eingebremst" hat, aus "politischen" Gründen, um die Platte fürs Datacenter uninteressant zu machen...

Da zählt nur wie groß der ZFS Datenblock in recsize ist im Vergleich zur small blocksize, damit der Block auf hd statt ssd landet, hat nichts mit iops oder Testeinstellungen in Chrystal zu tun sondern da zählt nur die physikalische Datenstruktur.

Nene, es geht darum benchmarken zu können, was in der Realität am ZFS VDEV zählt... wie die Einstellungen fürs Benchmark aussehen sollen, damit das Ergebnis halbwegs aussagekräftig ist.

Die Erfahrung lehrt, dass man schon 30% und mehr braucht, damit man eine schnellere IT Technik als solche "spürt". Etwas schneller ist ok wenn es nicht viel mehr kostet, sonst nicht.

Q32T1 sind aber ~400% bzw. 25%, daher meine Sorge bzw. Frage.

 

[gea]

Kann man nicht ausschließen, solche "Marketinggags" gibt es immer wieder. Ist aber eher unwahrscheinlich, dass man derlei im Alltag merkt. Schließlich steht die externe Platte auch im Wettbewerb mit anderen Desktopplatten nicht nur mit Enterprise Platten.

Die Enterprise Platten haben fast immer eine andere Firmware, sieht man allein schon daran dass die im Verbund mit anderen Platten wegen Vibrationen nicht einbrechen sollen. Bei Desktop Platten kann man die Performance schon durch "Anschreien" verringern.

Die Q Werte von Crystal zeigen zudem eher wie sich die Leistung bei paralleler Verarbeitung in der Warteschlenge ändert. Hier hätte ein unterschiedlich großer Plattencache Auswirkung.

Q1T1 ist der Wert der am Wichtigsten für realworld ist

 

[besterino]

CDM ist generell Mist. Taugt als grobes Schätzeisen, aber mehr auch nicht.

 

[bbott]

@pwnbert
Die max. IOPS bei HDDs ergeben sich im Prinzip aus der Zugriffszeit:
IOPS ≈ 1000 / (Seek + Rotationslatenz)
Bei 7200 rpm sind das grob ~4 ms Latenz (7200 upm) + ~8 ms Seek (Kopf bewegt sich zur Spur) → ~80–120 IOPS realistisch. Alles darüber im Benchmark ist meist Queueing/ Cache.

Q32T1 ist bei HDDs wenig aussagekräftig, weil sie nichts parallel abarbeiten können, relevant ist eigentlich Q1T1. Problematisch wird’s nur bei vielen gleichzeitigen kleinen Zugriffen (VMs, DBs etc.).

Fun Fact:
Die ~100 IOPS gelten für Worst/Full-Disk. Wenn die Daten nur außen liegen (Short Stroking), steigen die IOPS spürbar. Die 3,5er WD VelociRaptor hat das im Prinzip genau so gemacht (kleinere Fläche genutzt (nur äußere Bereich) → kürzere Wege).

 

[pwnbert]

Q32T1 ist bei HDDs wenig aussagekräftig, weil sie nichts parallel abarbeiten können, relevant ist eigentlich Q1T1. Problematisch wird’s nur bei vielen gleichzeitigen kleinen Zugriffen (VMs, DBs etc.).

Aber wie kommt man im Benchmark dann zu diesen unterschiedlichen Werten?

Kann man das nun ignorieren?

Ich hab halt Sorge mir die Performancde vom Pool zu "vergiften" in dem ich langsame HDDs zur guten Ware stecke.

 

[asm@s24]

Ich hab halt Sorge mir die Performancde vom Pool zu "vergiften" in dem ich langsame HDDs zur guten Ware stecke.

M.E. spielt Rost da eh keine Rolle, die Performance kommt von den SSD im special vdev. 🚀
Edit: special vdev & arc.

 

[pwnbert]

M.E. spielt Rost da eh keine Rolle, die Performance kommt von den SSD im special vdev. 🚀

Leider nicht. ATM schwankt mein Schreiben über SMB so bei 300-440, eher selten über 400... bei großen Dateimengen.

 

[asm@s24]

MB/s im 10 GbE? Das hab ich auch meist so. Ist doch ok.
Hab auch schon 700 gesehen im Zusammenhang mit PBS. Allerdings weiß ich grad die Umstände nicht mehr. Es war ein eher künstlicher Test.

Beitrag automatisch zusammengeführt: Heute um 14:05

Schreiben über SMB

SMB ist doch eh problematisch.

 

[bbott]

Aber wie kommt man im Benchmark dann zu diesen unterschiedlichen Werten?

Kann man das nun ignorieren?

Ich hab halt Sorge mir die Performancde vom Pool zu "vergiften" in dem ich langsame HDDs zur guten Ware stecke.

Der Unterscheid kommt daher, das wenn die Daten direkt in der Nebenspur sind schneller Zugreifbar sind, als wenn man den Lesekopf von ganz außen bis zu inneren (oder umgekehrt) den Lesekopf bewegen muss. In deinen Benches lagen die Daten (sehr) nah beieinander. Das ist auch ein Faktor, warum volle HDDs langsamer werden.

Daher hat man in vor SSD Zeiten auch gerne mehr HDDs verbaut und per Patition, die Daten nach außen erzwungen und auf Kapazität verzichtet, wenn eine Anwendung sehr stark auf IO angewesen war.

 

[pwnbert]

Versteh ich eh.
Offenbar liegt hier irgend ne künstliche FW Begrenzung vor, die irgendwie bei vielen parallelen Anfragen (Datacenterkram) bremst, damit die Platte für den Betrieb wohl uninteressant wird?

War mir nur nicht sicher, inwiefern mich das betreffen könnte.. imho is auch Q1T1 wichtig (wobei das eben das SVDEV abfedern sollte) und halt das SEQ...

Grad geschaut, mittlererweile kosten die 20tb HC560 und MG10 knapp 700, total insane, werd die Platten wohl so oder so einbauen.


Ne Idee wie ich mein Pool sinnvoll Benchmarken kann (unter TrueNAS Scale)?
Würde gern nen Vorher-Nachher Vergleich machen irgendwie.