☰

連続した連続書き込みによるパフォーマンスの大幅な低下

tag-icon • tag-icon linux performance hard-drive io
連続した連続書き込みによるパフォーマンスの大幅な低下

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の間でまだ先行していました。2GiB3GiB

すべての 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. このデータ ディスクへの連続書き込みが継続すると、サーバーの速度がなぜこれほど低下するのでしょうか?
  2. 特定の 1 台または少数のディスクに書き込むときに、他のディスクの速度低下を回避するにはどうすればよいでしょうか?
  3. なぜこの種類のハードドライブではパフォーマンスの問題が発生するのに、他のドライブでは発生しないのでしょうか?

/dev/sdc暗号化するディスクは同じモデル ( 、、、、、、 )が 6 台あり、将来的には順次書き込みワークロードが発生するため、この問題によってサーバーが停止しないようにしたいと考えています/dev/sdd。/dev/sde/dev/sdf/dev/sdg/dev/sdh

追加情報

クイックファクト

サーバ： デルパワーエッジ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 台所有しており、すべて正常であることが分かっています。そのうち 2 台をテストしたところ、両方のディスクでサーバー全体の I/O パフォーマンスの低下が発生しました。ディスクは、ほぼ200MiB/s最初から読み取りと書き込みを実行していました。

コントロール（問題のない）ハードドライブ： サムスン SP1614C

このディスクの持続書き込み速度は です50MiB/s。問題のあるディスクが速すぎる可能性がありますか?

ディスクコントローラ: デル PERC H310

このコントローラには、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

答え1

制御ディスクは、マザーボードに内蔵された SATA ポートに接続されます。

前述のとおり、ジャーナル フラッシュ タイムアウトの問題が発生しているディスクは、問題のある Toshiba が接続されているのと同じコントローラーである PERC に接続されています。

PERC 310 は、基本的なハードウェア RAID カードにすぎません。CPU はおそらく簡単に圧倒されるか、ファームウェアのバグがあるかのどちらかです。ダイレクト AHCI はあまり一般的に使用されていません。

PERCのIOがロックアップしているのであって、OSではないと思います。

答え2

これは消化すべきことがたくさんあります。

ZFS を使用しているため、プール内の 5TB ディスクと、場合によってはプールの設定に問題がある可能性があります。

これらは 4k セクターのディスクである可能性があるため、それを考慮して ZFS セットアップでいくつかの調整を行う必要があります。

df -h、、、および出力fdisk -lを提供できますか?zpool listzpool status -vzfs 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

残念ながら、私の知る限り、書き込みキャッシュ設定はグローバルです。その結果、低速デバイスのためにグローバル書き込みキャッシュ サイズを減らす必要がある場合、高速デバイスへのスループットが少し低下します。

関連情報