Sambaパラメーターとパフォーマンス
パフォーマンスに影響するパラメーター「socket options」
socket optionsパラメーターは、Sambaが送受信するソケットに関するパラメーターです。昔の推奨値は「TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192」でしたが、現在のSambaにこのまま適用しても問題はないのでしょうか。
また、Windowsクライアントとの通信に依存したmssのサイズに合わせたチューニングを行うという情報もWeb上には存在しますので、こちらの値も検討します。
今回は以下の4パターンで計測しました。
ケース（1）は、以前の推奨値8192とした場合です。以下のようなパラメータ値になります。
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
ケース（2）は、mssに依存した値（今回の環境CentOS＋Windows XPではmss=1460でしたので、その6倍の8760としてあります）とした場合です。以下のようなパラメータ値になります。
socket options = TCP_NODELAY SO_RCVBUF=8760 SO_SNDBUF=8760
ケース（3）は、socket optionsを空白に設定とした場合です。以下のようなパラメータ値になります。
socket options =
ケース（4）は、smb.confにsocket optionsパラメーター自体を設定しない場合です。
socket optinosの正解は？
計測の結果、ケース（4）のsocket optionsパラメーターを設定しない場合が一番高いスループットが出ました。このテストの場合、ローカルで実行するsmbtortureより、ネットワークを経由HDBENCHの結果が、実際の状態に近いものと思われ、指定値の大きさとTCP_NODELAYの有無できれいにケース（4）（3）（2）（1）の順番となっていました。
ケース（4）の場合TCP_NODELAYだけを指定した状態となりますが、SO_RCVBUFとSO_SNDBUFは0に設定されているわけではなく、デフォルト値が適用されています。このデフォルト値はlog levelを100にして、log.smbdを参照すると以下の値でsmbdが起動していました。
SO_RCVBUF=87380
SO_SNDBUF=16384
今回のケース（1）と（2）では手動で設定した値が、上記デフォルト値より小さな値を設定していたため、ネットワーク経由でのパフォーマンス劣化が発生していたものと推測されます。また、ケース（1）の8192は（2）の8760と数値としては、ほとんど違いが無いのですが、smbtortureでは内部スループットが大幅に劣化している点も興味深いです。
ケース（3）の場合、SO_RCVBUFやSO_SNDBUFはデフォルトの値となりますが、TCP_NODELAYが無効となるため、smbtortureとHDBENCHともにスループットが下がりました。
テストの結果から今回の環境では、smb.confは特に問題が無いかぎりは、socket optionsパラメーターは設定せず、デフォルトの状態（TCP_NODELAYのみ）にしておくのが良いようです。
ケース（1）と（2）では、値に8192を指定した（1）の方が大幅に劣化していたため、Wiresharkで詳細に調査してみました。すると、SO_SNDBUF＝8440以下ではパケットに「TCP Window Full」が大量発生し、linux kernel内部では10倍以上の頻度でmwait_idleやprepare_to_waitが呼ばれていました。
この現象はCentOS 5.2に依存しており、ほかのOSでは発生しないものと思われますが、このパラメーターを利用する場合は実環境でテストを行ってください。
次回はファイルサーバーとして利用する場合に重要なファイル属性、ユーザー属性関連のパラメーターについて解説します。
