Proxmox ZFS Performance bricht ein bei "moderater" Schreiblast

[4920441]

Hi,
ich hab hier einen AMD EPYC 7443P 24 Core / 48 Thread Server (256Gbyte ECC RAM) mit einem raidz2 pool bestehend aus 12 x 18 TB WD Ultrastar Platten, sowie zwei nvme Platten für das System.

Der Server ist sehr potent, man kann ihn aber mit moderater IO Last über das interne Plattensystem sehr schnell in die Knie zwingen - zu schnell.

Beispielsweise kann ich von einem HyperV ein SMB Share mounten und die vhdx Images (die sehr groß sind, ca 10-20 TByte each) und qm import das System derartig auslasten, das andere VMs deutlich spürbare Latenzen aufweisen - die Importrate liegt bei ca 400 MByte/s - ist zwar zügig, aber weit entfernt vom Maximum.

U.a. läuft auf dem System auch ein virtualisierter Proxmox Backup Server (für andere Hardware Proxmox instanzen) - Wenn dieser backups wegschreibt brechen die Backups teilweise sogar ab, wenn z.B. parallel ein obiger Import durchgeführt wird.

Währenddessen sieht man im dmesg direkt das typische "hung_task_timeout" , was auf fehlende Schreib-Performance hindeutet.

Vor einigen Jahren gab es mal ein Problem mit den neueren Epyc Prozessoren, mit dem Workaround den Scheduler auf "none" zu setzen.
Inwischen scheint das aber obsolet zu sein

"[Tue Aug 30 10:20:44 2022] The 'zfs_vdev_scheduler' module option is not supported."


Das System ist quasi backup System für andere Proxmox Server und hosted - wie geschrieben - auch den Proxmox backup server.
Höhere HDD IO Last ist daher häufiger der Fall - wenn die Schreibrate und IOPS runtergehen ist das in dem Kontext durchaus tolerabel,
wenn es aber zu einem Kernel-Timeout kommt und dadurch bzw. währendessen sogar die VMs nicht mehr schreiben können und abbrechen ist das nicht gut....

Was könnte man hier noch mal probieren?

Habt vielen Dank für Eure Tipps!

Anbei noch ein paar Details:

