セットアップは次のようになります。
VMware ESXi 6.0
データストアは、ESXiのインストール後に残っているすべてのディスクスペースで構成されています(8TB弱)
ゲストCentOSでは、システムパーティションはLVMext4です。
データパーティションは、単一のPV、LV、およびVGext4を備えたLVMです。
今私が抱えている問題は、ディスク上のデータ転送速度が非常に遅いことです。セミラージファイル(10〜30 GB)をLVMのある場所からLVMの別の場所にコピーしようとすると、約240MB/sの転送速度で開始されます。これは、私が期待する速度ですが、数秒後(通常は30秒)、1〜4 MB/sに低下し、iotopを表示すると、flush-253:2と呼ばれるプロセスの実行が開始され、すべてが遅くなるようです。
私はrsync--progressを使用して、転送速度をリアルタイムでより正確に把握してきましたが、cp操作でも同じ結果が得られます。
最終的に終了したら、同じファイルを同じ場所に置いて、同じ手順をもう一度実行してみました。 2回目は、rsyncの指示された転送速度が転送全体を通して約240MB/sで安定しますが、rsyncがファイル転送の完了を示した場合、最初のコピー手順を完了するのにかかった時間とほぼ同じ時間、その状態でハングします。両方の手順でflush-253:2プロセスが同じように機能していることがわかります。
これで、セットアップが最適ではないことがわかりました。ESXiシステム用に別のディスクを用意することをお勧めしますが、それがこの極端に遅い転送速度の原因であるとは思われません。
フラッシュプロセスに関する情報を検索しましたが、私が知る限り、基本的にメモリから実際のディスクにデータを書き込みますが、このレベルの遅い転送速度を経験したと言っている人は誰もいません。 。システムはまだ稼働しておらず、CPUもほとんど稼働しておらず、コピー手順の実行時に使用できる約100GBの空きメモリがあります。
誰かが何を試すべきかについて何か考えがありますか?完全に異なる(やや少ない)ハードウェアを除いて、基本的に同じ方法でセットアップされた別のシステムで同様の結果が見られました。 LVMでCentOS5とext3を実行している3番目のシステムもありますが、このような問題はありません。
編集1: 私は今、間違って記憶していたことに気付きました。システムパーティションもlvmですが、それでもデータパーティションとは別のボリュームです。
[root@server /]# mount
/dev/mapper/vg1-lv_root on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw,rootcontext="system_u:object_r:tmpfs_t:s0")
/dev/sda1 on /boot type ext4 (rw)
/dev/mapper/vg1-lv_home on /home type ext4 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
/dev/mapper/vg_8tb-lv_8tb on /datavolume type ext4 (rw,nobarrier)
[root@server /]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_1-lv_root<br>
50G 9.7G 37G 21% /
tmpfs 91G 0 91G 0% /dev/shm
/dev/sda1 477M 52M 400M 12% /boot
/dev/mapper/vg_1-lv_home
45G 52M 43G 1% /home
/dev/mapper/vg_8tb-lv_8tb
7.9T 439G 7.1T 6% /datavolume
アップデート1: 私はdirty_ratioを90まで増やしてみましたが、それでも改善は見られませんでした。 -o nobarriersでマウントしてみましたが、それでも同じ結果になりました
アップデート2: 混乱について私を助けようとしているすべての人に申し訳ありませんが、私は自分自身を見てきたので、ハードウェアは実際にはHP Proliant 380 G7ですが、それが違いを生むかどうかはわかりません。
また、レイドの構成も確認しましたが、P410レイドコントローラーを使用しているようです。レイド管理を起動すると、
HP Smart array (I think) P410 "SOMETHING", with 0MB in parenthesis
書き込みキャッシュに0MBがあることを意味しているのではないかと思います。
ハードウェアに関しては、ここでは少し深みがあります。書き込みキャッシュモジュール(?)がまだ存在しない場合は、このレイドコントローラーに追加できますか?または、新しいコントローラー/ SANへの移動が必要ですか?書き込みキャッシュがあるかどうかはどうすればわかりますが、おそらくバッテリーが切れていますか?
アップデート3: あなたの提案といくつかのさらなる研究のおかげで、私は今、ESXiにHPスマートアレイドライバーvibファイルをインストールしようとしています、そしてうまくいけば私が持っているもののより明確な絵を手に入れるでしょう。また、システムBIOSでドライブキャッシュを有効にするオプションを見つけたので、コントローラーに書き込みキャッシュがないことが判明した場合に備えて、最後の手段があるかもしれません。
アップデート4(解決済み): 解決策を提案してくれたすべての人に感謝します。そうです、ディスクコントローラにキャッシュモジュールが存在しないことが判明しました。
同様の問題を抱えている人には、ESXi用のhpssacliユーティリティVIBをインストールしました。次の出力で、返信で提案された内容を確認できました。
キャッシュボードの存在:False
Smart Array P410i in Slot 0 (Embedded)
Bus Interface: PCI
Slot: 0
Serial Number:
Controller Status: OK
Hardware Revision: C
Firmware Version: 6.62
Rebuild Priority: Medium
Surface Scan Delay: 15 secs
Surface Scan Mode: Idle
Parallel Surface Scan Supported: No
Wait for Cache Room: Disabled
Surface Analysis Inconsistency Notification: Disabled
Post Prompt Timeout: 0 secs
Cache Board Present: False
Drive Write Cache: Disabled
Total Cache Size: 0 MB
SATA NCQ Supported: True
Number of Ports: 2 Internal only
Driver Name: HP HPSA
Driver Version: 5.5.0
PCI Address (Domain:Bus:Device.Function): 0000:05:00.0
Host Serial Number:
Sanitize Erase Supported: False
Primary Boot Volume: logicaldrive 1
Secondary Boot Volume: None
書き込みキャッシュがあるようには見えません。
サーバーの世代とモデルを確認してください。ディスクが接続されているコントローラーにフラッシュバックアップ書き込みキャッシュモジュール(FBWC)がない場合、VMwareのパフォーマンスが低下します。
ここでの他の問題は、LVMと、数年前にRHEL6に登場したデフォルトのいくつかです。書き込みバリアを無効にしてこれを試してみてください。 LVMは、ボリュームのパーティション分割を回避するように人々を導くため、問題になる可能性があります...そしてそれはtuned-adm
のようなツールが仕事をする能力に影響を与えます。
mount
の出力を要求しました。投稿してもらえますか?
no barrier
フラグを使用してボリュームをマウントしてみてください。書き込みバリアはext4のEL6のデフォルトであるため、これが発生している最大の問題です。
RAIDコントローラにキャッシュがないようです。主な問題は、ハードウェアRAIDカードがデフォルトでディスクのプライベートDRAMキャッシュを無効にする傾向があることです。
つまり、数秒後(正確には、約30秒)にダーティページキャッシュがディスクにフラッシュされると、大量のランダムI/O要求が(遅い)メカニカルディスクを叩き始め、スループットが低下します。
ディスクのプライベートDRAMキャッシュを再度有効にすると(多くの場合、これはRAIDコントローラーオプションです)、パフォーマンスが大幅に向上するはずです。さらに高速な書き込みを行うには、書き込みバリアをオフにすることができます(nobarrier
マウントオプションを使用)が、残念ながら、BBUキャッシュがない場合は、オフになりますシステムのクラッシュ/停電の場合にデータの信頼性に影響を与えます。
EDIT:詳細については ここ を参照してください。
これの複製のようです:
フラッシュ-0:nプロセスが大きなボトルネックを引き起こしている
確かに、dirty_ratioを確認する必要があります。最初の書き込みがRAMで行われるため、最初は非常に高速なIOレートになります。後でRAMがdirty_ratioまでいっぱいになると、カーネルはディスクへのフルッシングを開始します。
いくつかの質問:
そして2つの個人的なメモ:-7,2KとRAID10を備えた6台の低速SATAドライブで実際に240MB/sに達することはないと思います。