Intereting Posts

如何在不启用sshd rootlogin的情况下使用Dirvish？ RPM：需要设置：somepackage> = 0.5.0和somepackage <0.6.0 check_snmp具有负值的警告和临界阈值 stream水线inputfunction – 写入进度和别名使用https和虚拟主机为nginx设置自定义错误页面通过IPMI或BIOS的电源使用情况还是？用Maildrop拒绝Postfix中不存在的用户 firefox无法将ntlm传递给在Centos 5.1上运行authenntlm的apache2 实用的SAN问题 APCUPSD和Hyper V R2 为什么NOC /指挥中心总是显示CNN或天气频道？ Corosync 2.3.3：无法启用密码编译时难以冻结并重启 ssh错误 – 绑定到端口22失败：地址已经在使用中 VMWare – 容错 – * SMB *解决scheme？

持续的顺序写入导致性能严重下降

我正在将数据迁移到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 。这是写回caching和填充的脏页（通过监视/proc/meminfo ）。

之后， pvlogging了正常的200MiB/s写入速度，但是在写回caching中，它仍然在2GiB和2GiB之间。

由于所有的I / O阻塞正在进行，服务器的负载平均值已经超过了10.00。

由于回写caching需要清空，中止pv写入testing需要一段时间，但在testing中止后，服务器性能恢复正常。

有趣的是，这些命令不会导致服务器滞后：

 # 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

我有这些问题：

为什么持续的顺序写入这个数据磁盘太慢了呢？
写入特定的一个或几个磁盘时，如何避免陷入其他磁盘？
为什么这种硬盘会导致性能问题，但其他硬盘却不行？

我有6个相同型号的磁盘（ /dev/sdc ， /dev/sdd ， /dev/sde ， /dev/sdf ， /dev/sdg和/dev/sdh ）进行encryption，未来，所以我不希望服务器从这个问题上拖延下去。

附加信息

要闻速览

服务器： Dell 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 Server 16.04 LTS Xenial Xerus 64位

有问题的硬盘： 东芝PH3500U – 1I72

我有6个这样的磁盘，都已知是健康的，我testing了其中的两个，并且经历了两个服务器范围内的I / O性能下降。 他们在接近开始的时候以200MiB/s读写。

控制（无 故障 ）硬盘： 三星SP1614C

这个磁盘有50MiB/s的持续写入速度。 难道是有问题的磁盘太快？

磁盘控制器： Dell 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似乎稍微减less了延迟，但其他磁盘上的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

检测到缓慢的示例并logging到`/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: PO 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: PO 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

控制盘连接到主板内置的SATA端口。

如上所述，遇到日志刷新超时问题的磁盘连接到与“有问题”的东芝所连接的PERC相同的控制器。

PERC 310只是一个基本的硬件RAID卡。它的CPU可能很容易被压垮，无论是或有固件的错误。直接AHCI不是一个非常常见的用法。

我build议IOlockingPERC，而不是操作系统

这是很多消化。

您正在使用ZFS，所以很有可能这是池中的5TB磁盘的问题，可能是您的池设置。

这些可能是4k扇区磁盘，所以应该在ZFS设置中进行一些调整来解决这个问题。

你可以提供你的df -h ， fdisk -l ， zpool list ， zpool status -v和zfs list输出吗？

我认为您的写入caching与块设备速度相比太大了。我会build议如下：

 vm.dirty_background_bytes = 50000000 vm.dirty_bytes = 200000000 vm.dirty_expire_centisecs = 500 vm.dirty_writeback_centisecs = 20

永远不要设置*_bytes和*_ratio因为最后一个设置将赢。此外，一些Linux内核版本可能会有一个错误，即设置*_ratio不能按预期工作。我会build议每次使用*_bytes 。

不幸的是，就我所知，写caching设置是全局的。因此，当由于某些速度较慢的设备而需要降低全局写入caching大小时，吞吐速度将会受到影响。