Using Samba Robert Eckstein, David Collier-Brown, Peter Kelly 共著 第一版 1999 年 11 月 1-56592-449-5, 注文番号: 4495 416 ページ, 34.95 ドル ハードコピー版(英語)を購入する 目次

Appendix B Samba のパフォーマンスチューニング

 

---

B.2 Samba のチューニング

それでは、どのようにして高速なネットワークパッケージを入手して、それを更に高速化するかについて議論しよう。

B.2.1 ベンチマーク

ベンチマーク神秘な、ある意味暗黒の芸術といえよう。しかし簡単なチューニングを行うのであれば専門的知識に熟達していなくとも可能である。Samba サーバの目的がファイルを転送することにある以上、ベンチマークにおいて着目するのはスループットだけでよく、特定イベントに対する応答時間はその必要がない。ファイルの転送速度を計測するのは比較的用意である。応答時間はより洗練されたテクニックを必要とすることが多いが、Samba のレスポンス時間はそれほど悪いものではない。

この作業に関する基本的な考え方は、以下のようなものである:

• コピーを行う適切な大きさのファイルと smbclient等のコピー速度を計測できるプログラムを選ぶ。

• テストにかかる典型的な時間を計測する。

• 各種バッファを予め利用しておくため、各テストを何回か事前実行する。

• テストを何回か行い、異常値の発生を監視する。

• 各実行結果を詳細に記録する。

• 正常な実行結果の平均値を期待される結果と比較する。

この方式を用いて基準値(baseline)を確定したら、特定の1パラメータを調整し、全ての計測を再実行する。読者の試験用に、本章の最後では空の表が提供されている。

B.2.2 チューニングするポイント

理論的にSambaには完全なサーバを模索する際に利用可能な設定の組合わせが数千通りも存在するが、このセクションで一覧する、スループットに影響すると考えられるオプションに限定することが可能である。オプションは、おおよその影響度に応じて説明していく。

B.2.2.1 Log level

これは非常に影響度が大きいオプションである。ログのレベルを増加させる(log level もしくは debug level 設定オプション)ことは、パフォーマンスの問題以外の問題の解析を行うのには適した対策である。Chapter 4, ディスク共有で述べたように、レベル3より大きくすると、Sambaは膨大な量のデバッグメッセージを生成する。これをディスクやsyslogに書き出すのはとても遅い処理になる。我々の行った smbclient/ftpのテストで、log level を0から3にすると、チューニング前の get 処理の速さが get speed645.3から622.2KB/sになり約5パーセントの低下となった。より大きなlog levelの指定は更に大きな影響をおよぼすことになる。

B.2.2.2 Socket options

次に考慮すべきものは、 socket options設定オプションである。このオプションは実際のところホスト側のチューニングオプションであるが、コネクション単位で設定されるものであり、 socket options = オプション を smb.conf ファイルの [global]セクションに追加することで Samba の動作するソケットの設定を行うことが可能である。以下のオプションの中にはベンダによっては提供されていないものもあるので、ベンダの setsockopt (1) もしくは socket (5)のマニュアルページで詳細を確認すること。

主なオプションは以下の通りである:

TCP_NODELAY

サーバが遅延を少なくするために適宜パケットを送信するようにする。これはtelnet接続で応答時間の向上をもたらしたり、あまり直観的でないが、小さな要求パケットが送られたり(Microsoft TCP/IP で発生するように)送達確認(ACK)が遅延したりする場合にもそれなりの速度を維持したりするために用いられる。これは 30-50 パーセントのスピードアップの効果がある。なお、Samba 2.0.4 においては、 socket options = TCP_NODELAYがこのオプションのデフォルト値である。

IPTOS_LOWDELAY

これはスループットを低下させても遅延を少なくするためのオプションであり、オプションを設定したサーバではなく、ルータや他のシステムの動作に影響する。IPTOSのオプションは新規のオプションであり、全てのOSやルータでサポートされているわけではない。サポートされている場合は、 TCP_NODELAY を設定する際に IPTOS_LOWDELAY も設定する。

SO_SNDBUF および SO_RCVBUF

送信および受信バッファはOSの規定値よりも大きい値に設定することが可能な場合がある。これにより(それが性能限界点を越えない範囲では)多少の速度向上が見込まれる。

SO_KEEPALIVE

