この記事では、以下の方法を学びます。

• Samba のパフォーマンスを測定する方法
• Samba のメモリー使用量を最適化する方法
• Server Message Block/Common Internet File System 環境におけるファイル転送速度を向上させる方法

この記事は、LPIC-3 Specialty「302 Mixed Environment Exam」試験の主題 315 の目標 315.3 の試験対策となります。この目標の重要度は 1 です。

前提条件

この連載記事を最大限に活用するには、Linux の高度な知識と、この記事で説明するコマンドを演習できる実際の Linux システムが必要です。また、TCP/IP ネットワーキングについて十分に理解している必要もあります。

上に戻る

Samba のパフォーマンス測定

何かの特性を改善するには、その特性を信頼できる方法で測定できなければなりません。その場合、まず特性を測定し、変更を行ってから再度測定して、その結果を比較するという作業を伴うからです。Samba のパフォーマンスを改善する場合には、以下の測定を行う必要があります。

• サーバーがアイドル状態にあるときにクライアントでの応答速度とスループット
• サーバーが特定の負荷状態にあるときにクライアントでの応答速度とスループット
• 特定の負荷がかかっているときのサーバーの特性
• クライアントの観点でのサーバーの最大キャパシティーまたはスループット

応答時間を測定することで、標準的なクライアントがテスト条件下で期待するパフォーマンスを知る手掛かりとなりますが、そのためには、テスト・ケースでの負荷を実際のクライアントの負荷に近づける必要があります。例えば、同じファイルを繰り返し要求する場合の速度は、小さなファイルと大きなファイルが混在するディレクトリーをコピーする場合の速度と同じではありません。

特定の負荷状態にあるサーバーの特性を測定すれば、サーバーにあとどれだけの負荷に対応する余地があるかがわかります。そのテストの時点で、サーバーが負荷の対処に苦労しているとしたら、そのテスト負荷が、サーバーのおおよその許容量ということになります。この手法は、本番サーバーの負荷を測定し、その許容量を推定するためにも使用されています。

サーバーに可能な限りの負荷をかけて、どこまで耐えられるかを調べる、いわゆる「耐久テスト」からは、興味深い情報を得られますが、他のタイプのテストほど有用ではありません。例えばサーバーが処理可能な最大負荷を証明することがテストの目的である場合は、こういった類のテストでも用が足ります。このようなタイプのテストがより有効なのは、大抵は下位レベルの特性 (サーバーの最大ディスク I/O 容量など) を測定する場合です。

Samba はネットワーク・サーバーであるため、使用するネットワークをある程度シミュレーションすることが重要です。サーバーからクライアントまでパケットが到達するのに 50 ミリ秒かかるとしたら、そのクライアントでのネットワーク遅延の影響はサーバー・ローカルのクライアントの場合よりも明白になります。このような情報は、チューニングの優先順位を左右します。

テストの方法を検討する

かなり高価な機器を購入すれば、クライアントのトラフィックをシミュレーションして正確なパフォーマンスを測定することができます。ベンチマークを発表する場合や、サーバー・ハードウェアを開発する場合には、そのような機器を使用するのが適切な選択かもしれませんが、使用中のサーバーをチューニングすることが目的で、しかも例によって時間と資金に限りがある場合には、あらためて使い方を学ばなければならない高価なツールを購入しようとは思わないはずです。

一例として、最初のテストでは Samba のコマンドライン・クライアントで多数のファイルをダウンロードして、ランダム読み出しのパフォーマンスを評価します。このテストの一番の関心事は、「特定のディレクトリーの最大ダウンロード速度」です。

正常に動作する他の UNIX ユーティリティーの場合と同様に、smbclient ツールは標準入力から命令のリストを読み取ることができます。以下のスニペットに、ディレクトリーの中身をダウンロードするための一連のコマンドを示します。

prompt
recurse
mget smbtest

