[SOLVED] ZFS zu langsam

[LnxBil]

Hattest du kein Benchmark gemacht mit sync=standard und 128K (also beides PVE Standard)? Das sollte nach deinen Berechnungen wohl den größten Vorteil bringen (wenn man mal extrapoliert).

Mit sync=standard läufts etwas besser. Wie sicher ist denn überhaupt welche Einstellung? Derzeit verwende ich sync=always und Cache writethrough.

disabled = ignoriert O_SYNC aufrufe komplett
standard = O_SYNC wird nach POSIX-Standard abgewickelt
always = wandelt alle IOs in O_SYNC um

Wenn du noch definierst was "sicher" ist kann ich dir sagen was du wissen willst :-D
Wie bei allem. Je sicherer du ein System willst, desto langsamer wird es logischerweise, da alle Caches umgangen werden und der komplette IO-Pfad abgewartet wird. Ich würde auf den Standard von PVE setzten, bei dem sich viele intelligenten Leute überlegt haben, was am besten ist.

 

[Michl]

128K hab ich nicht mehr getestet.

Was ist sicher? Angenommen es wird ne Datei geschrieben und gleichzeitig ein zugehöriger SQL-Eintrag gemacht, dann möchte ich sichergestellt haben, dass entweder beides oder nichts davon geschehen ist.

Mit "Standard" meinst Du dann sync=standard, volblocksize=8K, ashift=12 und in der VM SCSI und no cache?!

 

[LnxBil]

Mit "Standard" meinst Du dann sync=standard, volblocksize=8K, ashift=12 und in der VM SCSI und no cache?!

Du zeigst jetzt mehr Dinge auf einmal auf:
- ashift ist im Pool selbst beim Anlegen des Pools oder bei der PVE Installation und ist nicht änderbar
- volblocksize ist bei PVE standardmäßig auf 8K eingestellt und dem Pool, der PVE selbst initialisiert und gilt pro Volume
- sync=standard ist ZFS standard (somit auch PVE) und wird pro Volume gesetzt
- VM SCSI ist abhängig vom Gast-Betriebssystem
- no cache ist abhängig vom Storage (ZVOL klappt das, da O_SYNC unterstützt ist, bei ZFS Dateisystem klappt es nicht, da dort O_SYNC nicht unterstützt wird) und besagt, dass die Daten ohne Umwege durch den Hostcache direkt auf das Storage geschrieben werden.

Das O_SYNC ist ein Systemaufruf der z.B. eine Datenbank absetzt um einen synchronen Call auszuführen, sodass die Anwendung sicher ist, dass die Daten geschrieben sind wenn das OS sagt, dass sie geschrieben sind. Bei diesem Aufruf wird also sichergestellt, dass die Daten auf das darunterliegende Speichermedium geschrieben werden und es wird abgewartet bis man das OK von "unten" bekommt. Daher ist dieser Aufruf so langsam, aber es wird dadurch sichergestellt, dass die Daten auch wirklich geschrieben sind. Da ein ZFS Dateisystem kein O_SYNC kann (ist nicht implementiert), kann somit nicht gewährleistet werden, dass die Daten wirklich geschrieben sind, da das Betriebssystem ein OK zurückliefert, auch wenn die Daten noch nicht wirklich "weiter unten" geschrieben sind. Daher kommt der große Unterschied in der Geschwindigkeit zu stande, den du bei ZFS Dateisystem vs. ZFS Volume gesehen hast.

 

[Michl]

Also wenn ich das nun richtig verstanden hab, dann kann bei sync=standard die DB synchron schreiben, "wenn diese das möchte". Wie ist das mit meiner, oben beschrieben Datei, funktioniert das auch so ähnlich?

Und sind meine Werte für die Hardware normal, oder müsste mehr drin sein?
...und mit sync=standard und SCSI-Virtio bin ich sicherer unterwegs, als wenn ich ZFS als Dateisystem nutze?

Danke.

 

[LnxBil]

Oh Mist, mir ist gerade ein Fehler aufgefallen: Ersetze in meinem Text überall O_SYNC durch O_DIRECT, denn das ist in ZFS nicht unterstützt. Das Problem reduziert sich dadurch darauf, dass O_DIRECT sich auf den Cache der VM bezieht, der bei "no cache" auf O_DIRECT verlangt und somit nicht auf ZFS Dateisystem funktioniert. Sorry für die Verwirrung.

Generell vielleicht noch: Nur alle O_SYNC calls landen auf dem ZIL, alles andere wird asynchron direkt auf den Pool geschrieben. Wenn du sync=always machst, landet alles zuerst auf dem ZIL und dann auf dem Pool (wird dort also NOCHMAL geschrieben).

Also wenn ich das nun richtig verstanden hab, dann kann bei sync=standard die DB synchron schreiben, "wenn diese das möchte". Wie ist das mit meiner, oben beschrieben Datei, funktioniert das auch so ähnlich?