[Mon Aug 29 02:10:41 2022]  blkdev_fsync+0x3a/0x70
[Mon Aug 29 02:10:41 2022]  vfs_fsync_range+0x46/0x90
[Mon Aug 29 02:10:41 2022]  io_issue_sqe+0x109c/0x1fb0
[Mon Aug 29 02:10:41 2022]  ? lock_timer_base+0x3b/0xd0
[Mon Aug 29 02:10:41 2022]  io_wq_submit_work+0x6c/0xc0
[Mon Aug 29 02:10:41 2022]  io_worker_handle_work+0x1a7/0x5f0
[Mon Aug 29 02:10:41 2022]  io_wqe_worker+0x2c0/0x360
[Mon Aug 29 02:10:41 2022]  ? finish_task_switch.isra.0+0xa6/0x2a0
[Mon Aug 29 02:10:41 2022]  ? io_worker_handle_work+0x5f0/0x5f0
[Mon Aug 29 02:10:41 2022]  ? io_worker_handle_work+0x5f0/0x5f0
[Mon Aug 29 02:10:41 2022]  ret_from_fork+0x1f/0x30
[Mon Aug 29 02:10:41 2022] RIP: 0033:0x0
[Mon Aug 29 02:10:41 2022] RSP: 002b:0000000000000000 EFLAGS: 00000216 ORIG_RAX: 00000000000001aa
[Mon Aug 29 02:10:41 2022] RAX: 0000000000000000 RBX: 00007f21cf1f1860 RCX: 00007f2402cb59b9
[Mon Aug 29 02:10:41 2022] RDX: 0000000000000000 RSI: 0000000000000003 RDI: 0000000000000010
[Mon Aug 29 02:10:41 2022] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000008
[Mon Aug 29 02:10:41 2022] R10: 0000000000000000 R11: 0000000000000216 R12: 000055a800942f88
[Mon Aug 29 02:10:41 2022] R13: 000055a800943040 R14: 000055a800942f80 R15: 0000000000000001
[Mon Aug 29 02:10:41 2022]  </TASK>
[Mon Aug 29 02:10:41 2022] INFO: task iou-wrk-3562026:3341603 blocked for more than 120 seconds.
[Mon Aug 29 02:10:41 2022]       Tainted: P           O      5.15.39-3-pve #2
[Mon Aug 29 02:10:41 2022] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[Mon Aug 29 02:10:41 2022] task:iou-wrk-3562026 state:D stack:    0 pid:3341603 ppid:     1 flags:0x00004000
[Mon Aug 29 02:10:41 2022] Call Trace:
[Mon Aug 29 02:10:41 2022]  <TASK>
[Mon Aug 29 02:10:41 2022]  __schedule+0x33d/0x1750
[Mon Aug 29 02:10:41 2022]  ? __pagevec_release+0x30/0x70
[Mon Aug 29 02:10:41 2022]  ? __cond_resched+0x1a/0x50
[Mon Aug 29 02:10:41 2022]  ? write_cache_pages+0x24d/0x460
[Mon Aug 29 02:10:41 2022]  ? __set_page_dirty_no_writeback+0x50/0x50
[Mon Aug 29 02:10:41 2022]  schedule+0x4e/0xc0
[Mon Aug 29 02:10:41 2022]  io_schedule+0x46/0x80
[Mon Aug 29 02:10:41 2022]  wait_on_page_bit_common+0x114/0x3e0
[Mon Aug 29 02:10:41 2022]  ? filemap_invalidate_unlock_two+0x50/0x50
[Mon Aug 29 02:10:41 2022]  wait_on_page_bit+0x3f/0x50
[Mon Aug 29 02:10:41 2022]  wait_on_page_writeback+0x26/0x80
[Mon Aug 29 02:10:41 2022]  __filemap_fdatawait_range+0x97/0x120
[Mon Aug 29 02:10:41 2022]  file_write_and_wait_range+0xd3/0xf0
[Mon Aug 29 02:10:41 2022]  blkdev_fsync+0x3a/0x70
[Mon Aug 29 02:10:41 2022]  vfs_fsync_range+0x46/0x90
[Mon Aug 29 02:10:41 2022]  io_issue_sqe+0x109c/0x1fb0
[Mon Aug 29 02:10:41 2022]  ? lock_timer_base+0x3b/0xd0
[Mon Aug 29 02:10:41 2022]  io_wq_submit_work+0x6c/0xc0
[Mon Aug 29 02:10:41 2022]  io_worker_handle_work+0x1a7/0x5f0
[Mon Aug 29 02:10:41 2022]  io_wqe_worker+0x2c0/0x360
[Mon Aug 29 02:10:41 2022]  ? finish_task_switch.isra.0+0xa6/0x2a0
[Mon Aug 29 02:10:41 2022]  ? io_worker_handle_work+0x5f0/0x5f0
[Mon Aug 29 02:10:41 2022]  ? io_worker_handle_work+0x5f0/0x5f0
[Mon Aug 29 02:10:41 2022]  ret_from_fork+0x1f/0x30
[Mon Aug 29 02:10:41 2022] RIP: 0033:0x0
[Mon Aug 29 02:10:41 2022] RSP: 002b:0000000000000000 EFLAGS: 00000212 ORIG_RAX: 00000000000001aa
[Mon Aug 29 02:10:41 2022] RAX: 0000000000000000 RBX: 00007f4fab6f6860 RCX: 00007f500ea419b9
[Mon Aug 29 02:10:41 2022] RDX: 0000000000000000 RSI: 0000000000000003 RDI: 0000000000000010
[Mon Aug 29 02:10:41 2022] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000008
[Mon Aug 29 02:10:41 2022] R10: 0000000000000000 R11: 0000000000000212 R12: 000056470ba615e8
[Mon Aug 29 02:10:41 2022] R13: 000056470ba616a0 R14: 000056470ba615e0 R15: 0000000000000001
[Mon Aug 29 02:10:41 2022]  </TASK>