prompt コマンドを実行すると、クライアントがユーザーに対してダウンロードの確認を要求しなくなります。次の recurse コマンドは、ディレクトリー内にある複数のファイルをダウンロードする際に内部のディレクトリーもたどるように指示します。最後の mget smbtest は、クライアントに対し、smbtest ディレクトリーのダウンロードを開始するように命令するコマンドです。あとは、このディレクトリーに数百メガバイトのテスト・ファイルを入れておけば、パフォーマンスをテストすることができます。

テストを実行するには、smbclient で共有に接続し、標準入力をファイルにリダイレクトする必要があります。リスト 1 に、その方法を示します。

$ time smbclient '\\192.168.1.1\test' password < instructions 
Domain=[BOB] OS=[Unix] Server=[Samba 3.5.8-75.fc13]
getting file \smbtest\file2 of size 524288000 as file2 (5323.2 kb/s) (average 5323.2 kb/s)
getting file \smbtest\file1 of size 139460608 as file1 (5275.3 kb/s) (average 5313.0 kb/s)

real	2m2.289s
user	0m0.509s
sys	0m4.580s

リスト 1 のコマンドの先頭にある time コマンドは、引数の残りの部分で指定されているコマンドの実行時間を測定します。測定されるコマンド自体は smbclient です。このコマンドの引数としては、共有の名前とユーザーのパスワードを指定します。標準的な引数も追加できるので、例えばパスワードではなくユーザー名を渡さなければならない環境では、-U を追加してユーザー名を渡します。最後の < instructions は、smbclient の標準入力を instructions という名前のファイルにリダイレクトします。これは、最初のコード・スニペットに示された命令が含まれているファイルです。このコマンドを実行すると、複数のファイルが一括コピーされて、その所要時間が測定されます。

このコマンドを実行した結果、転送されたファイルの情報とともにファイルあたりの平均転送速度が出力されます。time コマンドによる出力が最後に表示されており、約 664MB のファイルをコピーするのにかかったのがウォールクロック時間で 2 分 2.289 秒であることが示されています。これが、ベンチマークです。何らかの変更を行った後、テストの時間が 2 分 2 秒より長くなるとしたら、その変更によってパフォーマンスを悪化させていることになります。

テストごとにローカル・ディスクとキャッシングの影響が変わらないようにして Samba のパラメーターだけをテストしたい場合には、テストを数回実行して最後の測定値を取得してください。そうすることで、オペレーティング･システムによって最大限のキャッシングが行われ、ディスク・アクセスが最小限の状態になります。また、変更をテストする際には、必ずサーバー上の空きメモリーと同じくらいの空きメモリーがあるようにしてください。そうでないと、キャッシュされるデータ量の違いによって、実験の結果が変わってしまう可能性があるためです。

Samba のステータスを表示する

サーバーの CPU、メモリー、ディスク、およびネットワーク情報を調べることで、サーバー自体の正常性に関する情報は十分に得られますが、アプリケーションが何をしているかについては何もわかりません。Samba には、現行の接続とファイル・アクティビティーを明らかにする、smbstatus という有用なユーティリティーが用意されています。このユーティリティーは、パフォーマンス･チューニングおよびトラブルシューティングにも役立ちます。

リスト 2 に、smbstatus コマンドの使用例を示します。

$ smbstatus
lp_load_ex: refreshing parameters
Initialising global parameters
params.c:pm_process() - Processing configuration file "/etc/samba/smb.conf"
Processing section "[global]"
Processing section "[homes]"
Processing section "[printers]"
Processing section "[extdrive]"

Samba version 3.5.8-75.fc13
PID     Username      Group         Machine                        
-------------------------------------------------------------------
17456     fred         fred       macbookpro-d0cd (::ffff:192.168.1.167)

Service      pid     machine       Connected at
-------------------------------------------------------
fred         17456   macbookpro-d0cd  Mon Jul 18 07:36:46 2011
extdrive     17456   macbookpro-d0cd  Mon Jul 18 07:36:46 2011

Locked files:
Pid    Uid   DenyMode   Access      R/W        Oplock      SharePath   Name   Time
----------------------------------------------------------------------------------
17456  505   DENY_NONE  0x100081    RDONLY     NONE        /home/fred   .  
17456  505   DENY_NONE  0x100081    RDONLY     NONE        /home/fred   Documents

