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