我正在將資料遷移到 LUKS 分割區。現在作業系統磁碟機正在脫離 LUKS 運行，我嘗試開始遷移資料磁碟機。然後伺服器停止回應。
此 LUKS 設備已開啟：
cryptsetup luksOpen /dev/sdc data1
這些命令中的任何一個都會扼殺伺服器：
pv /dev/zero > /dev/mapper/data1
pv /dev/zero > /dev/sdc
不是立即，而是幾秒鐘之內，伺服器就變得慢得無法使用。 I/O 上的所有內容都被封鎖：
root@node51 [~]# ps aux | awk '{if($8~"D"||$8=="STAT"){print $0}}'
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1197 0.0 0.0 0 0 ? D 06:39 0:00 [jbd2/dm-1-8]
root 1687 0.1 0.0 0 0 ? D 11:15 0:12 [kworker/u96:5]
root 13057 2.0 0.0 0 0 ? D 13:10 0:01 [dmcrypt_write]
root 13644 10.9 0.0 7452 784 pts/1 D+ 13:10 0:08 pv /dev/zero
root 14159 0.0 0.0 98256 6836 ? DNs 13:10 0:00 sshd: root [priv]
root 14772 0.0 0.0 29008 92 ? D 13:11 0:00 /usr/sbin/CRON -f
root 14773 0.0 0.0 98256 6748 ? DNs 13:11 0:00 sshd: root [priv]
root 15411 0.0 0.0 98256 6876 ? DNs 13:11 0:00 sshd: root [priv]
root 16009 0.1 0.0 98256 6840 ? DNs 13:11 0:00 sshd: root [priv]
root 16632 0.5 0.0 98256 6892 ? DNs 13:11 0:00 sshd: root [priv]
root 16900 0.0 0.0 5448 356 pts/3 D+ 13:11 0:00 awk {if($8~"D"||$8=="STAT"){print $0}}
root 28553 0.6 0.0 0 0 ? D 12:12 0:21 [txg_sync]
值得注意的是，大約兩秒鐘，pv報告它正在以超過2GiB/s.這既是回寫快取又是髒頁填滿（透過監控發現/proc/meminfo）。
之後，pv記錄了正常的寫入速度，但在回寫快取中200MiB/s仍然領先於 和 之間2GiB。3GiB
由於所有 I/O 阻塞的發生，伺服器平均負載躍升至 10.00 以上。
pv由於需要清空回寫緩存，因此需要一段時間才能中止寫入測試，但在測試中止後，伺服器效能立即恢復正常。
有趣的是，這些命令不會導致伺服器滯後：
# Reads from dm-crypt block device
pv /dev/mapper/data1 > /dev/zero
# Reads from the raw block device
pv /dev/sdc > /dev/zero
# Writes to a control disk of a different model
pv /dev/zero > /dev/sdi
# Reads from a control disk
pv /dev/sdi > /dev/zero
# Writes to a file on a dm-crypt ext4 filesystem on a solid-state drive
pv /dev/zero > /tmp/empty
# Reads from that same solid-state drive
pv /dev/sda > /dev/zero
我有這些問題：
- 為什麼對該資料磁碟的持續順序寫入會使伺服器速度減慢這麼多？
- 在寫入特定的一個或幾個磁碟時，如何避免其他磁碟陷入困境？
- 為什麼這種硬碟會導致效能問題，而其他硬碟卻不會？
我有六個相同型號的磁碟（/dev/sdc、/dev/sdd、/dev/sde、/dev/sdf、/dev/sdg和/dev/sdh）需要加密，它們將來會有順序寫入工作負載，所以我不希望伺服器因這個問題而停止。
附加資訊
要聞速覽
伺服器: 戴爾 PowerEdge T320
核心： Linux node51 4.4.0-22-generic #39-Ubuntu SMP Thu May 5 16:53:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
作業系統: Ubuntu 伺服器 16.04 LTS Xenial Xerus 64 位
有問題的硬碟： 東芝 PH3500U-1I72
我有 6 個這樣的磁碟，所有這些磁碟都處於正常狀態，我測試了其中兩個，發現兩者都出現了伺服器範圍內的 I/O 效能下降。他們在200MiB/s接近開始時閱讀和寫作。
控制（無問題）硬碟： 三星SP1614C
該磁碟的持續寫入速度為50MiB/s.難道是有問題的磁碟太快了？
磁碟控制器： 戴爾 PERC H310
兩個固態硬碟和六個有問題的硬碟連接到該控制器，所有這些都直接作為 AHCI 傳遞。控制盤連接至主機板內建的SATA連接埠。
I/O 調度程序
root@node51 [/tmp]# tail -n +1 /sys/block/sd*/queue/scheduler
==> /sys/block/sda/queue/scheduler <==
noop [deadline] cfq
==> /sys/block/sdb/queue/scheduler <==
noop [deadline] cfq
==> /sys/block/sdc/queue/scheduler <==
[noop] deadline cfq
==> /sys/block/sdd/queue/scheduler <==
[noop] deadline cfq
==> /sys/block/sde/queue/scheduler <==
[noop] deadline cfq
==> /sys/block/sdf/queue/scheduler <==
[noop] deadline cfq
==> /sys/block/sdg/queue/scheduler <==
[noop] deadline cfq
==> /sys/block/sdh/queue/scheduler <==
[noop] deadline cfq
==> /sys/block/sdi/queue/scheduler <==
noop [deadline] cfq
將調度程序從/dev/sdcfrom更改noop為deadline不會產生明顯的差異。將調度程序更改為 似乎cfq在一定程度上減少了延遲，但其他磁碟上的 I/O 操作仍然受到影響。
vm.dirty*核心參數
root@node51 [~]# sysctl -a | grep 'vm.dirty'
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 3000
vm.dirty_ratio = 20
vm.dirty_writeback_centisecs = 500
vm.dirtytime_expire_seconds = 43200
偵測到並記錄緩慢的範例/var/log/syslog
ZFS事務組同步：
May 11 19:28:44 node51 kernel: [ 4080.179688] INFO: task txg_sync:3179 blocked for more than 120 seconds.
May 11 19:28:44 node51 kernel: [ 4080.179905] Tainted: P O 4.4.0-22-generic #39-Ubuntu
May 11 19:28:44 node51 kernel: [ 4080.180110] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
May 11 19:28:44 node51 kernel: [ 4080.180357] txg_sync D ffff88060b68baa8 0 3179 2 0x00000000
May 11 19:28:44 node51 kernel: [ 4080.180362] ffff88060b68baa8 ffff880616a96d00 ffff8806133ea940 ffff880603dc2940
May 11 19:28:44 node51 kernel: [ 4080.180366] ffff88060b68c000 ffff880616ad6d00 7fffffffffffffff ffff88056cb8c508
May 11 19:28:44 node51 kernel: [ 4080.180368] 0000000000000001 ffff88060b68bac0 ffffffff818211f5 0000000000000000
May 11 19:28:44 node51 kernel: [ 4080.180372] Call Trace:
May 11 19:28:44 node51 kernel: [ 4080.180381] [<ffffffff818211f5>] schedule+0x35/0x80
May 11 19:28:44 node51 kernel: [ 4080.180385] [<ffffffff81824315>] schedule_timeout+0x1b5/0x270
May 11 19:28:44 node51 kernel: [ 4080.180390] [<ffffffff810abe52>] ? default_wake_function+0x12/0x20
May 11 19:28:44 node51 kernel: [ 4080.180395] [<ffffffff810c33b2>] ? __wake_up_common+0x52/0x90
May 11 19:28:44 node51 kernel: [ 4080.180398] [<ffffffff81820744>] io_schedule_timeout+0xa4/0x110
May 11 19:28:44 node51 kernel: [ 4080.180412] [<ffffffffc05afbec>] cv_wait_common+0xbc/0x140 [spl]
May 11 19:28:44 node51 kernel: [ 4080.180416] [<ffffffff810c3a70>] ? wake_atomic_t_function+0x60/0x60
May 11 19:28:44 node51 kernel: [ 4080.180423] [<ffffffffc05afcc8>] __cv_wait_io+0x18/0x20 [spl]
May 11 19:28:44 node51 kernel: [ 4080.180487] [<ffffffffc071320e>] zio_wait+0x10e/0x1f0 [zfs]
May 11 19:28:44 node51 kernel: [ 4080.180528] [<ffffffffc069ce66>] dsl_pool_sync+0x2c6/0x430 [zfs]
May 11 19:28:44 node51 kernel: [ 4080.180573] [<ffffffffc06b85b6>] spa_sync+0x366/0xb30 [zfs]
May 11 19:28:44 node51 kernel: [ 4080.180576] [<ffffffff810abe52>] ? default_wake_function+0x12/0x20
May 11 19:28:44 node51 kernel: [ 4080.180623] [<ffffffffc06c9a4a>] txg_sync_thread+0x3ba/0x630 [zfs]
May 11 19:28:44 node51 kernel: [ 4080.180669] [<ffffffffc06c9690>] ? txg_delay+0x180/0x180 [zfs]
May 11 19:28:44 node51 kernel: [ 4080.180676] [<ffffffffc05aae31>] thread_generic_wrapper+0x71/0x80 [spl]
May 11 19:28:44 node51 kernel: [ 4080.180682] [<ffffffffc05aadc0>] ? __thread_exit+0x20/0x20 [spl]
May 11 19:28:44 node51 kernel: [ 4080.180686] [<ffffffff810a0588>] kthread+0xd8/0xf0
May 11 19:28:44 node51 kernel: [ 4080.180688] [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0
May 11 19:28:44 node51 kernel: [ 4080.180692] [<ffffffff8182568f>] ret_from_fork+0x3f/0x70
May 11 19:28:44 node51 kernel: [ 4080.180694] [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0
ext4 日誌：
May 11 20:46:46 node51 kernel: [ 6000.186474] INFO: task jbd2/dm-2-8:1148 blocked for more than 120 seconds.
May 11 20:46:46 node51 kernel: [ 6000.193164] Tainted: P O 4.4.0-22-generic #39-Ubuntu
May 11 20:46:46 node51 kernel: [ 6000.199950] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
May 11 20:46:46 node51 kernel: [ 6000.208323] jbd2/dm-2-8 D ffff88060a6e7c98 0 1148 2 0x00000000
May 11 20:46:46 node51 kernel: [ 6000.208330] ffff88060a6e7c98 0000000000000246 ffff8806133eb700 ffff88060b561b80
May 11 20:46:46 node51 kernel: [ 6000.208333] ffff88060a6e8000 ffff88060aeb68b8 ffff88060a6e7d88 ffff88060a6e7d70
May 11 20:46:46 node51 kernel: [ 6000.208336] ffff88060b561b80 ffff88060a6e7cb0 ffffffff818211f5 ffff8805fd6af900
May 11 20:46:46 node51 kernel: [ 6000.208339] Call Trace:
May 11 20:46:46 node51 kernel: [ 6000.208355] [<ffffffff818211f5>] schedule+0x35/0x80
May 11 20:46:46 node51 kernel: [ 6000.208361] [<ffffffff812ea0e0>] jbd2_journal_commit_transaction+0x240/0x1870
May 11 20:46:46 node51 kernel: [ 6000.208365] [<ffffffff810b6be1>] ? dequeue_entity+0x431/0xa80
May 11 20:46:46 node51 kernel: [ 6000.208368] [<ffffffff810b774a>] ? dequeue_task_fair+0x51a/0x8a0
May 11 20:46:46 node51 kernel: [ 6000.208372] [<ffffffff810c3a70>] ? wake_atomic_t_function+0x60/0x60
May 11 20:46:46 node51 kernel: [ 6000.208378] [<ffffffff810ec5fe>] ? try_to_del_timer_sync+0x5e/0x90
May 11 20:46:46 node51 kernel: [ 6000.208381] [<ffffffff812ef32a>] kjournald2+0xca/0x250
May 11 20:46:46 node51 kernel: [ 6000.208384] [<ffffffff810c3a70>] ? wake_atomic_t_function+0x60/0x60
May 11 20:46:46 node51 kernel: [ 6000.208387] [<ffffffff812ef260>] ? commit_timeout+0x10/0x10
May 11 20:46:46 node51 kernel: [ 6000.208391] [<ffffffff810a0588>] kthread+0xd8/0xf0
May 11 20:46:46 node51 kernel: [ 6000.208394] [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0
May 11 20:46:46 node51 kernel: [ 6000.208397] [<ffffffff8182568f>] ret_from_fork+0x3f/0x70
May 11 20:46:46 node51 kernel: [ 6000.208399] [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0
May 11 20:46:46 node51 kernel: [ 6292.776357] perf interrupt took too long (2539 > 2500), lowering kernel.perf_event_max_sample_rate to 50000
答案1
控制盤連接至主機板內建的SATA連接埠。
如上所述，遇到日誌刷新逾時問題的磁碟連接到 PERC，該控制器與「有問題的」東芝連接到同一控制器。
PERC 310 只是一個基本的硬體 raid 卡。它的 CPU 可能很容易被淹沒，或者是韌體錯誤。直接 AHCI 並不是很常見的用法。
我建議 IO 鎖定在 PERC 上，而不是作業系統上
答案2
這需要消化很多東西。
您使用的是 ZFS，因此這很可能是您池中的 5TB 磁碟以及池設定的問題。
這些可能是 4k 磁區磁碟，因此應在 ZFS 設定中進行一些調整以解決此問題。
您能提供您的df -h、fdisk -l、zpool list和輸出嗎zpool status -v？zfs list
答案3
我認為與區塊設備速度相比，您的寫入快取太大。我建議如下：
vm.dirty_background_bytes = 50000000
vm.dirty_bytes = 200000000
vm.dirty_expire_centisecs = 500
vm.dirty_writeback_centisecs = 20
切勿同時設定兩者*_bytes，*_ratio因為最後設定的將獲勝。此外，某些 Linux 核心版本可能存在設定*_ratio無法如預期運作的錯誤。我建議*_bytes每次都使用。
不幸的是，據我所知，寫入快取設定是全域的。因此，當您由於某些較慢的裝置而需要減少全域寫入快取大小時，較快裝置的吞吐量將會受到一些影響。