Table of Contents
SamvaサーバーはクライアントとTCP通信を使用しているため、パフォーマンスを上げるには同じプロトコルを使用しているプログラムと比べてみるべきである。最も簡単に入手できるTCPを使用したファイル転送プログラムは、FTPもしくは他のTCPベースのSMBサーバである。
もしNTやWindows Workgroups serverに対して実験してみたいなら、クライアントかサーバのTCP以外は無効にする必要がある。そうしないとNetBEUIのようなまったく違うプロトコルが使われ、比較は意味がない。
通常、SambaプラットフォームがFTPと同じぐらいの理論上の転送速度で動作することが解るだろう。速度はそのシステムの環境次第だが、NFSよりかは相当早い。
何人かは、SambaとNovell、NFS又はWindows NTとの間での比較を行った。そのうちのいくつかの場合は、Sambaの動作は一番よく、ほかの場合は一番悪かった。最も大きな要素は、Samba対他のシステムではなく、種々のシステムで使用しているハードウェアとドライバであると推測している。同じようなハードウェアで、Sambahaは他のシステムと、速度の点において競合できうる。
いくつかのオプションは、SambaのようなTCPベースのサーバのパフォーマンスに大きな影響を与える。
Sambaが使うソケットオプションは、-O
をコマンド行に指定するか、smb.conf
ファイルに記述できる。
smb.conf
のマニュアルページのsocket optionsに、どのように記述するか、推奨は何かがが書いてある。
ソケットオプションを正しく設定すれば大きくパフォーマンスを改善できるが、間違って設定すると同じくらいパフォーマンスが悪くなる。正しい設定は、使用するネットワークにとても依存する。
TCP_NODELAYは多くのネットワークにおいて、単独で大きな違いを引き起こす。多くの人々がsocket options = TCP_NODELAYを追加することで、Sambaのreadパフォーマンスを2倍にしたと報告している。MicrosoftのTCP/IPスタックがTCP ACKを送るのが遅いためだというのが一番良い説明だろう。
socket options = SO_RCVBUF=8192
をsmb.confの中に書き込むことで、Sambaのループバックアダプタ(IP Address 127.0.0.1)のパフォーマンスがひどく下がるという報告がある。socket options
を設定する前に、サーバ上で定量的に計測することを強く推奨する。
read sizeオプションは、ディスクのR/WとネットワークのR/Wの同時動作に影響する。いくつかのSMBコマンド(currently SMBwrite, SMBwriteXとSMBreadbraw)で転送されているデータ量がこの値より大きかったとき、サーバはネットワークからそのパケットを受け取る前にデータを書き込む。もしくは、SMBreadrawコマンドの場合、全てのデータをディスクから読む前にネットワークに書き込む。
この並列動作は、ディスクアクセスとネットワークアクセスがほぼ同じ速度の場合に最も効果があり、どちらか片方がとても早い場合にはあまり効果がない。
既定値は16384である。最適値を決めるために多少試験してみたが、最適値はシステム間で非常に大きく違うようである。65536以上の値には意味が無く、不必要にメモリを割り当ててしまう。
起動時にクライアントとサーバとの間で、ほぼすべてのコマンドサイズを制限する、maximum transmit
値の調停を行う。sambaが調停する最大値をsmb.conf
にmax xmitオプションを使うことで設定できる。これはSambaが受け取るSMBリクエストの最大値であり、クライアントが受け取る最大値ではない。クライアントのmaximum受信サイズはクライアントからSambaに送られ、Sambaはその値を信頼する。
既定値では65536バイトに設定されているが、より小さい値の方がよいという場合もありうる。2048より小さい値にすると、重大な問題を引き起こす可能性がある。殆どの場合、既定値が最適である。
debug levelとして設定できるログレベルを2より大きくすると、大幅にパフォーマンスが低下する。これはサーバが各操作後ににログをフラッシュし、それがとても時間がかかるためである。
read raw操作は、最適化された、レイテンシの小さい、ファイル読み取り操作の為に設計されている。サーバはそれをサポートしなくてもよいが、Sambaはread rawサポートをオプションとしていて、規定値では有効になっている。
ある場合、クライアントはread rawをうまく扱えず、従来の読み取り操作を使うよりも、それを使うことで実際にはパフォーマンスが落ちることとなり、そのため、read raw = noを試して、ネットワーク上で何が起きるかを観察しても良い。それはパフォーマンスを下げるか上げるか、あるいは何も起きないかもしれない。テストすることで真実がわかる。
write raw操作は、最適化された、レイテンシの小さい、ファイル読み取り操作の為に設計されている。サーバはそれをサポートしなくてもよいが、Sambaはread rawサポートをオプションとしていて、規定値では有効になっている。
多くの場合、write rawをパラメータを変更しようとした場合、変更すると通常よりも速度が遅くなる。
ログインが遅い場合は、多くの場合パスワードチェックのためである。最も小さい実用的なpassword levelは、これを改善する。
大抵の場合、スピードの問題はクライアントに原因がある。(Windows for Workgroupsのような)クライアントはたいていの場合、TCPパフォーマンスをより改善できる。Sambaとその他のCIFSクライアント中の、各種クライアントについての節をチェックすること。
あるユーザーがメーリングリストに次のように発言した。
私はGentooの上でSamba 2.2.8aを動かしています。最近私はカーネルのバージョンを
linux-2.4.19-gentoo-r10
からlinux-2.4.20-wolk4.0s
に変更しました。すると、Sambaのパフォーマンスに問題が生じました。多くの人々はおそらく“普通のソース(kernel)に移行しろ!”」と言うでしょう。もちろん私は試しましたが、上手くいきませんでした。私は100MBのLANと2台のコンピュータ(LinuxとWindows2000)を使っています。LinuxサーバーでDivxファイルの入ったフォルダを共有し、クライアント(Windows2000)でLAN経由で再生していました。2.4.19カーネルにする前は全てが上手く動いていましたが、現在では動画は固まって止まってしまいます。サーバーからWindowsへファイルを移動させようとしましたが、それもとても遅いです。
それに対してこのような返答があった。
我々のSambaPDCサーバは、3年間の間問題なく500以上のユーザ[Windows NT/XP]で3TBのデータをホスティングしていました。現在ではすべての共有がとても遅いです。親プロセスのsmbdは継続してプロセスを起動していて、(通常なら平均で250なのに)1600以上のSMDBプロセスが起動しています。これによってSUN E3500が2回壊れています。幾たびもの調査の後、rm /var/locks/*.tdb
を実行することにしました。その結果、再び良好に動作しました。
質問:*.tdbファイルを最良の状態に保持する何らかの方法はあるのでしょうか?あるいは、どのようにしたら、素早く破壊状態を検出できるのでしょうか?
答え: はい、nmdbの停止と起動のたびにtdbbackup
を実行してください。
質問:さらに言及したいこととして、サービスのレイテンシは削除前よりかなり遅くなったように見えます。最高速度を保持する良いアイデアはありませんか?
答え:はい、同じ質問が前にありました。
MYOB Premier操作とそのデータファイルへのアクセスにおいて、とても不可解な徴候を経験したと、あるサイトは報告した。そのファイルへのいくつかの操作で40秒から45秒の時間がかかった。
Windowsクライアント上でプリンタモニタープログラムを走らせたところ、この問題が発生した。ログから、1秒ごとに休止状態が発生していることが分かりました。
モニタソフトウエアを止めたところ、ネットワーク速度が普通(早い状態に)戻りました。再びモニタソフトウエアを起動させたところ、再び遅くなりました。プリンターはCanon LBP-810で and the relevant task wassomething like CAPON (not sure on spelling). モニタソフトウエアは、クライアントが印刷中、"印刷中"を表示している。
Windowsのクリーンインストールと、他のソフトを何度も段階的にインストールすることによって、発見した。
この話の教訓:すべてをチェックしなさい(他のソフトウェアも含めて)!