|
前回の記事を掲載後、いくつかのご指摘を読者の方々から戴いた。IDE Busmasterが動作しない件だが、簡単にまとめると
・RedHat 7.2のままでも、カーネルを2.4.9-31に上げると解決する。
・RedHat 7.3ではこの問題は発生しない。
・デフォルトのままだと、FTP/HTTPと比較してSambaのパフォーマンスが上がらない可能性がある。ただしこれは簡単にチューニング可能である。
といったところで、ほかにも
・FreeBSD Release 4.5は未対応だが、開発中の 4.6-PRERELEASE 最新版では対応コードが入っている模様(なので試してくれ)
というメールも戴いた。さすがにFreeBSDは今回の話から外れる(というか、そこまでやってしまったら人柱の方の興味を奪ってしまう)し、RedHat 7.3も完全にOS入れなおしになるので今回は勘弁させていただくとして、最初の2つについて追試を行なった結果をご紹介したい。(編集部注:FreeBSDについては4.5Rで問題なく動作しているというレポートを読者からいただきました)。
ここでSambaのチューニングと言っているのは、http://www.samba.gr.jp/doc/contrib/tuning.htmlで示されている内容である。簡単に言ってしまえば、デフォルト状態のSambaのパラメータがWindowsのNBT(NetBIOS Over TCP/IP)に最適化されていないので遅くなるという話である。そこでこれをチューニングすれば、高速になる「かもしれない」(上記ページでも、「必ず高速化される」とは言っていない)わけで、ちょっとチャレンジしてみる価値があるだろう。
ただしその前に、現状確認である。まずFTPでの転送速度だが、Windows XP標準のFTPコマンドを使って、700MBのファイルのUpload/Downloadを行なった結果 (写真1)
Upload :約2,096KB/sec
Download:約2,150KB/sec
という惨憺たる結果。次にHTTPだが、ApacheサーバーからIriaを使って同じダウンロードした結果は約1,427KB/secという、更に壊滅的な結果(写真2)。これはもうHTTPがどうの、Sambaがこうのという以前の話で､とにかくHDDアクセスが遅すぎるとしか思えない。ちなみにクライアントマシンの環境がちょっと変わったのでHDBenchを取り直した結果(写真3)をみると、Read 1.8MB/Sec、Write 1.9MB/Sec出ており、Sambaは遅いというよりむしろ健闘したといって差し支えなく、この時点でチューニングをしたからといって、性能が改善される可能性は低そうだ。
 |
 |
 |
| 【写真1】Iriaだとアップロードができないので、素直にWindows XP標準のftpコマンドを利用した | 【写真2】ちょっとクライアントのPC2を英語版Windows XPに入れなおしてしまった関係でメニューが化けている。ご容赦いただきたい | 【写真3】前回より微妙に数字が落ちてるが、まぁこれは誤差の範囲。別にSambaだけが飛びぬけて遅いわけではないことは確認できた |
RedHat 7.2の場合、製品出荷後のアップデートは、http://www.jp.redhat.com/support/errata/rh72/ にまとめられている。このうち、カーネルのアップデートが行なわれているのは、2002年2月27日付けの「2.4カーネルのアップデート」である。そこでここから当該モジュール(今回の場合、i386なのか、i586なのか、i686なのかの判断がハッキリしないので、とりあえずi586用パッケージを突っ込んだのだが、どうも後で見てみるとi686用だったらしい。ただ実際のCPUがVIA C3ということを考えると､i386用でもよさそうな気も……)
とにかく入手してrpmコマンドを実行すると、エラーメッセージが出て怒られてしまう(写真4)。modutilsパッケージとtuxパッケージが古いようだ。ということで、まずは「kernel2.4のアップデート(kernel-2.4.9-21/modutils-2.4.10-1/tux-2.2.0-1)」からtuxの2.2.0-1と、「New modutils packages available(modutils-2.4.13-0.7.1)」からmodutils 2.4.13-0.7.1を入手、それぞれをインストールした。その後に、もう一度Kernel 2.4.9-31をインストールすると、今度は問題なくインストール完了である(写真5)。その後再起動すると、ちゃんと2.4.9-31カーネルで問題なくブートした。
 |
 |