クライアントが存在していることを確認するためのチェックを定期的(15分間隔)に行うかどうかを制御する。期限切れのコネクションは、Samba の keepalive と dead time オプションで処理を行った方がよい。どのオプションも、最終的には応答のないコネクションをクローズし、空費されているメモリとプロセステーブルのエントリをOSに返却する。

他にも幾つかのソケットオプション(例えば SO_SNDLOWAT) があるが、それらはベンダによってその機能が異なっている。Samba のパフォーマンスチューニングのためにこれらのオプションについて更に調査を行いたい場合は、恐らく TCP/IP Illustrated(monyo訳注:書籍名) を参照するとよいであろう。

B.2.2.3 read raw と write raw

これは重要なパフォーマンス設定オプションであり、Samba がネットワークとの読み書きする単位を1つのSMBリクエストで最大64KBまで拡大する。これには、最大のSMBパケット構造体であり、このオプションの名前の由来ともなった SMBreadraw と SMBwriteraw が必要である。これば UNIX用語の raw read とは異なるので注意すること。UNIX用語では、通常ディスクをファイルシステムを介さずに読むことを意味するが、これは Sambaの read raw とは全く異なった意味になる。

以前のクライアントのプログラムの中には read raw を用いると異常動作するものがあった。知る限りにおいて、この問題が発生するクライアントはもはや存在しない。read raw と write raw はデフォルトで yes になっており、クライアント側で問題が発生しない限りはそのままにしておくべきである。

B.2.2.4 Opportunistic locking

Opportunistic locks, or oplocksにより、クライアントがファイルをローカルにキャッシュすることが可能になり、パフォーマンスが30%のオーダーで向上する。このオプションは現在デフォルトで有効になっている。読み込み専用のファイルに対しては、 fake oplocks により、同様の機能が実際にキャッシュを行うことなく提供される。キャッシュできないファイルがある場合、 oplocks は無効にすることもできる。

データベースファイル、サーバとクライアントの両方から更新を行うファイル、変更が即座に反映されなければならないファイルは絶対にキャッシュしてはならない。これらのファイルに対しては、 veto oplock files オプションにより、個々のファイルやワイルドカードを用いたパターンによって、キャッシュを行わないファイルを指定することができる。クライアントにキャッシュしたくないファイルが大量に存在する場合、 oplocks を共有ベースで無効にすることも可能である。oplock についての詳細な情報はChapter 5, ブラウジングと高度なディスク共有 を参照のこと。

B.2.2.5 IP packet size (MTU)

ネットワーク上の個々のパケットのサイズには通常上限が設定されている。これは最大セグメントサイズ(Maximum Segment Size)とよばれ、パケットへッダのサイズも含めた場合は最大トランスポートユニット(Maximum Transport Unit (MTU))と呼ばれる。この MTU は Samba が設定するものではないが、Samba needs to use a max xmit (write size) bigger than the MTU, or throughput will be reduced. これに関する詳細な議論は、以下の注で記述する。MTU は通常イーサネットにおいては 1500 バイト、FDDI においては 4098 バイトに設定されている。一般的に小さくしすぎるとスループットが悪化し、大きくしすぎてもフラグメンテーションと再送により突然パフォーマンスが悪化する。

ルータ越えの通信を行う場合、ルータが専用線(T1等)に接続されている勝手に仮定して、MTUを536バイト前後にしてしまうシステムがある。Windows 95 もそれであり、クライアントが同一ネットワークにある場合はよいパフォーマンスを示すが、ルータ越えのクライアントに対しては顕著に性能が悪化する。クライアントが反対の設定ミスを行い、小さい MTU であるべき回線で大きい MTU を設定してしまうと、パケットは幾つかの断片に分割される。これは転送速度を低下させ、ネットワークのエラーが発生すると、複数の断片が再送されるため、Samba の速度が顕著に遅くなる。Windows のMTUサイズを変更することで、こうしたエラーを避けることが可能である。この話題についての詳細を理解するには、 http://www.stanford.edu/~llurch/win95netbugs/faq.htmlにある"The Windows 95 Networking Frequently Asked Questions (FAQ)"を参照のこと。どのようにして Windows の MTU やウインドウサイズを変更するかについての説明がある。

B.2.2.6 TCP 受信ウインドウ

TCP/IP はデータを小さいパケットに分割してマシン間を転送することで動作する。パケットを分割する際にはチェックサムが含まれるため、受信者がパケットのデータをチェックして転送中に発生しうるエラーを検出することが可能になっている。通常パケットを受信して整合性の検査を行うと、送達確認のパケットが送信者に対して返却され、"全パケットが完全に到着したので、送信を続行してほしい"という情報を伝達する。

