2008/08/30(土)【解決】ファイル共有での遅延問題
2008/08/30 13:13
この問題はいったい何だったかというと、
・ファイルサーバ側(WinXP SP1)、クライアント側(WinXP SP1)ということだった。
・クライアント側からNBTでサーバ側のディレクトリにアクセスしたときに発生
・サーバ側のファイル数は600程度で日本語を含む
・ファイルの列挙(要はdir/ls)にかかる時間は4秒程度
・ファイルの列挙に時間がかかるだけで、転送速度そのものが遅くなっているわけではない
・パケットをキャプチャしてみたが余計なパケットは飛んでいないように見える
・dirで確認すると一定の転送量ごとに何かがつっかえている感じ
・サーバー側・クライアント側入れ替えても発生
・クライアント側からLinux+sambaの自宅サーバにアクセスするとこの現象は発生しない
さて、なんでこの問題に再び手をつけようと思ったかというと外部からLinuxサーバを介してWindows機をいじり倒すでsmbfsでlinuxからマウントした際に、この現象が発生しなかったためである。つまりこれはサーバとしてのWindowsの仕様ではなく、なにかしらネットワークやその他の設定が関わっている可能性が高い。あるいは、クライエント側の設定次第で回避する方法があるということだ。
さて、いつも通りパケットキャプチャから始める。使うソフトは定番WireShark（EtheralはWireSharkと名前を変えた）。
前回結論は、
・パケットをキャプチャしてみたが余計なパケットは飛んでいないように見えるだったが何か見落としがあるだろうか。
クライアント側
サーバ側
読み方としては、requestが飛んで、Responseを３分割で返してACKが２回……確かに余計なパケットは飛んでないように見える。だけどなんだろう、この0.2秒のラグは。これが定期的に発生してるから遅くなっているように見える。ACKの１回目で連結させて、２回目までにラグ？ この２回目のACKは余計なものなんじゃないだろうか。
で、調べてみたらそのものずばりな情報が公式にあった。
今回ばかりは私の探し方が悪い。MS悪くない。
リモート ディレクトリの表示はローカル ディレクトリの表示より時間がかかる
この情報整理するとこういうことらしい。
- 分割応答の際は偶数回目だけACKを送ります
- もしくは他の接続がくるか0.2秒タイムアウトすると送ります
- 従ってブロックが奇数個に分割される応答ではブロック応答ごとに0.2mmの遅延が発生します
- ブロックのデフォルト値は4356byteです
- TCP/IPのデフォルトMTUは1500byteです
- ブロックは３つに分割されますので、ブロックごとに0.2mmの遅延が発生する結果こうなります
ていうか情報は良いんだけど、これデフォルト値の設定に色々文句があるというか。
いや違うな。この偶数回目だけ返すっていう仕様がなんかだなあ。確かにネットワークの無駄ACKパケットが最大半分に減るけど、それは対処療法的チューニングというか、せめて設定でいじらせてくださいよ。
要約すると、通常、確認応答は、遅延確認応答のタイマ (200 ミリ秒) がタイムアウトしない限り、1 つの接続で受信した TCP セグメントに対して 1 つおきに送信されます。遅延確認応答を構成する、または無効にするレジストリ パラメータはありません。……。
で、対処方法に挙げられているとおり、
１．[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters]に[値の追加]で、
値の名前 : SizReqBuf
データ型 : REG_DWORD
データ : 14596
(データは10 進数)
２．Server サービスを再開（もしくは再起動）
>net stop server
>net start server
で、全く問題が無くなりました！ やりい。一応パケットも見てみたけど、想定通りブロックを10個分割で送って5回ACK返しで、すぐに次の通信に推移してるね。
ただね、これ抜本的な解決じゃなくて、多分ジャンボフレームの設定とかいじると、また奇数個分割にマッチしちゃうことがあると思うんだよねえ。ディレクトリのリストが１回で返る場合や、応答の尻尾というか最後でも0.2secつっかえる可能性があるわけだし、なんかクソ仕様な気がしてならないぞ。まあ解決方法が分かったので、その都度対処は出来るけども。
Vistaが対象一覧に含まれていないので、Vistaでは改善したのかしら。
多分Windows Serverを日常的に扱っている人にとっては当たり前の知識（もしくはバッドノウハウ）なんだろうな。