processor    : 46
vendor_id    : AuthenticAMD
cpu family    : 25
model        : 1
model name    : AMD EPYC 7443P 24-Core Processor
stepping    : 1
microcode    : 0xa001173
cpu MHz        : 2850.000
cache size    : 512 KB
physical id    : 0
siblings    : 48
core id        : 28
cpu cores    : 24
apicid        : 57
initial apicid    : 57
fpu        : yes
fpu_exception    : yes
cpuid level    : 16
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 invpcid_single hw_pstate ssbd mba ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 invpcid cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr rdpru wbnoinvd amd_ppin arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold v_vmsave_vmload vgif v_spec_ctrl umip pku ospke vaes vpclmulqdq rdpid overflow_recov succor smca
bugs        : sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass
bogomips    : 5699.93
TLB size    : 2560 4K pages
clflush size    : 64
cache_alignment    : 64
address sizes    : 48 bits physical, 48 bits virtual
power management: ts ttp tm hwpstate cpb eff_freq_ro [13] [14]

processor    : 47
vendor_id    : AuthenticAMD
cpu family    : 25
model        : 1
model name    : AMD EPYC 7443P 24-Core Processor
stepping    : 1
microcode    : 0xa001173
cpu MHz        : 2850.000
cache size    : 512 KB
physical id    : 0
siblings    : 48
core id        : 29
cpu cores    : 24
apicid        : 59
initial apicid    : 59
fpu        : yes
fpu_exception    : yes
cpuid level    : 16
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 invpcid_single hw_pstate ssbd mba ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 invpcid cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr rdpru wbnoinvd amd_ppin arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold v_vmsave_vmload vgif v_spec_ctrl umip pku ospke vaes vpclmulqdq rdpid overflow_recov succor smca
bugs        : sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass
bogomips    : 5699.93
TLB size    : 2560 4K pages
clflush size    : 64
cache_alignment    : 64
address sizes    : 48 bits physical, 48 bits virtual
power management: ts ttp tm hwpstate cpb eff_freq_ro [13] [14]

zpool status -t
  pool: hddpool
 state: ONLINE
  scan: scrub repaired 0B in 12:53:45 with 0 errors on Tue Aug 30 23:29:36 2022
config:

    NAME                                  STATE     READ WRITE CKSUM
    hddpool                               ONLINE       0     0     0
      raidz2-0                            ONLINE       0     0     0
        ata-WDC_WUH721818ALE6L4_1111111V  ONLINE       0     0     0  (trim unsupported)
        ata-WDC_WUH721818ALE6L4_2222222T  ONLINE       0     0     0  (trim unsupported)
        ata-WDC_WUH721818ALE6L4_3333333T  ONLINE       0     0     0  (trim unsupported)
        ata-WDC_WUH721818ALE6L4_4444444T  ONLINE       0     0     0  (trim unsupported)
        ata-WDC_WUH721818ALE6L4_5555555T  ONLINE       0     0     0  (trim unsupported)
        ata-WDC_WUH721818ALE6L4_6666666T  ONLINE       0     0     0  (trim unsupported)
        ata-WDC_WUH721818ALE6L4_7777777T  ONLINE       0     0     0  (trim unsupported)
        ata-WDC_WUH721818ALE6L4_8888888T  ONLINE       0     0     0  (trim unsupported)
        ata-WDC_WUH721818ALE6L4_9999999C  ONLINE       0     0     0  (trim unsupported)
        ata-WDC_WUH721818ALE6L4_0000000T  ONLINE       0     0     0  (trim unsupported)
        ata-WDC_WUH721818ALE6L4_AAAAAAAV  ONLINE       0     0     0  (trim unsupported)
        ata-WDC_WUH721818ALE6L4_BBBBBBBC  ONLINE       0     0     0  (trim unsupported)

