!== !== Speed.txt for Samba release 2.0.7 26 Apr 2000 !== 翻訳者: 中野武雄 更新日: July 1999 主題: Samba の性能について (Samba performance issues) ============================================================================ このファイルでは、Samba サーバの速度を向上させる方法について、その 概要を述べます。 比較対象 -------- Samba サーバはクライアントとの通信に TCP を用います。したがってサーバ が良好に動作しているかを知りたい場合には、同じく TCP プロトコルを使って いるプログラムと比べなければなりません。比較対象にする TCP ベースの ファイル転送プログラムとしては、 ftp か、他の SMB/TCP サーバがもっとも 入手が簡単でしょう。 NT や WfWg サーバなどと比較したい場合は、クライアントかサーバのいずれ かで、 TCP 以外のプロトコルを全て無効にしなければなりません。さもなけ れば TCP とは全く異なるプロトコル (NetBEUI など) が通信に用いられてし まいますから、比較しても意味がありません。 通常 Samba は、 ftp と同等の転送速度になるでしょう。 NFS よりはだい ぶ速いと思います。しかしこれらはシステムに強く依存します。 Samba と Novell, NFS, WinNT などとの比較に関しては、何人かの人からレポー トが出ています。 Samba が最速の場合もあれば、もっとも遅い場合もあるよう です。個人的には、このような比較において重要となる要素は、ソフトウェア間 の違いではなく、さまざまなシステムでそれぞれ用いられているハードウェアや ドライバの違いだと思っています。同じようなハードウェアを揃えれば、 Samba は他のシステムと、速度の点において充分競合できるはずです。 OPLOCKS ------- oplock (opportunistic lock: 便宜的ロック) とは、 SMB クライアントが ファイル操作をローカルにキャッシュする許可を、サーバから取得する手法の ことです。サーバが oplock を与えると、クライアントは自分だけがその ファイルにアクセスしているとみなして、積極的にファイルのデータを キャッシュしようとします。 oplock のタイプによっては、クライアントは ファイルの open/close 操作さえもキャッシュします。これによって、性能は 非常に向上します。 Samba 1.9.18 のリリースからは、この opportunistic lock が正しくサポート されています。これはデフォルトでは有効になっていますが、共有単位で 無効に切り替えることができます。用いるパラメータは以下です。 oplocks = False しかし我々は oplock を有効にしておくほうをお薦めします。 NetBench を 用いた現在のベンチマークでは、有効にしておいたほうがおよそ 30% ほども 速度が向上しています。これは平均の値であって、クライアントのリダイレクタの 動作によっては、体感速度が何倍も向上することさえあります。 Samba 1.9.18 以前には、 'fake oplocks' と言うオプションがありました。 これも過去との互換性を保つために残してありますが、今となっては使用 すべきではありません。このルーチンが行う動作に付いて、以下にまとめて おきます。 LEVEL2 OPLOCKS -------------- Samba 2.0.5 は新しい機能 - level2 (読み込み専用) oplock がサポートされ ました(ただし既定では、このオプションはオフになっています。詳細に付いては smb.conf のマニュアルページを参照してください)。level2 oplock を (共有毎に)有効にするには、以下のようにパラメータを設定してください。 level2 oplocks = true これで、通常は書き込みされないファイル、例えばアプリケーション共有など (Microsoft Office 共有のように、共通の実行ファイルが格納されている共有) への同時アクセスが高速化するはずです。それは、クライアントがこれらの ファイルをキャッシュから先読みすることが可能になるからです。 以前の 'fake oplocks' オプション (使わないこと) ----------------------------------------------- oplock 動作をするように Samba を見せかけることができます。これは クライアントから来た oplock 要求を全て与えるようになっています。 smb.conf のオプション "fake oplocks" によって設定できます。 "fake oplocks = yes" とすると、クライアントは open 動作を行うたびに、積極的 にキャッシュをするようになります。 'fake oplocks' は、リードオンリーの共有や、一度に一つのクライアントから しかアクセスされないことが保証されている共有に用いると、各種の動作にお いて非常に性能が向上するでしょう。しかし複数のクライアントが、ファイル に対して同時に読み書きを行うような共有にこれを用いると、おそらくデータ が破壊されてしまうでしょう。 ソケットオプション ------------------ Samba のような TCP ベースのサーバでは、サーバの性能に強い影響を 及ぼすようなソケットオプションが多数存在します。 Samba が用いるソケットオプションは、コマンドラインの -O オプションと smb.conf ファイルのどちらでも指定することができます。 smb.conf のマニュアルページにおける "socket options" セクションでは、 これらの指定方法と、おすすめの値とが記述してあります。 ソケットオプションを適切な値にすると、性能が非常に向上することが あります。しかし間違った値にすると、同じように非常に性能が低下すること もありえます。正しい設定は使っているネットワークに強く依存します。 数あるオプションの中でも、単独で大きな影響を及ぼすものとして TCP_NODELAY が挙げられます。 "socket options = TCP_NODELAY" を設定する ことによって、 Samba ドライブの読み出し性能が倍加した、という報告が 多くの人々からなされています。これに対する最もわかりやすい解釈は、 Microsoft の TCP/IP スタックでは tcp の ACK を送るのが遅い、という ものでした。 読み取りサイズ (read size) -------------------------- "read size" オプションは、ディスクの read/write とネットワークの read/write とのオーバーラップに影響することになります。 SMB のコマンド (現在あるのは SMBwrite, SMBwriteX, SMBreadbraw) によって転送されるデータの 分量が、この値よりも大きくなると、サーバはすべてのパケットをネットワーク から受け取る前にディスクへの書き込みを開始します (逆に SMBreadbraw の 場合は、すべてのデータをディスクから読み取る前にネットワークへの出力を 開始します)。 このオーバーラップ動作は、ディスクとネットワークのアクセス速度が同程度の 時にもっともうまく機能します。逆にどちらか一方が他方に比べて非常に高速な 場合は、あまり影響を持ちません。 デフォルトの値は 16384 ですが、この値を決めるために多数の実験を行った わけでは全くありません。また、この値についても、最適値はシステムに よって非常に異なると考えられます。ただし 65536 以上の値は意味がなく、 不必要なメモリを割り当てるだけの結果となってしまうでしょう。 転送の最大値 (max xmit) ----------------------- 起動時に、クライアントとサーバは "maximum transmit" サイズの ネゴシエーションを行います。この値は、ほぼすべての SMB コマンドに おける転送サイズの上限値となります。 smb.conf で "max xmit =" オプション を指定すれば、 Samba がネゴシエーションに用いるサイズの値を指定できます。 ただし、これは Samba が SMB 要求の最大値として受け入れる値であって、 「クライアントが受け入れる最大値」ではないことに注意して下さい。 クライアントが受け入れる最大値は、クライアントから Samba へ送られます。 Samba はこの制限値を用いることになります。 この値は、デフォルトでは 65536 (指定できる最大の値です) となっています。 しかしこの転送サイズを小さくすると、クライアントによっては性能が向上する こともあります。しかし 2048 よりも小さくすると、かなりまずい結果となる でしょう。 ほとんどの場合はデフォルトが最適のオプションだと思います。 ロッキング (locking) -------------------- デフォルトでは、 Samba は strict locking (厳密なロック動作) をそれぞれ の read/write 呼び出しに対して行うことはしません (以前のバージョンでは 行っていましたが)。 strict locking は "strict locking = yes" によって 有効になりますが、システムによっては非常に性能が低下することがあります。 性能の低下は、おそらく NFS マウントされたファイルシステムでより大きい でしょう。しかしローカルなディスクでも、大きな性能低下はありえます。 共有モード (share modes) ------------------------ ファイルのオープンに非常に時間がかかる、という報告がいくつかあるようです。 この原因は多くの場合、 "share modes" のコードが、 dos share mode 機能の フル実装を要求するからです。このコードは "share modes = no" とすることに よって無効にできます。これによってファイルのオープン・クローズはかなり 高速化されるでしょう。しかし一方で、あるユーザーが read-write オープン しているファイルを次のユーザがオープンしようとしたときに、システムは このオープンをリードオンリーに強制することができなくなるかもしれません (場合によっては、ですが)。独自のファイルロックを用いているアプリケー ションでは、これは問題になることはないでしょう。しかし問題になるアプリ ケーションもあるかもしれません。ほとんどの Windows アプリケーションは、 "share modes" が正しく動作していることを仮定しているので、この場合は Samba の share mode サポートをデフォルトの "on" にしておかなければ ならないでしょう。 Samba の share mode コードは 1.9.17 リリースで書き換えられました。 これは Ziff-Davis NetBench PC Benchmarking tool によるテスト結果を 反映したものです。 Samba 1.9.17 の share modes の実装は、 Windows NT とほぼ同様のものになっているはずです。 追記: より最近のバージョンでは、 share modes の実装に mmap() によって 共有メモリを用いるオプションが追加されています。これは動作をさらに高速 化します。これを有効にする方法については Makefile を見て下さい。 ログのレベル (log level) ------------------------ log level ("debug level" も同じ) を 2 以上にすると、性能は大きく低下 するでしょう。これはサーバがオペレーションのたびにログファイルをフラッ シュするからであり、これは非常に高くつく作業だからです。 リンクの追跡 (wide links) ------------------------- "wide links" オプションは、現在ではデフォルトで有効になっています。 (セキュリティを強化するために) 無効にすることもできますが、この場合は ファイル名の解決の性能が低下します。この性能の低下は "getwd cache = yes" とすることによって抑えることができます (この設定はデフォルトです)。 raw モードの読み込み (read raw) ------------------------------- "read raw" 動作は、ファイルの読み込み動作の反応を速くし、最適化する ために設計されたものです (ただしすべての SMB サーバに必須の機能では ありません)。 Samba ではデフォルトで有効になっていますが、オプション で無効にすることもできます。 クライアントによっては "read raw" をうまく扱うことができず、これまでの read 動作よりも性能が低下してしまうこともありえます。 ですから "read raw = no" としてみて、ネットワークがどうなるか試してみ ると良いでしょう。性能が低下するかもしれませんし、向上するかも、変化し ないかもしれません。これは実験してみないとわかりません。 raw モードの書き込み (write raw) -------------------------------- "read raw" 動作は、ファイルの書き込み動作の反応を速くし、最適化する ために設計されたものです (ただしすべての SMB サーバに必須の機能では ありません)。 Samba ではデフォルトで有効になっていますが、オプション で無効にすることもできます。 マシンによっては "write raw" が通常の書き込み動作よりも遅くなることも ありえます。この場合はオプションを変更すると良いでしょう。 先読み (read prediction) ------------------------ Samba は SMB コマンドのいくつかにおいて、先読み動作を行うことができます。 これは、 Samba サーバが SMB コマンドを待っている間に、最後に読んだ ファイルの余分なデータを読んでおくようになることを意味します。これに よって、次の読み込み要求が到着したときの反応が向上します。 これはデフォルトでは無効になっています。 "read prediction = yes" と することによって有効にできます。 先読みは、リードオンリーでオープンされたファイルに対してしか用いられ ません。 先読みは、ファイルからの読み込みを、少しずつ多数回行うような間抜けな クライアント (NT での「ライト(WRITE.EXE)」など) に対して特に有効でしょう。 Samba は "read size" オプションで指定された量以上の先読みは行いません。 また常に 1k ブロックの境界までの先読みを行います。 メモリマッピング ---------------- Samba はメモリマッピングによるファイルの読み出しをサポートしています。 マシンによっては、これによって性能が非常に向上します。全く変わらなかっ たり、逆に性能が落ちることもあるかもしれません。 有効にするには、 -DUSE_MMAP オプションを Makefile の FLAGS 行に指定して、 Samba を再コンパイルする必要があります。 メモリマッピングはリードオンリーでオープンされたファイルに対してのみ有効 です。また "read raw" 動作の際には用いられません。したがって、メモリ マッピングの方が有効であるかどうかを調べるには、 "read raw = no" として "read raw" を無効にする必要があります。 遅いクライアント ---------------- ある人のレポートによれば、プロトコルを LANMAN2 から COREPLUS に変更する ことで、劇的な速度の向上が見られたそうです (10k/s -> 150k/s)。 おそらく彼の PC (386sx16 ベース) は、扱うことのできるより以上のデータを 要求していたのでしょう。プロトコルを変えるのではなく、 "read raw = no" や "max xmit = 2048" とすることによってもおそらく同じような速度の向上が 期待できるのではないかと思います。 "read size" を減らすことも効果が あるでしょう。 ログインが遅い -------------- ログインが遅いのは、ほとんどすべての場合、パスワードのチェックに要する 時間のせいです。 "password level" を、実際に必要な最低限の値にすることに よって、速度は大きく向上します。 Makefile で "UFC crypt" オプションを 有効にすることもできます。 クライアントのチューニング -------------------------- 速度の問題はクライアントにあることも多いです。そのようなクライアント (例えば Windows for Workgroups) では、たいてい TCP の性能を向上させる ようなチューニングが可能です。 クライアントのドキュメントを注意して読んでください。特に、 WfWg の TCPWINDOWSIZE や TCPSEGMENTSIZE は、性能に非常に影響するらしいです。 何人かの報告によれば、 WfWg で SYSTEM.INI ファイルの [MSTCP] セクション 中の DefaultRcvWindow を 3072 に設定することによっても、大きな向上が 見られるそうです。理由は知りませんが。 個人的な経験では、 DefaultRcvWindow を大きな値 (16384 以上) にすること によって、ずっと性能が向上したことがありました。他の人々の報告では、 3072 以上ではずっと速度が低下するのだそうです。ある人によれば、 3072 から 8192 にすることによって速度が 1/30 にも低下することもあるのだそう です。理由はわかりません。 おそらくこれはハードウェアや、接続先の unix マシンのタイプに強く依存 するのでしょう。 私の結果 -------- このような文書においては、実際の数値を知りたい人も入るようですので、 ここに記しておきます。私は WfWg 3.11 に 3.11b の tcp/ip スタックを用いた 486sx33 クライアントを使っています。これは ISA バスのイーサネットカード SMC Elite-16 を使っています。 WfWg に対して私が行ったチューニングは、 system.ini [MSTCP] セクションの DefaultRcvWindow を 16384 だけです。 サーバは Linux の 486dx3-66 です (訳注 dx2 ?)。こちらは 20Mb の RAM と SMC Elite-16 を搭載しています。私のサーバの設定は、配布されている Samba の examples/tridge/ サブディレクトリを見て下さい。 8Mb のファイル copy で読み取ると、 490k/s という値になりました。 同じファイルを Samba サーバに書きこむときは、 441k/s でした。 もちろん単純なスループットの値以外にもベンチマークはたくさん考えられる でしょうが、とりあえずの目安にはなるでしょう。 Win95 や WinNT でも試してみたところ、 WinNT が Samba のクライアントと しては最速でした。しかしそれ以上の速度を示すクライアントが (私の場合に は) ありまして、それは他の linux マシンからの smbclient でした。いつか この文書にもそれらの結果を載せたいと思っています... ==翻訳者謝辞== 本文書の翻訳作業においては、 samba-jp ML 上でちゃぷさん、佐藤さん、 篠原さんより、数多くの貴重なご意見やご指摘をいただきました。