ただし、通信を円滑に行うため TCP には、送信者が各パケット毎に送達確認を待たずに送信することができるパケット数(ウインドウ)という概念が存在する。(これにより、複数の送達確認をまとめて同時に送信者に送ることが可能になる。)言い方を変えると、この受信ウインドウとは送信者が受信者の送達確認を待たずに送信可能なバイト数である。MTU と同様、これはコネクションのタイプに応じて自動的に設定される。ウインドウを小さくしすぎると、送達確認のメッセージを不必要に待機することになる。様々なOSでソケット毎に適切なサイズのバッファが割り当てられ、プログラムがメモリを喰い尽くさないようになっている。

バッファサイズはバイト単位で割り当てられ、例えば SO_SNDBUF=8192 のように socket options 行で指定する。 socket options 設定オプションは以下のように設定する:

socket options = SO_SNDBUF=8192 

通常は、このソケットオプションをデフォルト値よりも大きく設定する。デフォルト値は SunOS 4.1.3 や SVR4では、4098(monyo訳注4096の誤りでは??), AIX や Solaris、BSD では 8192-16384 である。とりあえず 16384 にしてみることを推奨する。Steven の書籍中で記述されているテストでは、Sambaとは直接関係ないものの40パーセントの性能向上を達成している。サイズを大きくしすぎると性能はかえって低下するので、この値の設定にはある程度の経験が必要である。これを図示したのが 図 B.1 である。これはある Linux システムにおいて行われたテストである。

Figure B.1: SO_SNDBUF サイズとパフォーマンス

O_SNDBUF(monyo訳注SO_SNDBUF) と SO_RCVBUF のソケットオプションをデフォルト値より小さくすることは推奨できない。これらの値を大きくしていくことでネットワークによる上限に達するまでは性能が向上する。ただしこの上限に達してしまったら、パフォーマンスは急に低下する。

B.2.2.7 max xmit

Samba において、MTUとウインドウサイズに直結するオプションが max xmitである。このオプションは Samba が一度に書き込む最大のデータブロックサイズを設定する。このサイズは write sizeと呼ばれることもあるが、Samba の設定オプション中の同名のパラメータとは関係ない。

各ブロック中に必要なオーバーへッドの割合はブロックが大きくなるほど減少するため、max xmit は可能な限り大きくすることが望ましい。デフォルト値はプロトコルの上限値であり、これは 64キロバイトである。顕著な速度低下を招かない範囲での最小値は、2048である。この値を小さくしすぎると、Samba がネゴシエートした最大パケットサイズの上限値を制約してしまうことになる。これは、信頼できないネットワーク接続をテストする場合に小さいMTUをシミュレーションするときに利用できる。ただし、こうしたテストは有効なMTUを減少させるため、実運用では行うべきではない。

B.2.2.8 read size

max xmit が一般的に write size と呼ばれるならば、 read size は Samba がネットワーク経由でクライアントから読み出し可能なデータの最大量ということになるが、実際はそうではない。このオプションは write ahead の開始トリガを決定するものである。つまり Samba がある一定量以上にディスクから読み出してネットワークに書き込むと(あるいはその逆をすると)、ネットワークへの書き込みと同時にディスクからの読み込み(あるいはその逆)を開始する。

read size は UNIX においてそれほどパフォーマンスに影響を与えないが、この値を非常に小さくした時は別であり、明らかなパフォーマンスの低下を引き起こす。このため、デフォルト値は 2048 になっているが、これを 1024 以下にしてはいけない。

B.2.2.9 read prediction

直感的でないこともあって、このオプションは廃止された。このオプションにより、Samba はクライアントが読み込み専用でオープンしたファイルの先読みを行うことが可能になった。このオプションは、oplock と重複したため、Samba 2.0 (及び 1.9 の後期)からは廃止された。

B.2.2.10 write cache size

このパラメータは、Samba 2.0.7 で公開され、RAIDディスクの書き込みサイズをチューニング可能とするだけでなく、大量のメモリはあるがディスクが遅いというマシンの書き込みキャッシュサイズにも同様に適用される。

このオプションは、Samba がoplock されたファイル毎に作成する書き込みキャッシュのサイズを設定する。これにより、大量の書き込みが可能になり、パフォーマンスが非常に向上する。

