我正在将数据迁移到 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
我有六个这样的磁盘，已知它们都是健康的，我测试了其中两个，发现它们都出现了服务器范围的 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/sdc从改为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每次都使用。
不幸的是，据我所知，写入缓存设置是全局的。因此，当你因为某些较慢的设备而需要减少全局写入缓存大小时，较快设备的吞吐量会受到一点影响。