Wenn du das wirklich möchtest, dann ist die Schreibperformance definitiv nicht schnell und weit unter dem was du hier beschreibst. Du musst "no cache" verwenden, was bei ZFS Dateisystem nicht funktioniert. Du solltest dann auch sämtliche Cache-Mechanismem der Platten (disk-on-cache) deaktivieren, denn bei einem Spannungsverlust auf der SSD hast du keine Ahnung ob das Zeugs geschrieben wurde. Das ist übrigens ein Teil, warum Enterprise SSD besser sind, die kümmern sich um den Fall und entweder puffern die Daten oder schreiben diese doch noch weg, da sich einen eingebauten Kondensator haben, der den Spannungsabfall kompensiert. Auch haben Enterprise SSD meist eine kleinere interne Blockgröße, wodurch das Wearout viel geringer ausfällt. Manche Consumer-SSDs haben eine Blockgröße von bis zu einigen MB, da die Herstellung wohl kostengünstiger ist und das die Leserperformance nicht beeinträchtigt, aber die Schreibperformance und vor allem die Lebensdauert. Wenn man 8K schreibt, im Ende aber mehrere MB geschrieben werden ist schon doof.

Und sind meine Werte für die Hardware normal, oder müsste mehr drin sein?

Ich hab keine Erfahrung mit Prosumer SSD, nur mit Enterprise SSDs und die sind flotter (aber halt auch um ein vielfaches teurer).

...und mit sync=standard und SCSI-Virtio bin ich sicherer unterwegs, als wenn ich ZFS als Dateisystem nutze?