リスト 2 には、Samba サーバーの現行のアクティビティーが示されています。この出力によると、現在接続しているユーザーは fred というユーザーだけで、このユーザーは 2 つの共有 (fred と extdrive) をマウントしています。また、2 つのディレクトリーがロックされています。

上に戻る

ネットワークのチューニング

Samba は主としてネットワークでパケットを送受信するデーモンです。Samba がパケットを送信する方法や、ベースにあるオペレーティング・システムとやりとりする方法は、いくつかのパラメーターによって変更することができます。これらのパラメーターは、パフォーマンスに大きな影響を及ぼします。

基本的なオプション

多くのデーモンは、すべてのクライアントにできる限り最高レベルのサービスを提供し、クライアントを分け隔てしません。サービスが過負荷状態になると、すべてのクライアントに提供するサービスのレベルが低下します。それとは対照的に、電話網で輻輳が発生した場合には、新たに電話をかけようとしてもつながらない一方、現在行われている通話は何事もなかったように続けられます。Samba の場合、特定のオプションで制限をすることで、リソースが枯渇に近づくという事態を防ぐことができます。

max connections パラメーターは、特定の Samba サーバーへの許容接続数を制限します。それぞれの接続がメモリーおよび CPU リソースを消費するため、接続数が多すぎると、サーバーが過負荷状態になる可能性があります。デフォルトでは、接続数は制限されていません。サーバーがビジー状態にならないようにする必要がある場合には、max connections で接続数のハード・リミットを指定することで対処することができます。

max smbd processes は、実行できるプロセスの最大許容数を制御するパラメーターです。このパラメーターは max connections と同様ですが、接続数ではなく、接続によって生じるプロセス数を制御するという点が異なります。

log level でログ・レベルを高くすると、ログをディスクに書き込むために使われるサーバー・リソースが多くなります。このパラメーターの値を 1 または 2 に維持しておくことで、ディスクに書き込まれるログの量が制限され、クライアントに提供するためのリソースをより多く確保しておくことができます。

ソケット・オプションを設定する

アプリケーションは、オペレーティング・システムにネットワーク接続のオープンを要求するときに、そのオペレーティング・システムに特定の方法でパケットを扱うように要求することもできます。そのための手段となるのが、ソケット・オプションです。ソケット・オプションを使用すると、ネットワーク・パフォーマンスの微調整を有効/無効にしたり、パケットに特定のサービス品質ビットをセットしたり、ソケットにカーネル・レベルのオプションを設定したりすることができます。

socket options コマンドは、パケットの TOS (Type Of Service: サービス･タイプ) ビットを制御することができます。TOS ビットはルーターに対し、トラフィックの処理方法を指示します。ルーターが TOS ビットに従うように構成されていれば、アプリケーションが要求する方法に従ってトラフィックを処理することができます。このコマンドに指定するキーワードとしては、LAN などの低遅延ネットワークには IPTOS_LOWDELAY、それよりも遅延の大きい WAN リンクには IPTOS_THROUGHPUT が最適です。ネットワークの構成によっては、これらのオプションの効果が逆になる場合もあります。

TCP_NODELAY オプションは Nagle アルゴリズム (詳細については「参考文献」のリンクを参照) を無効にするため、頻繁にデータをやり取りする「チャッティーな」プロトコルには適しています。ただし、送信されるパケットが増えるという犠牲を伴います。

ファイアウォールやその他の機器でネットワークの状態を保持している場合には、TCP キープアライブを有効にする SO_KEEPALIVE オプションを検討することができます。定期的に送信されるキープアライブ・パケットは接続をオープン状態に保ち、ファイアウォール内でネットワークの状態を最新に保ちます。接続がオープン状態に保たれないとしたら、ファイアウォールがパケットを破棄することになります。その場合、クライアントがサーバーに再接続しなければならないことを認識するまでに多少の時間がかかることになります。

