ZFS Auslastung

[TapsTT]

Hallo zusammen,

habe 2 Server im Cluster beide mit ZFS:
4 x SATA im RAID10
2 x SSD ZFS Log
64GB RAM (ca. 25GB durch VMs belegt)
Proxmox ist auf einer extra Platte installiert und aktuell (5.1)

Beim z.B.: starten einer VM oder wenn auf den Servern gearbeitet wird (Terminalserver, wenn Programme gestartet werden) geht der IO delay ziemlich nach oben (manchmal 70%) und Load average geht auch in den 2 stelligen Bereich. Das geht dann auch recht schnell wieder runter.
Die VMs(Windows Server) laufen recht schnell und ohne Probleme.

Sind diese Ausschläge normal bei ZFS?

Vielen Dank.

Gruß
Tobias

 

[wolfgang]

Ja mit Windows Terminal Server schon.
Windows Server sind dafür bekannt viele Disk IO beim starten zu verursachen.
Der Terminal Server macht das noch schlimmer.

Beim erst mal wenn du einen VM startest die noch nie gelaufen ist hast du viele ARC data misses und alles muss von den Platen gelesen werden.
Bei deiner Memory Auslastung wird wahrscheinlich, die nicht mehr heißen Daten auch gleich aus dem ARC geschmissen.
Deswegen kommt es immer wieder zu vielen ARC data misses.

 

[TapsTT]

Vielen Dank für die Rückmeldung.
Wenn das normal ist bin ich beruhigt.

Kann das mit einer Cache Platte verbessert werden oder bringt das eher nichts?
Geschwindigkeitsprobleme gibt es eigentlich keine, die Server laufen alle recht gut.

 

[Denny Fuchs]

Hi,

ich klinke mich hier auch mal mit ein. Wir haben auch einen Server:

• Proxmox pve-manager/5.1-42/724a6cb3 (running kernel: 4.13.13-4-pve)
• Mainboard Supermicro X11SSH
• Broadcom (LSI) 9300-8i
• Supermicro Gehäuse mit SAS Expander
• 8 x WD Red 1TB 5400U/min
• 64GB Ram DDR4 ECC
• Xeon E3-1270 v5 (3.6Ghz)
• Raidz-2 über alle 8 Festplatten

Mein Problem ist ebenfalls, das aus nicht erkennbaren Gründen der Load recht schnell auf ziemliche hohe Werte springt (30>), besonders wenn meine Monitoring Instanz (Icinga2) etwas mehr zu tun hat. Zwar fällt die Load nach ein paar Minuten wieder, nervig ist es aber dennoch, da beim Monitoring dann häufig bei bestimmten Checks in einen Timeout laufen (30sec). Ich hege ebenfalls den Verdacht, dass es etwas mit ZFS zu tun haben könnte und die 8 VMs ihre Daten zu langsam bekommen bzw. schreiben können. Mein zfs_arc sieht so aus:

options zfs zfs_arc_min=6442450944
options zfs zfs_arc_max=12884901888

Wir haben noch einen M2E Slot frei und überlege, dort das SLOG abzulegen.

  pool: rpool
 state: ONLINE
  scan: scrub repaired 0B in 14h14m with 0 errors on Sun Mar 11 14:38:42 2018
config:

	NAME        STATE     READ WRITE CKSUM
	rpool       ONLINE       0     0     0
	  raidz2-0  ONLINE       0     0     0
	    sda2    ONLINE       0     0     0
	    sdb2    ONLINE       0     0     0
	    sdc2    ONLINE       0     0     0
	    sdd2    ONLINE       0     0     0
	    sde2    ONLINE       0     0     0
	    sdf2    ONLINE       0     0     0
	    sdg2    ONLINE       0     0     0
	    sdh2    ONLINE       0     0     0

Mir gehen allmählich die Ideen aus.

cu denny

 

[wolfgang]

Kann das mit einer Cache Platte verbessert werden oder bringt das eher nichts?

Jein, das Problem mit dem Cache ist das er nicht gratis ist.
Du bezahlst ihn mit Speicher, der dir dann als ARC fehlt.
Also du verbrauchst deinen ARC Speicherplatz und must dann immer von der L2ARC (SSD) lesen.
Das kann schneller sein muss aber nicht, das hängt sehr stark vom Anwendungsfall ab.
Bei VM sind immer sehr viel Daten heiße und beim Terminal Server noch mehr.

Wenn du keine Probleme hast würde ich es so lassen oder du probierst es einfach aus.
Kannst ja von deinen ZIL Laufwerk, den Großteil als Cache verwenden.

Hi @Denny Fuchs
Hohe Load ist bei zfs nichts abnormales und auch unproblematisch.
ZFS hat halt viele worker die alle was tun und das machen sie richtig gut ;-)

da beim Monitoring dann häufig bei bestimmten Checks in einen Timeout laufen (30sec).

Was meinst du genau mit Timeout?
Genaue Fehler wären hilfreich.

Klar ist das mit einen RaidZ2 mit 8 Platten (WD Red) keine Rakete ist.
Du hast bei einen solchen System max 500 IOps, was bei mehreren VM schnell nicht mehr reicht.

 

[TapsTT]

Jein, das Problem mit dem Cache ist das er nicht gratis ist.
Du bezahlst ihn mit Speicher, der dir dann als ARC fehlt.
Also du verbrauchst deinen ARC Speicherplatz und must dann immer von der L2ARC (SSD) lesen.
Das kann schneller sein muss aber nicht, das hängt sehr stark vom Anwendungsfall ab.
Bei VM sind immer sehr viel Daten heiße und beim Terminal Server noch mehr.