Nochmal: ZFS Dateisystem in PVE hat einen Grund warum man es das nicht standardmäßig gibt, was schon implizieren sollte, dass damit was komisch ist. Ich würde es nicht verwenden, wenn mir meine Dateien wichtig sind und immer auf zvols setzen. Dort hat man feinere Kontrolle (volblocksize) bei der Performance, die auf das Gast-Dateisystem ausgelegt sein muss (Blockgröße im Gast = Vielfacher (inkl 1x) der Blockgröße im Backend). (http://open-zfs.org/wiki/Performance_tuning)

 

[Michl]

Generell vielleicht noch: Nur alle O_SYNC calls landen auf dem ZIL, alles andere wird asynchron direkt auf den Pool geschrieben. Wenn du sync=always machst, landet alles zuerst auf dem ZIL und dann auf dem Pool (wird dort also NOCHMAL geschrieben).

Das ist übrigens ein Teil, warum Enterprise SSD besser sind, die kümmern sich um den Fall und entweder puffern die Daten oder schreiben diese doch noch weg, da sich einen eingebauten Kondensator haben, der den Spannungsabfall kompensiert.

Die Intel 750 hat auch Kondensatoren. Laut einem SLOG-HDD-Benchmark in einem Blog, das ich leider gerade nicht mehr finde, schnitt die 750er besser ab als manche Enterprise-SSDs. Mein Gedanke war eben, dort nur das ZIL draufzupacken und zu erzwingen. Dadurch versprach sich mir Sicherheit und Geschwindigkeit trotz den günstigen Samsung SSDs. Die 90 MB/s sind schon traurig und weit weg von dem, was ich vorher recherchierte.

Nochmal: ZFS Dateisystem in PVE hat einen Grund warum man es das nicht standardmäßig gibt, was schon implizieren sollte, dass damit was komisch ist. Ich würde es nicht verwenden, wenn mir meine Dateien wichtig sind und immer auf zvols setzen.

Gut, das muss man erst mal wissen. Werde ich in Zukunft auch so tun.


Ich kann nun nicht mehr rechtfertigen, einen teueren Controller mit BBU auszubauen, Geld zu investieren damit es viel schlechter läuft, und dann nochmal viel mehr Geld für Enterprise-SSDs zu investieren, mit denen es hoffentlich wieder wie vorher funktioniert. ZFS ist eine eigene Welt.

Auch im Netz finden sich viel zu viele Falschinformationen und unterschiedliche Meinungen. Durch lesen der Dokumentationen weiss ich wie es gemacht wird, aber nicht warum es so oder so besser ist.
Wie gesagt, dass ich mit weniger Geld die Haltbarkeit und Geschwindigkeit von guten Enterprise-SDDs nicht erreiche, war mir schon klar, aber hier geht ja "garnichts".

Ich will dich nun nicht weiter belästigen. Du hast mir schon sehr viel weitergeholfen.
Den Rest werde ich irgendwie noch hinbekommen.

Herzlichen Dank für Deine Zeit!

 

[Michl]

Laut einem SLOG-HDD-Benchmark in einem Blog, das ich leider gerade nicht mehr finde, schnitt die 750er besser ab als manche Enterprise-SSDs.

https://www.sebastien-han.fr/blog/2...-if-your-ssd-is-suitable-as-a-journal-device/

 

[Michl]

root@proxmox:~# fio --filename=/dev/disk/by-id/nvme-INTEL_SSDPEDMW400G4_CVCQ7336000H400AGN-part1 --direct=1 --sync=1 --rw=write --bs=4k --numjobs=1 --iodepth=1 --runtime=60 --time_based --group_reporting --name=journal-test
journal-test: (g=0): rw=write, bs=4K-4K/4K-4K/4K-4K, ioengine=psync, iodepth=1
fio-2.16
Starting 1 process
Jobs: 1 (f=1): [W(1)] [100.0% done] [0KB/372.8MB/0KB /s] [0/95.5K/0 iops] [eta 00m:00s]
journal-test: (groupid=0, jobs=1): err= 0: pid=23357: Sun Dec 17 23:33:16 2017
  write: io=22292MB, bw=380448KB/s, iops=95112, runt= 60001msec
    clat (usec): min=8, max=6143, avg=10.11, stdev=16.93
     lat (usec): min=8, max=6143, avg=10.18, stdev=16.93
    clat percentiles (usec):
     |  1.00th=[    8],  5.00th=[    8], 10.00th=[    9], 20.00th=[    9],
     | 30.00th=[    9], 40.00th=[    9], 50.00th=[    9], 60.00th=[    9],
     | 70.00th=[    9], 80.00th=[   10], 90.00th=[   12], 95.00th=[   18],
     | 99.00th=[   25], 99.50th=[   28], 99.90th=[   36], 99.95th=[   38],
     | 99.99th=[   50]
    lat (usec) : 10=79.71%, 20=17.58%, 50=2.70%, 100=0.01%, 250=0.01%
    lat (usec) : 500=0.01%, 750=0.01%
    lat (msec) : 2=0.01%, 4=0.01%, 10=0.01%
  cpu          : usr=13.97%, sys=11.21%, ctx=5706999, majf=0, minf=9
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=5706816/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
  WRITE: io=22292MB, aggrb=380448KB/s, minb=380448KB/s, maxb=380448KB/s, mint=60001msec, maxt=60001msec

 

[Michl]

Ich habe nun mit dem Intel SSD-Tool die Sektorgröße auf 4K angepasst:

isdct start –intelssd 0 -NVMeFormat LBAformat=3 SecureEraseSetting=0 ProtectionInformation=0 MetaDataSettings=0

sync steht auf "standard":
Nun erreiche ich 346 MB/s write.

Irgendwann vorher hatte ich bei sync=standard keine Aktivität auf dem SLOG. Nun funktioniert es aber. Er schreibt irgendwas drauf und ich hoffe, dass es seine Richtigkeit hat. Weil ansonsten wäre ich mit meinem Latein am Ende.

In der VM steht der Cache auf writethrough, was dann etwa 10 GB/s read aus dem ARC ergibt.
Controller ist SCSI Virtio mit discard enabled.

Wenn die Daten so einigermaßen sicher sind, kann ich damit gut leben.
Und sofern keiner irgendwelche Einwände hat, so ganz unter dem Motto "was hatter jetzt schon wieder gemacht!!?", dann passe ich o.g. Produktivserver auch noch auf diese Einstellungen und ZVOLs an.

Nochmals Danke an alle. Vor allem an LnxBil.

 

[LnxBil]

Ja, so langsam finde ich, dass man einen guten Guide bräuchte, den man basierend auf allen bishrigen Posts mal zu ZFS aufbaut um weitere Fragen in der Zukunft besser zu handeln. Wie du schon gesagt hast, zu ZFS gibt es sehr viele, oft widersprüchlich scheinende Aussagen (man muss hier leider immer zwischen Oracle ZFS auf Solaris, OpenZFS auf OpenSolaris, OpenZFS auf FreeBSD und dann noch OpenZFS on Linux unterscheiden), die einem das Leben nicht wirkich einfacher machen. Ich selbst habe auch jahrelang rumprobiert, bis ich alles so hatte wie es jetzt ist und mit dem ich leben kann - ich kann da deinen Frust bei der ganzen Angelegenheit schon verstehen und nachvollziehen.

Auch wenn mein ZFS hier auf meinen SSDs nicht so schnell ist (reine fio benchmarks) wie ein mittlerweile ausgebautes BBU-Hardware-RAID ist, so würde ich nie wieder auf etwas anderes als ZFS setzen wollen. Die vielen Vorteile bzgl. Snapshots, inkrementelle Backups/Replikation, Konsistenz (z.B. gegen silent data corruption), Kompression, Thin-Provisioning etc. will ich nicht mehr missen.

 

[Michl]

Bei mir sind es bisher 'nur' 3 Monate immer mal wieder probieren. Davon steckt aber auch noch etliche Zeit in den Scripten. Es gibt schlimmeres.

Aber das stimmt schon, wenn man ZFS einmal im Griff hat, tut man sich wesentlich leichter als mit einem klassischen Raidcontroller, und hat mehr Möglichkeiten. Schreiben ist nun zwar etwas langsamer als mit dem Raid, aber dafür macht's beim Lesen der ARC wieder gut

Unterm Strich bin ich nun auch zufrieden.