smbd は同時に 10 個までの書き込みキャッシュを作成することが可能である。それぞれのキャッシュが指定したサイズで作成され、10 個の oplock されたファイルに割り当てられる。一般的なファイルシステムのキャッシュと同様、データが書き込まれる前にクラッシュした場合、ファイルが破壊される。

sync always を設定することで、書き込みキャッシュを無効にすることができ、strict sync を設定することで、Windows クライアントに対しても書き込みキャッシュを無効にできる。しかし、Windows の Explorer ではデフォルトで sync ビットがオンになっているため、strict sync を設定するとパフォーマンスに多大な影響が発生する。

新しいオプションであることもあってか、パフォーマンスの向上に関する報告はあまり多く受けていない。もしかしたらこれはあまり意味がないオプションかも知れない。

B.2.3 その他の Samba のオプション

以下の Samba のオプションは、debug level のように誤って設定されているとパフォーマンスに影響をおよぼす。以下の記述によって、何を確認すればよいかを理解できるであろう:

hide files

Windows クライアントから隠したいファイルを判別するパターンを設定する。 hide files はパターンにマッチした全てのファイルに対してDOSの隠しファイル属性をつけた形でクライアントに返却する。そのため、ディレクトリを一覧すると個々のファイル毎にパターンマッチングが必要となり、サーバの応答を悪化させる。

lpq cache time

lpq (printer queue contents) コマンドの実行が完了するまでに時間がかかる場合は、 lpq cache time の値を lpq を実行するのに必要な時間よりも長くすることで、lpqの実行中にSambaが別のlpqを開始してしまうことを避けられる。 デフォルト値は10秒だが、これは妥当な値だと考えられる。

strict locking

strict locking オプションを設定することで、Sambaはクライアントから問い合わせられた時だけでなく、アクセスの度にロックをチェックするようになる。このオプションは基本的にバグを避けるためのものでり、バグのあるDOSやWindowsのアプリケーションが共有ファイルを壊してしまうことを避けられる。しかし、このオプションはSambaの動作を遅くするので、通常は避けるべきである。

strict sync

strict sync を設定することで、クライアントがパケット中にsyncビットを設定している場合、Sambaが各パケットを(monyo訳注:キャッシュせずに)ディスクに書き込むとともに書き込みが完了するまで待機するようになる。Windows 98 のエクスプローラはこのビットを全てのパケットにつけてしまうので、このオプションを有効にすると、Windows 98 の利用者は Samba が非常に遅いと感じるようになるだろう。

sync always

sync always を設定することで、Samba は全ての書き込みの度にディスクへのフラッシュを行うようになる。これはサーバが頻繁にクラッシュする場合は適切な措置であるが、パフォーマンスに与える影響は大きい。SMB はクラッシュの悪影響を避けるために、通常oplockと自動再接続を用いているため、通常このオプションは不要である。

wide links

wide links を無効にすると Samba は共有内のファイルから共有外のファイルに対するシンボリックリンクが禁止する。UNIXにおけるシンボリックリンクは特にセキュリティ上の問題はないので、デフォルトではこのオプションは有効になっている。 これを無効にすると、ファイルをオープンする度に追加の処理が必要となる。wide links を無効にするのであれば、要求されるデータをキャッシュするために getwd cache を有効にすること。

follow symlinks というオプションも存在し、これは全てのシンボリックリンクの追跡を禁止する。ただし、このオプションにパフォーマンス上の問題はない。

getwd cache

このオプションは現在のディレクトリへのパスをキャッシュすることで、それを発見するためのディレクトリツリーの探索を避ける。プリンタサーバの場合や、 wide linksを無効にしている場合は、このオプションがパフォーマンスの向上につながる。

B.2.4 我々の推奨

以下の smb.conf ファイルは推奨するパフォーマンス向上策を盛り込んだものである。右側にはコメントを付加した。

[global] 
	log level = 1                      # Default is 0 
	socket options = TCP_NODELAY IPTOS_LOWDELAY 
	read raw = yes                     # Default 
	write raw = yes                    # Default 
	oplocks = yes                      # Default 
	max xmit = 65535                   # Default 
	dead time = 15                     # Default is 0
	getwd cache = yes
	lpq cache = 30
[okplace] 
	veto oplock files = this/that/theotherfile
[badplace] 
	oplocks = no

---

B.1 簡単なベンチマーク		B.3 Samba サーバのサイジング

---