[ Samba ]
!==
!== 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 上でちゃぷさん、佐藤さん、
篠原さんより、数多くの貴重なご意見やご指摘をいただきました。