errors: No known data errors

  pool: rpool
 state: ONLINE
  scan: scrub repaired 0B in 00:00:02 with 0 errors on Sun Aug 14 00:24:06 2022
config:

    NAME                                 STATE     READ WRITE CKSUM
    rpool                                ONLINE       0     0     0
      mirror-0                           ONLINE       0     0     0
        nvme-eui.00xxxxxxxxxxxe54-part3  ONLINE       0     0     0  (100% trimmed, completed at Sun 07 Aug 2022 12:24:08 AM CEST)
        nvme-eui.00xxxxxxxxxxxx46-part3  ONLINE       0     0     0  (100% trimmed, completed at Sun 07 Aug 2022 12:24:08 AM CEST)

errors: No known data errors

 

[itNGO]

Drehende Platten mit Beteiligung im ZFS ist immer schnell am Ende.. es gibt dazu bereits einige, sehr lange Threads....

Ähnlich gelagert ZFS, SSD, Spindeln etc... war hier Thema... https://forum.proxmox.com/threads/ständig-windows-vms-mit-kaputtem-filesystem.111640/

Getrennte HBAs für SSD und Spindeln hilft gelegentlich....

 

[Dunuin]

HDDs könnte man gut mit 3 SSDs als Special Metadata Devices im Dreifach-Mirror entlasten. Dann müssten die HDDs wenigstens nur noch die reinen Daten schreiben und keinerlei Metadaten mehr. Da werden die HDDs dann von deutlich weniger IOPS getroffen. Und das hilft im Gegensatz zum SLOG auch bei Async Writes.

 

[Neobin]

Verstehe ich richtig, dass auf dem HDD-ZFS-RaidZ alles drauf läuft?

• VMs
• PBS-Datastore
• Riesige vDisks die importiert werden

mit einem raidz2 pool bestehend aus 12 x 18 TB WD Ultrastar Platten

Damit hast du gerade mal die IOPS von einer einzigen HDD. Also nicht wirklich verwunderlich, dass da nix geht.

Für PBS wird z.B. das empfohlen:

Backup storage:
Use only SSDs, for best results
If HDDs are used: Using a metadata cache is highly recommended, for example, add a ZFS special device mirror.

https://pbs.proxmox.com/docs/system-requirements.html

Für eine bessere Performance wäre zu empfehlen, die HDDs auf ein Raid10 (striped mirrors) umzustellen und ein 3-fach Raid1 Special Device aus Enterprise-NVMes hinzuzufügen. Und ja, das geht natürlich mit einem ordentlichen Platzverlust einher; bringt dir dafür aber, im Falle der 12 Platten und somit 6 striped mirrors, auch direkt mal die 6-fachen IOPS. Plus das Special Device dazu, sollte ein deutlich spürbarer Unterschied sein.

Nichtsdestotrotz würde ich das Storage-Konzept nochmal überdenken, da ich befürchte, dass selbst durch die obenerwähnten Änderungen das HDD-ZFS-Raid immer noch sehr schnell zu gehämmert wird. Also zumindest mal ein Raid1 oder nach Bedarf sogar Raid10 aus Enterprise-NVMes wäre da zumindest für die (System-vDisks der) VMs wohl sehr zu empfehlen, damit die nicht beeinträchtigt werden.

Wie bereits erwähnt wurde, gibt es dazu einige Threads in denen @Dunuin das Ganze auch sehr gut und ausführlich erläutert hat.

 

[4920441]

Verstehe ich richtig, dass auf dem HDD-ZFS-RaidZ alles drauf läuft?

• VMs
• PBS-Datastore
• Riesige vDisks die importiert werden

Korrekt. Wie geschrieben handelt es sich bei den vDisks der vms auch "nur" um Backupserver, die täglich mehrmals unter last gesetzt werden.