上に戻る

チューニング以外の作業

さまざまに設定を変えて、最適な構成になるように試すのは面白い作業かもしれませんが、Samba の構成以外のところに、パフォーマンスの妨げとなっている原因がある可能性もあります。サーバーがディスクからデータを読み取ってクライアントに送信する、あるいは着信ネットワーク・トラフィックを受け取ってディスクに書き込むという処理以外のことを行っているとしたら、それによって処理時間を長引かせていることになります。

Ethernet のエラー

送信中のパケットが失われると、カーネルはパケット損失を通知して、パケットの再送信を要求するという処理を行わなければなりません。このプロセスは、送信側と受信側の間に大きな遅延が存在する場合にはなおのこと、両者間のやりとりの速度を低下させる可能性があります。パケット損失の一般的な原因の 1 つは、スイッチとサーバーとの間で設定が一致していないことです。具体的には、オート・ネゴシエーションで正しい一致が見つからないこと、あるいはスイッチとサーバーのいずれか一方が静的に設定されていているにも関わらず、もう一方がオート・ネゴシエーションを続けていることなどが考えられます。この不一致により、スイッチとサーバーの両方でエラーが発生する結果になります。このようなエラーを見つけるには、netstat コマンドを使用することができます。

# netstat -d -i 2
Kernel Interface table
Iface       MTU Met    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
eth1       1500   0  5258404      0      0      0  3024340      0      0      0 BMRU
eth1       1500   0  5258409      0      0      0  3024341      0      0      0 BMRU
eth1       1500   0  5258411      0      0      0  3024342      0      0      0 BMRU

このコードには、2 秒間隔でインターフェース・エラーを探すために -d -i 2 パラメーターを設定した、多目的の netstat コマンドが示されています。このコマンドにより、使用可能なインターフェースのステータスが 2 秒おきに表示されます。上記の例に示されている RX-OK 列と TX-OK 列は、それぞれ受信したパケットと送信したパケットの数を示しています。エラー (ERR)、破棄 (DRP)、オーバーロード (OVR) を表す列は、送信側でも、受信側でもすべて 0 であるため、パケット損失は発生しなかったことを示しています。

エラーが示された場合には、mii-tool または mii-diag を実行して、使用されている速度やデュプレックス・モードを調べてください。リスト 3 に、ネットワークの設定を調べる方法を示します。

# mii-tool 
eth1: negotiated 100baseTx-FD, link ok
# mii-diag eth1
Basic registers of MII PHY #24:  3000 782d 0040 6177 05e1 41e1 0003 0000.
 The autonegotiated capability is 01e0.
The autonegotiated media type is 100baseTx-FD.
 Basic mode control register 0x3000: Auto-negotiation enabled.
 You have link beat, and everything is working OK.
 Your link partner advertised 41e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
   End of basic transceiver information.

リスト 3 では最初に mii-tool コマンドを実行してアクティブ・インターフェースの要約を取得しています。その結果から、インターフェースが 100baseTx の全二重でネゴシエーションされていたことがわかります。次に実行している mii-diag は、もっと詳細な情報を出力します。問題をネットワーク・チームに上げなければならない場合には、この出力のほうがネットワーク・チームに送付する情報としては適しています。mii-tool コマンドを使用すれば、速度とデュプレックス・モードを変更することができますが、実際にはリンクにオート・ネゴシエーションを行わせたほうが賢明です。

TDB ファイルを維持する

Samba が状態を記録するために使用する簡易データベース (TDB) ファイルについては、「Linux の 302 (Mixed Environment) 試験対策: 簡易データベース (TDB) ファイル」で説明しました。簡易データベースで問題が発生すると、サーバーは不要なディスクを調べるなどの余計な作業を行う羽目になるか、あるいはリモート・サービスからの情報をキャッシングできなくなります。幸い、TDB ファイルの破損を調べて、問題がある場合にはそれを修正することができます。一時 TDB ファイルは、Samba をシャットダウンした後に削除することができます。これらのファイルは、起動時に再作成されます。その他のファイルについては、必ずバックアップを実行してから、tdbbackup -v を使ってファイルを検証してください。

