NFSクライアント/サーバースタックのチューニング

CentOS 5 VMWareサーバーが、ディスクイメージを保持するNFSを介してOpenSolaris 2009.06マシンに接続しています。私の仮想マシンは遅いIOによってバインドされているようですので、接続を最適化するためにできる限りのことをしたいと思います。

本番システムでスループットを測定する最良の方法dd bs=1024k count=400はわかりませんが、show local（OpenSolaris）の書き込みが〜1.6GB / s、リモート（CentOS）の書き込みが〜50MB / sの非科学的なテストです。現在、7つのVMが接続を介して実行されているため、これらは実際に得ているものよりも低いと思います。

現在、2台のマシンは直接接続されたgigEであり、ジャンボフレームは両方のNICで有効になっています（MTU = 9000）。それ以外は、最適化は行われていません。NFSマウント/エクスポートはデフォルトを使用しています。

パフォーマンスを向上させるには、ノブをどこから始めればよいですか？

明確にするために、単一のGbイーサネット接続を介してNFSで50MB /秒を取得していますか？

また、ホストサーバーは、VMware ServerがインストールされたCentOSを実行しています。これにより、7つのVMが実行されます。より高性能なソリューションであるVMware ESXiではなく、CentOSとVMware Serverを組み合わせて使用​​した特別な理由はありますか？

50MB /秒は素晴らしいものではありませんが、1本のGbネットワークケーブルで期待するものを大きく下回ることはありません。NFSを調整すると、前述のように人々が言及したように、おそらく70- 80MB /秒。以下のオプション：

「ro、hard、intr、retrans = 2、rsize = 32768、wsize = 32768、nfsvers = 3、tcp」

システムの両端でおそらくあなたにとって合理的です。

それを超えるには、ネットワークカードをペアにチーム化する必要があります。これにより、スループットが約90％増加します。リンク集約で最高のパフォーマンスを得るには、802.3adをサポートするスイッチが必要になる場合があります。

ただし、OpenSolarisボックスでのIOスループットが疑わしいほど高く、12個のディスクが1.6GB /秒のスループットをサポートする可能性は低いため、Solaris + ZFSによって大量にキャッシュされる可能性があります。

RHEL / CentOS 5マシンでは、次のマウントフラグを使用します

nfsvers = 3、tcp、timeo = 600、retrans = 2、rsize = 32768、wsize = 32768、hard、intr、noatime

新しいLinuxカーネルバージョンは、さらに大きなrsize / wsizeパラメーターをサポートしますが、EL5の2.6.18カーネルでは32kが最大です。

NFSサーバーでは、少なくともLinuxの場合、BBWCを備えたディスクコントローラーがある場合、no_wdelayがおそらく役立つでしょう。また、クライアントでnoatimeフラグを使用する場合は、おそらくnoatimeを使用してサーバーにファイルシステムをマウントすることも意味があります。

そして、すでに述べたように、UDPを気にしないでください。より高速のネットワーク（1GbE +）では、シーケンス番号が折り返されてデータが破損する可能性がゼロではありません。また、パケット損失の可能性がある場合、TCPはUDPよりもパフォーマンスが高くなります。

データの整合性についてそれほど心配しない場合は、「非同期」エクスポートオプションを使用すると、パフォーマンスが大幅に向上します（非同期の問題は、サーバーがクラッシュするとデータが失われる可能性があることです）。

また、少なくともLinuxサーバーでは、十分なNFSサーバースレッドが実行されていることを確認する必要があります。デフォルトの8は低すぎます。

私は一度、dell r710、1 CPU、4 GB RAM、RAID-10搭載の6 SATAディスクでテストを行いました。クライアントはsun x2100であり、CentOS 5.3と上記のようなnfsパラメータの両方を備えていました

「ro、hard、intr、retrans = 2、rsize = 32768、wsize = 32768、nfsvers = 3、tcp」

noatimeで両側に取り付けられています。

また、nfsdsを256に増やし、perc6 RAIDコントローラにnoopスケジューラを使用しました。私がしたもう1つのことは、パーティションをRAIDコントローラの64Kストライプサイズに揃えることでした。

次に、ddを使用してnfsパフォーマンスを測定しました-読み取りの場合はgigEパイプを埋めることができましたが、書き込みの場合は、あなたよりもわずかに良い結果しか得られませんでした。非同期を有効にすると、70〜80 MB /秒を取得できましたが、非同期は私の選択肢ではありませんでした。

たぶん、gigEリンクからnfsでこれ以上取得することはできませんか？

次の2つの手順で、OpenSolaris NFSサーバーでZFSインテントログ（ZIL）を一時的に無効にします。

1. echo zil_disable/W0t1 | mdb -kw
2. テストパーティションを再マウントします

その後、もう一度テストします。zilstatを使用して、ZILへのIOが本当にないことを確認できます。テストの実行が速くなれば、パフォーマンスの問題がZILに関係していることがわかります。それでも動作が遅い場合は、ZILが原因ではないことと、ZILにSSDを使用しても役に立たないことがわかります。ZILの詳細については、ZFS Evil Tuning Guideを参照してください。

別のオプションは、ネットワークトラフィックをキャプチャし（たとえば、Wiresharkを使用）、ジャンボフレームなどに問題がないかどうかを確認することです。ワイヤー上のパケットが、構成から予想したとおりであることを確認します。悪い断片化が起こっていますか？再送信はありますか？

読み取りおよび書き込みペイロードのサイズを大きくすると、役立つことがあります。特にジャンボフレームと組み合わせて使用​​します。

32kが最適だと思う傾向があります。

rsize=32768,wsize=32768

もちろん、UDPトランスポートへの切り替えは、TCPよりも高速です。これは、転送制御のオーバーヘッドが節約されるためです。しかし、これは信頼できるネットワークでNFSv4が使用されていない場合にのみ適用されます。

ZFSでのNFSパフォーマンスは、ZFSインテントログ（ZIL）にSSDを使用することで大幅に向上します。これにより、操作の待ち時間が短縮されます。OpenSolaris NFSおよびZFSメーリングリストのZFSパフォーマンスにおけるVMWare NFSに関するこのスレッドには、ZILパフォーマンスがボトルネックであるかどうかを確認するベンチマークツールなどの詳細情報があります。

ちなみに、ddコマンドはディスクに書き込まずにキャッシュに書き込みます。SolarisではディスクではなくRAMに書き込むため、「-oflag = sync」を使用してディスクに強制的に書き込むことができるため、1.6G / sのようなクレイジーな数値が得られます。