Damit hast du gerade mal die IOPS von einer einzigen HDD. Also nicht wirklich verwunderlich, dass da nix geht.

Naja - da bei backups die IOPS aber auch m.M.n vernachlässigbar sind, soillte das dennoch gehen. Es laufen ja keine IOPS intensiven VMs auf dem System - das das so nichts wird, wäre mir auch direkt klar.

Es kommt ja schon zu den Timeouts wenn nur "normal" backup files geschrieben werden - mit der Migration kann man das nur halt forcieren das es viel zu viel wird.

Nichtsdestotrotz würde ich das Storage-Konzept nochmal überdenken, da ich befürchte, dass selbst durch die obenerwähnten Änderungen das HDD-ZFS-Raid immer noch sehr schnell zu gehämmert wird. Also zumindest mal ein Raid1 oder nach Bedarf sogar Raid10 aus Enterprise-NVMes wäre da zumindest für die (System-vDisks der) VMs wohl sehr zu empfehlen, damit die nicht beeinträchtigt werden.

160TByte Enterprise SSDs für ein Backupsystem sind aber, naja.... sehr teuer!

Wie bereits erwähnt wurde, gibt es dazu einige Threads in denen @Dunuin das Ganze auch sehr gut und ausführlich erläutert hat.

Ich lese mir das ganze mal intensiv durch. Vielleicht bringt es ja auch eine Menge, wenn ich Dunuin obigen Tipp erstmal umsetze - das ist auf jeden Fall preislich absolut schnell umzusetzen.



Habt schonmal vielen Dank!

4920441

 

[Neobin]

Wie geschrieben handelt es sich bei den vDisks der vms auch "nur" um Backupserver,

Sorry, das hatte ich so gar nicht realisiert; dachte da laufen noch andere VMs drauf, neben den Backup-VMs.

Vielleicht bringt es ja auch eine Menge, wenn ich Dunuin obigen Tipp erstmal umsetze

Jupp, dann erstmal das testen. Bin gespannt und würde mich über eine Rückmeldung hier freuen.

Sollte aber wirklich auch, wie von @Dunuin geschrieben, ein 3-fach Mirror Special Device sein. (Redundanz des Special Device immer mindestens so hoch, wie die des Haupt-Raids.) Denn wenn dir das Special Device flöten geht, ist auch das Haupt-Raid unbrauchbar!

Auch zu bedenken, dass nur Daten, die nach dem Hinzufügen des Special Device geschrieben werden von diesem profitieren.

 

[Dunuin]

Naja - da bei backups die IOPS aber auch m.M.n vernachlässigbar sind, soillte das dennoch gehen.

160TB datastore bei 2MB pro chunk = 80 Millionen kleine Chunk-Dateien. Mach da ein GC und er will 80 Mio mal Metadaten (atime) lesen + schreiben. Das sind schon ordentlich IO, daher auch die SSD-only Empfehlung. Special Device hilft massiv beim GC, Verify und Co Tasks wird trotzdem ewig dauern, da die neben Metadaten auch alle Daten einmal neu lesen müssen.

Sagen wir mal das wären 120 IOPS weil du bei raidz2 nur die IOPS Performance einer einzelnen HDD hast. Und 160TB an Chunks ergibt grob 160 Mio IO für ein GC. Dann würde der GC über 2 Wochen dauern weil 160.000.000 IO / 120 IOPS = 1.333.333 Sekunden = 15,43 Tage. Also vernachlässigbar würde ich die IOPS da echt nicht nennen.

 

[RolandK]

darüberhinaus ist zfs auf hdd auch deutlich anfälliger für write-performance/timeoute probleme im kontext writes als ssd.

zeigt z.b. dieses ticket:

https://github.com/openzfs/zfs/issues/10110

daher sollte man gerade bei hdd dafür sorgen, daß man den storage performancemässig nicht an den anschlag fährt