クライアントを調べる

クライアントがパフォーマンスを低下させる原因になることもあります。例えば、クライアントにデュプレックスの問題があることや、マルウェアがあること、あるいはその他の問題が発生していることがあります。テストで一貫したクライアントを使用すると、パフォーマンス低下の潜在的原因からサーバーを除外する上で有効です。

上に戻る

まとめ

LPIC の 302 試験に関する連載は、今回の記事で最後です。これまでに書き留めたノートを復習して試験を受けてください。健闘を祈ります！

参考文献

学ぶために

• smb.conf の man ページに、この記事で取り上げたコマンドのその他の例および詳しい説明が記載されています。
  
  
• Samba クラスターを構成すると、処理可能な負荷を増やし、サーバー障害の影響を小さくすることができます。
  
  
• Performance Dynamics の Gunther 博士がその著書で、パフォーマンス分析およびチューニングについて詳説しています。LPIC の 301 試験から、彼の PDQ 分析方式についてはご存知のことでしょう。
  
  
• Nagle アルゴリズムは、ネットワーク速度に計り知れない影響を及ぼすことが可能です。
  
  
• LPIC Program サイトでは、LPI の 3 つの Linux システム管理資格認定レベルについて、詳しい目標、タスクのリスト、そして出題例を調べられます。特に、LPI-302 の詳細な目標について調べてください。
  
  
• developerWorks の連載「LPI exam prep」をすべて読んで、Linux の基礎を学び、2009年4月以前の LPI 試験の目標に基づくシステム管理者認定試験に備えてください。
  
  
• developerWorks Linux ゾーンで、Linux 開発者および管理者向けのハウツー記事とチュートリアル、そしてダウンロード、ディスカッション、フォーラムなど、豊富に揃った資料を探してください。
  
  
• さまざまな IBM 製品および IT 業界についての話題に絞った developerWorks の Technical events and webcasts で時代の流れをキャッチしてください。
  
  
• 無料の developerWorks Live! briefing に参加して、IBM の製品およびツール、そして IT 業界の傾向を素早く学んでください。
  
  
• developerWorks の on-demand demos で、初心者向けの製品のインストールとセットアップから、熟練開発者向けの高度な機能に至るまで、さまざまに揃ったデモを見てください。
  
  
• Twitter で developerWorks をフォローするか、developerWorks で Linux に関するツイートのフィードに登録してください。
  
  

製品や技術を入手するために

• オープンソースのパフォーマンス・テスト・ツールを探しているとしたら、opensourcetesting.org によるこのリストを調べてください。
  
  
• Wireshark は、現在出回っているパケット分析ツールのなかで最も優れたツールです。これを使用して、サーバーが送受信しているパケットを調べてください。
  
  
• IOzone ファイルシステム・ベンチマークは、ストレージの速度を調べるのに役立ちます。
  
  
• 30 日間使用できる IBM Rational Performance Tester 試用版をダウンロードして、システム・パフォーマンスのボトルネックを突き止めてください。
  
  
• ご自分に最適な方法で IBM 製品を評価してください。評価の方法としては、製品の試用版をダウンロードすることも、オンラインで製品を試してみることも、クラウド環境で製品を使用することもできます。また、SOA Sandbox では、数時間でサービス指向アーキテクチャーの実装方法を効率的に学ぶことができます。
  
  

議論するために

• developerWorks コミュニティーに参加してください。ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者が主導するブログ、フォーラム、グループ、ウィキを調べることができます。
  
  

著者について

Sean Walberg はネットワーク・エンジニアであり、ネットワークについて 2 冊の本も書いています。これまで医療やメディアをはじめ、さまざまな業界に携わってきました。

この記事を評価する

コメント

上に戻る

目次

• 前提条件
• Samba のパフォーマンス測定
• ネットワークのチューニング
• チューニング以外の作業
• まとめ
• 参考文献
• 著者について
• コメント