| 【写真4】つれないエラーメッセージ。ただこれで、modutilsとtnxという2つのモジュールの更新が必要と判るから十分ではある | 【写真5】3つのパッケージをRedHatのサポートサイトからダウンロードし、/tmpに置いておき一気にアップデートをかける。ダウンロードの時間を除くと、大体作業は10分程度である |
さて更新したところで、再びhdparmコマンドを掛けると、11.64MB/secだ(写真6)。大幅に向上した……と言って良いか、ちょっと判断に苦しむところ。少なくとも20MB/sec台、本来なら30MB/secオーバーの性能が出ないとおかしいだけに、この結果はちょっと納得いかないところがある。
ただこのあたりに詳しい人の話では、RedHatのIDEドライバ周りはかなり頻繁に変わっているので、古いバージョンだとあまり性能が出なくても不思議ではないとの事。RedHat 7.3では25MB/secを越えたという報告もあるので、このバージョンであれこれ苦しむより、RedHat 7.3なり他のディストリビューション(Vine Linuxで30MB/sec越えした、という話もいただいた)に乗り換えるといった対策の方が賢明そうだ。
ちなみにこの状態で、ふたたびクライアントからのアクセス速度も測定してみた(写真7)。まずFTPでは
Upload :約9,163KB/sec
Download:約10,617KB/sec
と大幅に性能が改善。httpでのダウンロードも、約10MB/secとこちらもほぼHDDのスピードの限界まで出た。(写真8)
では、気になるSambaの成績はというと、Read 6.79MB/Sec、Write 6.92MB/Secとなった(写真9)カーネル入れ替え前に比べれば3倍以上のスピードだが、Windows XPの8MB/secに及ばないのはちょっと不満が残るところ。そこでSambaのチューニングを行なってみることにした。
 |
 |
| 【写真6】確かにUltraDMAは有効になったのだが、たったの10MB/sec?? | 【写真7】圧倒的なスピード。ちなみに、Eden533上での操作も圧倒的に快適になった |
 |
 |
| 【写真8】なぜかIriaが急に不調になってしまったので、IEを使ってダウンロードしてみた。ピークで10.2MB/sec、アベレージでほぼ10MB/secに達している | 【写真9】数字はともかく体感速度で8MB/secと6MB/secは、それほど大きな差はない。結構これでも使い物になるとはいえる |
さてSambaのチューニングにあたっては、まず現状でのMSS(Maximum Segment Size)を知る必要がある。上記のページでは、tcpdumpを使ってこれをサンプリングする、という話だったので、さっそく
tcpdump -i eth1 > /tmp/a.log
とかを仕掛けて、転送を仕掛けた結果､MSSは1,460Byteと判明した(リスト1)。そこで、SO_SNDBUF=2920(MSSの2倍)というパラメータを記述したIncludeファイルを追加してSambaを再起動し、再びHDBenchをとった結果は、Read 6.88MB/Sec、Write 6.85MB/Sec(写真10)とチューニング前と大差のない結果となった。微妙に高速化しているとは言えるが、誤差の範囲とも言えなくもない。
 |
| 【写真10】sambaチューニング後のベンチマーク結果 |
|
【リスト1】ログの一部 19:13:48.128820 192.168.20.2.1083 > 192.168.20.1.netbios-ssn: P 2312369754:2312369852(98) ack 3161250821 win 63943NBT Packet (DF) 19:13:48.128820 192.168.20.1.netbios-ssn > 192.168.20.2.1083: P 1:108(107) ack 98 win 5840NBT Packet (DF) 19:13:48.128820 192.168.20.2.1083 > 192.168.20.1.netbios-ssn: P 98:174(76) ack 108 win 63836NBT Packet (DF) 19:13:48.128820 192.168.20.1.netbios-ssn > 192.168.20.2.1083: P 108:147(39) ack 174 win 5840NBT Packet (DF) 19:13:48.128820 192.168.20.2.1083 > 192.168.20.1.netbios-ssn: P 174:219(45) ack 147 win 63797NBT Packet (DF) 19:13:48.128820 192.168.20.1.netbios-ssn > 192.168.20.2.1083: P 147:186(39) ack 219 win 5840NBT Packet (DF) 19:13:48.128820 192.168.20.2.1083 > 192.168.20.1.netbios-ssn: P 219:317(98) ack 186 win 63758NBT Packet (DF) 19:13:48.128820 192.168.20.1.netbios-ssn > 192.168.20.2.1083: P 186:293(107) ack 317 win 5840NBT Packet (DF) 19:13:48.128820 192.168.20.2.1083 > 192.168.20.1.netbios-ssn: P 317:380(63) ack 293 win 63651NBT Packet (DF) 19:13:48.128820 192.168.20.1.netbios-ssn > 192.168.20.2.1083: . 293:1753(1460) ack 380 win 5840NBT Packet (DF) 19:13:48.128820 192.168.20.1.netbios-ssn > 192.168.20.2.1083: . 1753:3213(1460) ack 380 win 5840NBT Packet (DF) 19:13:48.128820 192.168.20.2.1083 > 192.168.20.1.netbios-ssn: . ack 3213 win 64240 (DF) 19:13:48.128820 192.168.20.1.netbios-ssn > 192.168.20.2.1083: P 3213:4452(1239) ack 380 win 5840NBT Packet (DF) 19:13:48.318820 192.168.20.2.1083 > 192.168.20.1.netbios-ssn: . ack 4452 win 63001 (DF)
|
(2002年5月13日)
[Reported by 槻ノ木隆]
