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:
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:
Code:
[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>
Code:
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]
Code:
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
Last edited: