継続的な順次書き込みでの大幅なパフォーマンス低下
データを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]
注目すべきことに、約2秒間、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
私はこれらの質問があります：
- このデータディスクへの継続的な順次書き込みによってサーバーの速度が大幅に低下するのはなぜですか？
- 特定の1つまたは少数のディスクに書き込むときに、他のディスクのパフォーマンスを低下させないようにするにはどうすればよいですか？
- なぜこの種のハードドライブがパフォーマンスの問題を引き起こしているのに、他のドライブはそうではないのですか？
同じモデル（/dev/sdc、/dev/sdd、/dev/sde、/dev/sdf、/dev/sdg、/dev/sdh）の6つのディスクを暗号化して将来的にシーケンシャル書き込みワークロードが発生するため、この問題によってサーバーが停止することは避けたいです。
追加情報
簡単な事実
サーバー：Dell PowerEdge T32
カーネル：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
オペレーティングシステム：buntu Server 16.04 LTS Xenial Xerus 64ビット
問題のあるハードドライブ：Toshiba PH3500U-1I72
私はこれらのディスクを6つ持っていますが、すべて正常であることがわかっており、そのうち2つをテストしたところ、両方でサーバー全体のI/Oパフォーマンスが低下しました。彼らは読み始めて200MiB/sで読み書きします。
制御（問題のない）ハードドライブ：Samsung SP1614C
このディスクの持続書き込み速度は50MiB/sです。問題のあるディスクが速すぎるのではないでしょうか？
ディスクコントローラ：Dell PERC H31
2台のソリッドステートドライブと6台の問題のあるハードドライブがこのコントローラーに接続され、すべてが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
コントロールディスクは、マザーボードに組み込まれているSATAポートに接続されています。
述べたように、ジャーナルのフラッシュタイムアウトの問題が発生しているディスクは、PERCに接続されています。これは、「問題のある」東芝が接続されているのと同じコントローラです。
PERC 310は、基本的なハードウェアRAIDカードにすぎません。それは、CPUがおそらく簡単に圧倒されているか、それともファームウェアのバグがあるかです。直接AHCIはあまり一般的な使用法ではありません。
IOがOSではなくPERCでロックアップしていることをお勧めします
これは消化することがたくさんです。
ZFSを使用しているため、これがプール内の5TBディスクと、場合によってはプールのセットアップに問題がある可能性があります。
これらは4kセクターのディスクである可能性があるため、それを考慮してZFSセットアップでいくつかの調整を行う必要があります。
df -h、fdisk -l、zpool list、zpool status -vおよびzfs list出力？
書き込みキャッシュがブロックデバイスの速度に比べて大きすぎると思います。私は以下をお勧めします：
vm.dirty_background_bytes = 50000000
vm.dirty_bytes = 200000000
vm.dirty_expire_centisecs = 500
vm.dirty_writeback_centisecs = 20
*_bytesと*_ratioの両方を設定しないでください。最後に設定された方が優先されます。さらに、一部のLinuxカーネルバージョンには、*_ratioの設定が意図したとおりに機能しないというバグがある場合があります。毎回*_bytesを使用することをお勧めします。
残念ながら、書き込みキャッシュ設定は私の知る限りグローバルです。その結果、一部の低速デバイスが原因でグローバル書き込みキャッシュサイズを減らす必要がある場合、高速デバイスへのスループットが少し低下します。