☰

64GBのメモリを搭載したシステムでは、ddでデバイスnullにコピーしている間、Linuxバッファがいっぱいになり、手動でdrop_cachesを実行するまでIOが停止します。

tag-icon • tag-icon linux performance dd pagefile disk-cache
64GBのメモリを搭載したシステムでは、ddでデバイスnullにコピーしている間、Linuxバッファがいっぱいになり、手動でdrop_cachesを実行するまでIOが停止します。

私は Linux ソフトウェア RAID 10 でサーバーを実行しています。これは 64GB RAM を搭載したデュアル CPU システムです。各 CPU に 2x16GB DIMM が接続されています。dd を使用して KVM 仮想マシンをバックアップしたいのですが、深刻な IO 問題が発生しています。最初は RAID に関連していると思いましたが、Linux のメモリ管理の問題でした。次に例を示します。

  1. メモリは正常です: https://i.stack.imgur.com/NbL60.jpg
  2. ddを開始します: https://i.stack.imgur.com/kEPN2.jpg
  3. nmon はディスク アクセスも表示します。 https://i.stack.imgur.com/Njcf5.jpg
  4. しばらくすると「バッファ」が大きくなり、コピーの進行が止まります https://i.stack.imgur.com/HCefI.jpg
  5. meminfo は次のとおりです: https://i.stack.imgur.com/KR0CE.jpg
  6. dd の出力は次のとおりです。 https://i.stack.imgur.com/BHjnR.jpg
  7. 手動で一時的に問題を解決し、キャッシュを強制的に削除することができます: "sync; echo 3 > /proc/sys/vm/drop_caches"
  8. 呼び出しには数秒かかり、その後すぐに dd 速度が通常のレベルに達します。もちろん、1 分ごとに cronjob を実行したりすることはできますが、それは実際の解決策ではありません。 https://i.stack.imgur.com/zIDRz.jpg https://i.stack.imgur.com/fO8NV.jpg

解決策や設定のヒントを持っている人はいますか? ここに私の sysctl もありますが、すべての値は Centos のデフォルトです。 https://i.stack.imgur.com/ZQBNG.jpg

編集1

別のテストを行い、/dev/null の代わりにディスクに dd を作成します。今回も、pv なしで 1 つのコマンドで実行します。つまり、プロセスは 1 つだけです。dd if=/dev/vg_main_vms/AppServer_System of=AppServer_System bs=4M

  1. 書き込みなしで読み取りから開始します（ターゲットが同じディスク上にありません） https://i.stack.imgur.com/jJg5x.jpg
  2. しばらくすると、書き始めると読むスピードが遅くなります https://i.stack.imgur.com/lcgW6.jpg
  3. その後は、書くだけの時間になります。 https://i.stack.imgur.com/5FhG4.jpg
  4. ここで主な問題が発生します。コピー プロセスが 1 MB 未満に低下し、何も起こりません。 https://i.stack.imgur.com/YfCXc.jpg
  5. ddプロセスには100%のCPU時間（1コア）が必要になりました https://i.stack.imgur.com/IZn1N.jpg
  6. そして、もう一度手動で一時的な問題を解決し、キャッシュを強制的に削除することができます: sync; echo 3 > /proc/sys/vm/drop_caches。その後、同じゲームが再び始まります...

編集2

ローカル dd の場合、パラメータ iflag=direct および oflag=direct を使用して回避できます。ただし、これは万能な解決策ではありません。VM からローカル samba 共有にファイルをコピーするなどの他のファイル アクセスもあり、そのようなパラメータは使用できません。このような問題が発生することなく大きなファイルをコピーできないのは普通ではないため、システム ファイル キャッシュ ルールを微調整する必要があります。

答え1

単なる推測です。問題は大きなダーティ ページのフラッシュにある可能性があります。/etc/sysctl.conf を次のように設定してみてください。

# vm.dirty_background_ratio contains 10, which is a percentage of total system memory, the 
# number of pages at which the pdflush background writeback daemon will start writing out 
# dirty data. However, for fast RAID based disk system this may cause large flushes of dirty
# memory pages. If you increase this value from 10 to 20 (a large value) will result into 
# less frequent flushes:
vm.dirty_background_ratio = 1

# The value 40 is a percentage of total system memory, the number of pages at which a process
# which is generating disk writes will itself start writing out dirty data. This is nothing
# but the ratio at which dirty pages created by application disk writes will be flushed out
# to disk. A value of 40 mean that data will be written into system memory until the file 
# system cache has a size of 40% of the server's RAM. So if you've 12GB ram, data will be
# written into system memory until the file system cache has a size of 4.8G. You change the
# dirty ratio as follows:
vm.dirty_ratio = 1

次に、sysctl -pリロードして、再度キャッシュを削除します ( echo 3 > /proc/sys/vm/drop_caches)。

関連情報