サーバーの負荷が高く(20または30以上になることもある)、CPU使用率が非常に低い(アイドル状態が98%)場合のシナリオに遭遇しています。これらの待機状態がNFSファイルシステム接続の一部として来ているのかどうか疑問に思っています。これは私がVMStatに表示するものです
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
2 1 0 1298784 0 0 0 0 16 5 0 9 1 1 97 2 0
0 1 0 1308016 0 0 0 0 0 0 0 3882 4 3 80 13 0
0 1 0 1307960 0 0 0 0 120 0 0 2960 0 0 88 12 0
0 1 0 1295868 0 0 0 0 4 0 0 4235 1 2 84 13 0
6 0 0 1292740 0 0 0 0 0 0 0 5003 1 1 98 0 0
4 0 0 1300860 0 0 0 0 0 120 0 11194 4 3 93 0 0
4 1 0 1304576 0 0 0 0 240 0 0 11259 4 3 88 6 0
3 1 0 1298952 0 0 0 0 0 0 0 9268 7 5 70 19 0
3 1 0 1303740 0 0 0 0 88 8 0 8088 4 3 81 13 0
5 0 0 1304052 0 0 0 0 0 0 0 6348 4 4 93 0 0
0 0 0 1307952 0 0 0 0 0 0 0 7366 5 4 91 0 0
0 0 0 1307744 0 0 0 0 0 0 0 3201 0 0 100 0 0
4 0 0 1294644 0 0 0 0 0 0 0 5514 1 2 97 0 0
3 0 0 1301272 0 0 0 0 0 0 0 11508 4 3 93 0 0
3 0 0 1307788 0 0 0 0 0 0 0 11822 5 3 92 0 0
IOが上がるとわかることから、待機が上がる。NFSが原因であるのか、それとも他のことを心配する必要があるのか?これは、ファイバーチャネルSANのVPSボックスです。ボトルネックはSANではないだろうと思います。
iostatを使用して、I/O待機を生成するデバイスを特定することができます。
# iostat -k -h -n 5
詳細については、iostatのマニュアルページを参照してください。特に多数の小さなファイルを処理する場合、または特定の多くのファイル操作を行う場合は、nfsが問題の一部になることがよくあります。 rsize = 32768、wsize = 32768のような通常のマウントオプションを使用して、nfsアクセスを調整できます。このトピックをカバーするnetappによる優れたホワイトペーパーがあります: http://media.netapp.com/documents/tr-3183.pdf
また、ネットワークインターフェイスにドロップがないことを確認してください。
お役に立てれば
率直。
asyncオプションを/ etc/exportsに追加すると、負荷平均を標準に戻すことができました。
/mnt/dir *(rw,async,pnfs,no_root_squash,no_subtree_check)