Wenn du keine Probleme hast würde ich es so lassen oder du probierst es einfach aus.
Kannst ja von deinen ZIL Laufwerk, den Großteil als Cache verwenden.

Wenn ich den Cache mit auf die 256GB ZIL Platten legen möchte bedeutet das folgendes:?
1. ZIL Mirow entfernen
2. Platten partitionieren (ZIL: 50GB, L2ARC: 200GB)
3. ZIL Mirow wieder erstellen auf Partition 1
4. L2ARC auf Partition 2 legen

Vielen Dank.

 

[Denny Fuchs]

Hallo Wolfgang,

ich nutze Icinga2 welcher als Satellite arbeitet. Dieser führt unter anderem SNMP Checks aus. Icinga2 ist so konstruiert, dass wenn ein Check nicht in der Laufzeit n fertig wird, dann wird der Prozess schlicht abgebrochen (kill). Ich habe dieses Phänomen tatsächlich nur auf diesem einen Server, dessen ursprüngliche Aufgabe nur reiner (Syslog) Logserver (daher 8 größere Festplatten) war, aber jetzt noch Instanzen bekommen hat, die an für sich auch nur sehr wenig Last verursachen (Quorum Hosts). Die größte (CPU) Last verursacht die besagte Satelliten Instanz, aber hauptsächlich nur CPU. Im Anhang wäre so ein relativ absurdes Beispiel, bei dem I/O Wait im Schnitt nur wenige Prozent hat, aber dann auch mal auf über 3000% geht. Da sind dann die Spitzen, die die VMs kurz ins stocken geraten lassen und deren LOAD dann ebenfalls sehr schnell sehr hoch geht. Wie gesagt, fängt sich alles, aber sieht eben nicht sehr schön aus, auf dem Dashboard

Daher vermute ich, dass die WD Platten für ein Raidz-2 einfach zu langsam sind und ein SLOG auf einer SSD helfen könnte. Das Problem wäre nur, ich habe wirklich nur einen M.2 Slot und kann daher auch kein Raid dafür erstellen ... obwohl mir nicht ganz so klar ist, ob ich das an der Stelle wirklich brauchen würde. Dumm wäre, wenn die kaputt gehen sollte, ich den Server nicht mehr booten kann.

 

[wolfgang]

Wenn ich den Cache mit auf die 256GB ZIL Platten legen möchte bedeutet das folgendes:?

Genau so kannst du es mal testen.

 

[wolfgang]

Dumm wäre, wenn die kaputt gehen sollte, ich den Server nicht mehr booten kann.

Das ist nie der Fall, da ZFS transaktionell arbeitet und immer einen Konsistenten zustand ist.
Im schlimmsten Fall hast du die Daten im ZIL verloren.
Das mit dem Zil Mirror ist so ne Sache und muss jeder für sich selber entscheiden wie wichtig seine Daten sind.

Das ZIL schreibt nur sync writes bis zu einer gewissen Block Größe, alle anderen writes werden direkt auf die Platten geschrieben.

In deinen Fall kannst du ja mal iostat laufen lassen und sehen ob ein Zil dir was bringen würde.

zpool iostat -r 1

 

[Denny Fuchs]

hi,

was ich beobachten kann, ist:

rpool         sync_read    sync_write    async_read    async_write      scrub   
req_size      ind    agg    ind    agg    ind    agg    ind    agg    ind    agg
----------  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----
512             0      0      0      0      0      0      0      0      0      0
1K              0      0      0      0      0      0      0      0      0      0
2K              0      0      0      0      0      0      0      0      0      0
4K             14      0      0      0      0      0      0      0      0      0
8K              0      0      0      0      0      0      0      0      0      0
16K             0      0     47      0      0      0      0      0      0      0
32K             0      0      0      0      0      0      0      0      0      0
64K             0      0      0      0      0      0      0      0      0      0
128K            0      0      0      0      0      0      0      0      0      0
256K            0      0      0      0      0      0      0      0      0      0
512K            0      0      0      0      0      0      0      0      0      0
1M              0      0      0      0      0      0      0      0      0      0
2M              0      0      0      0      0      0      0      0      0      0
4M              0      0      0      0      0      0      0      0      0      0
8M              0      0      0      0      0      0      0      0      0      0
16M             0      0      0      0      0      0      0      0      0      0
--------------------------------------------------------------------------------

rpool         sync_read    sync_write    async_read    async_write      scrub   
req_size      ind    agg    ind    agg    ind    agg    ind    agg    ind    agg
----------  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----
512             0      0      0      0      0      0      0      0      0      0
1K              0      0      0      0      0      0      0      0      0      0
2K              0      0      0      0      0      0      0      0      0      0
4K              0      0      0      0      0      0      0      0      0      0
8K              0      0      0      0      0      0      0      0      0      0
16K             0      0     31      0      0      0      0      0      0      0
32K             0      0      0      0      0      0      0      0      0      0
64K             0      0      0      0      0      0      0      0      0      0
128K            0      0      0      0      0      0      0      0      0      0
256K            0      0      0      0      0      0      0      0      0      0
512K            0      0      0      0      0      0      0      0      0      0
1M              0      0      0      0      0      0      0      0      0      0
2M              0      0      0      0      0      0      0      0      0      0
4M              0      0      0      0      0      0      0      0      0      0
8M              0      0      0      0      0      0      0      0      0      0
16M             0      0      0      0      0      0      0      0      0      0
--------------------------------------------------------------------------------

Also bei 16K habe ich oft Werte bei sync_write "ind" stehen, während bei allen anderen sowohl "ind" als als "agg" sich die "Waage" halten.