それマグで！

知識はカップより、マグでゆっくり頂きます。　takuya_1stのブログ

習慣に早くから配慮した者は、 おそらく人生の実りも大きい。
トップ > Sambaが遅いのでパフォーマンスチューニング

Sambaが遅いのでパフォーマンスチューニング

サンバの設定ファイルsmb.confにSPEEDに関する事はこっち嫁と書いてあった。

smb.conf
185 # Most people will find that this option gives better performance.
186 # See smb.conf(5) and /usr/share/doc/samba-doc/htmldocs/speed.html

だからspeed.htmlを読んでみた。

speed.htmlを導入する＠ubuntu

$>sudo aptitude install samba-doc

これでspeed.htmlをインストールする。で読み始める

speed.html

げげ、全部英語じゃん。日本語訳がない。仕方ない翻訳するよ。一年ぶりだな翻訳。

要約すると

    • Sambaなめんな
    • デフォルトで最適値だぞ
    • Sambaが遅いと疑う前にネットワークとOSの状態を調べろ
    • 誰かがそれで出来た。と言ってても闇雲に信用するな。
    • 自分でやってパフォーマンステストしろ

とまぁ当たり前のことが書いてありました

2009-09-23追記

現在のSamba設定を確認する簡単な方法。"testparm -v"

takuya@v1046r:~$ testparm -v

Load smb config files from /etc/samba/smb.conf
Processing section "[homes]"
Processing section "[printers]"
Processing section "[print$]"
Loaded services file OK.
Server role: ROLE_STANDALONE
Press enter to see a dump of your service definitions

[global]
        dos charset = CP850
        unix charset = UTF-8
        display charset = LOCALE
        workgroup = WORKGROUP
        realm =
        netbios name = V1046R
        netbios aliases =
        netbios ...
...

これを使っていまロードされているSamba設定を確認するとよい。たいていは十分な高速化がなされていると思う。何だかんだ言って、LANの速度UPが一番良いみたい。

和訳：Chapter 44. Samba Performance Tuning

Chapter 44. Samba Performance Tuning
44 章：Samba パフォーマンス チューニング
Paul Cochrane
Dundee Limb Fitting Centre


Jelmer R. Vernooij
The Samba Team


John H. Terpstra
Samba Team

Table of Contents
Comparisons 比較
Socket Options ソケット設定
Read Size 受信サイズ
Max Xmit 最大Xmit
Log Level ログ
Read Raw 読み込み。
Write Raw 書き込み
Slow Logins 遅延ログイン
Client Tuning クライアント側チューニング
Samba Performance Problem Due to Changing Linux Kernel LinuxでのSamba高速化の課題
Corrupt tdb Files TDBファイルの破損
Samba Performance is Very Slow Sambaの処理は遅い

Comparisons 比較

The Samba server uses TCP to talk to the client, so if you are trying to see if it performs well, you should really compare it to programs that use the same protocol. The most readily available programs for file transfer that use TCP are ftp or another TCP-based SMB server.

SambaサーバーはTCP通信でクライアントPCと通信します。転送状態が良好か調べたいとき、本当なら同じ通信プロトコルで速度比較するべきです。TCP通信で比較に利用しやすい通信はFTPや別のSambaサーバーです。

If you want to test against something like an NT or Windows for Workgroups server, then you will have to disable all but TCP on either the client or server. Otherwise, you may well be using a totally different protocol (such as NetBEUI) and comparisons may not be valid.

WindowsのNTドメインやワークグループサーバーとのテストしたいときは、クライアントかサーバーでTCP通信以外を利用しないことが必要です。TCP通信を使わない場合、全く別のプロトコル（NetBEUIなど）を利用した通信であり、全く比較になりません。

Generally, you should find that Samba performs similarly to ftp at raw transfer speed. It should perform quite a bit faster than NFS, although this depends on your system.

ふつうは、SambaはFTPの転送速度と同じくらいのパフォーマンスを体感できる。それはNFSよりちょっと速く、PCやネットワークの状態や性能に依存するが、それくらいは出るはずだ。


Several people have done comparisons between Samba and Novell, NFS, or Windows NT. In some cases Samba performed the best, in others the worst. I suspect the biggest factor is not Samba versus some other system, but the hardware and drivers used on the various systems. Given similar hardware, Samba should certainly be competitive in speed with other systems.
SambaとNovelのNFS、SambaとWindowsNTを比較した人がいて、ある実測ではSambaの速度が一番で、別の計測ではSambaが最下位だったそうだ。たぶん、このような結果の原因はSambaそのものではなく、ハードウェアやドライブの性能じゃなかろうか。同一ハードで検証するとSambaは他システムとでも十分に競争できる。

Socket Options
ソケット設定

There are a number of socket options that can greatly affect the performance of a TCP-based server like Samba.

SambaのようなTCP通信を使うサーバソフトに対しては、その性能に大きく影響を与えるソケット設定がたくさんある。

The socket options that Samba uses are settable both on the command line with the -O option and in the smb.conf file.

Sambaのソケット設定は 起動時に-O　オプションを指定するか、smb.confに記述することも出来る。

The socket options section of the smb.conf manual page describes how to set these and gives recommendations.
smb.confのドキュメントにソケットの章があり、そこでどのように設定をするか、するべきか書いてある。⇒つまりSmb.confのマニュアル読めってこと。

Getting the socket options correct can make a big difference to your performance, but getting them wrong can degrade it by just as much. The correct settings are very dependent on your local network.

ソケット設定の修正で転送速度は改善・改悪のどちらも起こりえる。適切な設定はネットワークの状態に強く依存することを念頭に置くように。

The socket option TCP_NODELAY is the one that seems to make the biggest single difference for most networks. Many people report that adding socket options = TCP_NODELAY doubles the read performance of a Samba drive. The best explanation I have seen for this is that the Microsoft TCP/IP stack is slow in sending TCP ACKs.

ソケット設定のTCP_NODELAYが、殆どのネットワークでsingle differenceになる可能性が高い。TCP_NODELAY設定がSambaの速度を2倍に引き上げたと数多くの報告があがってる。
これはMicrosoftのTCP/IPスタックがTCP ACKsで遅いことが主な原因である、と説明されている。

There have been reports that setting socket options = SO_RCVBUF=8192 in smb.conf can seriously degrade Samba performance on the loopback adaptor (IP Address 127.0.0.1). It is strongly recommended that before specifying any settings for socket options, the effect first be quantitatively measured on the server being configured.

ソケット設定をSO_RCVBUF=8192にしたばあい、LoopBackアドレス（localhostのIP 127.0.0.1)へのSambaのパフォーマンスが最悪になることが報告されている。ソケット設定を確定する前に、まずサーバーで設定の効果を十分に測定すること。

Read Size
読み込みサイズ

The option read size affects the overlap of disk reads/writes with network reads/writes. If the amount of data being transferred in several of the SMB commands (currently SMBwrite, SMBwriteX, and SMBreadbraw) is larger than this value, then the server begins writing the data before it has received the whole packet from the network, or in the case of SMBreadbraw, it begins writing to the network before all the data has been read from disk.

読み込みサイズ設定は設定は、ネットワークからの読書とディスク読書の発生タイミングに影響を与えます。SMB コマンド(今のところSMBwrite, SMBwriteX, and SMBreadbraw)が受け取ったデータサイズがこの設定より大きいとき、SMBはファイルをディスクに書き込みます。この書込が全パケット到着前に発生します。SMBreadbrawの場合は、ディスク読込完了前にネットワークへパケットを送出します。

This overlapping works best when the speeds of disk and network access are similar, having little effect when the speed of one is much greater than the other.

この読み書きのタイミングを一致していることが一番望ましく、ネットワーク速度とディスク性能に極端な差があるとき、僅かながら速度向上に役立ちます。


The default value is 16384, but little experimentation has been done as yet to determine the optimal value, and it is likely that the best value will vary greatly between systems anyway. A value over 65536 is pointless and will cause you to allocate memory unnecessarily.

デフォルト値は16384です。この設定の最適値が少しだけテストされていて、システムによってその最適値は大幅に違う事が分かっています。65536以上は、メモリの割り当てに失敗し、ポインタアドレスが消失するので設定できません。

Max Xmit
最大転送サイズ

At startup the client and server negotiate a maximum transmit size, which limits the size of nearly all SMB commands. You can set the maximum size that Samba will negotiate using the max xmit option in smb.conf. Note that this is the maximum size of SMB requests that Samba will accept, but not the maximum size that the client will accept. The client maximum receive size is sent to Samba by the client, and Samba honors this limit.

Sambaサーバーとクライアントが通信開始時に、最大転送サイズを決定します。このサイズは、大半のSMBコマンドに効力が及びます。Sambaが最大Xmitサイズを使って通信サイズを決定するようにsmb.confに記述することが出来ます。注意点として、クライアントとの最大サイズ決定で、この最大サイズまでを受け付けます。しましクライアント側の受け付け可能な最大サイズではありません。クライアント側からSambaサーバーへの送信で受け付ける最大サイズです。

It defaults to 65536 bytes (the maximum), but it is possible that some clients may perform better with a smaller transmit unit. Trying values of less than 2048 is likely to cause severe problems. In most cases the default is the best option.

デフォルト値は最大値65536 です。ただし、いくつかのSambaクライアントでは、小さめの値がよりパフォーマンス向上につながることがあるようです。ただし２０４８より小さな値にすると、とんでもない問題を引き起こします。殆ど全ての場合はデフォルト値が最適値です。

Log Level
ログ通知レベル設定。

If you set the log level (also known as debug level) higher than 2, then you may suffer a large drop in performance. This is because the server flushes the log file after each operation, which can be quite expensive.

デバッグ用のログレベルを２以上に設定したら、大幅なパフォーマンス劣化で困ることになります。これはSamba操作毎にログ書込と書込フラッシュが起こることになります。ログ書込負荷はとても大きなものになります。

Read Raw
Read Rawオプション

The read raw operation is designed to be an optimized, low-latency file read operation. A server may choose to not support it, however, and Samba makes support for read raw optional, with it being enabled by default.

Read Rawも最適化されています。ファイル操作の遅延時間が最小になるように設計されています。サーバーＯＳでRead Rawオプションが操作できない設定のとき。SambaサーバーでRead Rawを設定する事が出来ます。このとき、Read Rawオプションが有効になります。

In some cases clients do not handle read raw very well and actually get lower performance using it than they get using the conventional read operations, so you might like to try read raw = no and see what happens on your network. It might lower, raise, or not affect your performance. Only testing can really tell.

たまに、クライアントがRead Rawをうまく扱えないことがあります。そのときパフォーマンスは低下します。この場合は、サーバー＆クライアント側でやりとりして決定していまが。クライアント側の問題であるがサーバー側でRead RawをNoに設定したいと考えるはずです。そしてネットワークのパケットをみたいと考えるはずです。しかし、これはパフォーマンスにたいした変化を与えません。やってみて結果を見てください。


Write Raw
Write Rawオプション

The write raw operation is designed to be an optimized, low-latency file write operation. A server may choose to not support it, however, and Samba makes support for write raw optional, with it being enabled by default.
Write Rawも最適化されています。書込の遅延が最小になるように設定されています。
サーバーOS側がこれを設定しないとき、Samba側でこの設定が有効になり、Write Raw
オプションが提供されます。

Some machines may find write raw slower than normal write, in which case you may wish to change this option.
サーバーによっては、通常書込よりSamba書込が遅くなるものが中にはあります。そのときこのオプションを変えてみてください。


Slow Logins
ログインがトロい
Slow logins are almost always due to the password checking time. Using the lowest practical password level will improve things.

ログインが遅いとき、ほとんどがパスワードチェックによるものです。必要最小限なパスワードの長さにしてみましょう。改善するかも。

Client Tuning
クライアント側の調整。

Often a speed problem can be traced to the client. The client (for example Windows for Workgroups) can often be tuned for better TCP performance. Check the sections on the various clients in Samba and Other CIFS Clients.
Samba Performance Problem Due to Changing Linux Kernel

クライアント側がパフォーマンス低下の原因であることもあります。（たとえばWindowsのワークグループ設定など）クライアント側がTCPのパフォーマンスを改善すれば、パフォーマンス調整が可能な場合も在るようです。SambaサーバーがCIFSやSambaクライアントなどいくつものセッションを受け付けていてる場合など。Sambaのパフォーマンス問題はLinuxカーネルを変えることが原因になることもあるようです。

A user wrote the following to the mailing list:
MLに届いてたユーザーからの質問を紹介します。

I am running Gentoo on my server and Samba 2.2.8a. Recently I changed kernel versions from linux-2.4.19-gentoo-r10 to linux-2.4.20-wolk4.0s. Now I have a performance issue with Samba. Many of you will probably say, “Move to vanilla sources!” Well, I tried that and it didn't work. I have a 100MB LAN and two computers (Linux and Windows 2000). The Linux server shares directories with DivX files, the client (Windows 2000) plays them via LAN. Before, when I was running the 2.4.19 kernel, everything was fine, but now movies freeze and stop. I tried moving files between the server and Windows, and it is terribly slow.
GentooでSamba2.28aを動かしています。最近、カーネルバージョンをlinux-2.4.19-gentoo-r10 からlinux-2.4.20-wolk4.0sへ変えたんですが、Sambaの速度に問題が起きました。SambaユーザーMLでは「バニラソースをどこかにやってから来い」（甘いこと言ってんじゃねーよ！ってことかな？）といわれるのでしょうが、もちろんパフォーマンス関連のオプションは試しました。100MのLANでWindows2000とLinuxを使っています。クライアントはLAN経由でつながったWindows2000です。2.4.19カーネルで動かすと、問題ありませんでした。しかし、現バージョンにしたとたん、ムービーがフリーズが発生し、また再生が完全ストップするようになりました。ファイルをLinuxとWindows間で転送してみましたが、これが半端無く遅いのです。

The answer he was given is:
この質問に寄せられた回答がコレです。

Grab the mii-tool and check the duplex settings on the NIC. My guess is that it is a link layer issue, not an application layer problem. Also run ifconfig and verify that the framing error, collisions, and so on, look normal for ethernet.
mii-toolをつかってみなよ、NICの設定におかしなところがないか、もう一度調べてみて。
たぶん、僕の予想があったっていれば、リンク層の問題だと思うな。ifconfigを叩いてみてさ、IOフレームにエラーや衝突がないか調べてみなよ。イーサネットの問題だと思うよ。

Corrupt tdb Files
TDBファイルの破損

Our Samba PDC server has been hosting three TB of data to our 500+ users [Windows NT/XP] for the last three years using Samba without a problem. Today all shares went very slow. Also, the main smbd kept spawning new processes, so we had 1600+ running SMDB's (normally we average 250). It crashed the SUN E3500 cluster twice. After a lot of searching, I decided to rm /var/locks/*.tdb. Happy again.

うちのSambaのPDCサーバーは３ＴＢのデータが載っていて、５００人以上のユーザーがWindowsXp/2000/NTで利用しています。現在Samba利用で3年になりますが、目立った問題は発生していません。しかし、今日、全てのファイル読み書き速度が著しく低下し、SmbdがSwapプロセスを発生し続けました。結局1600以上のSmbdプロセスが走っていました。（ちなみに通常時だと２５０程度です。）そしてSUNのE3500サーバーを二度もクラッシュさせました。労力を費やして調べた結果。/var/locks/*tdbを消しことにしました。そして再び全てがうまく動作するようになりました。

Question: Is there any method of keeping the *.tdb files in top condition, or how can I detect early corruption?

質問:*.tdbファイルの状態をチェックし正常な状態を維持する方法はありますか。またどうやって以上検知すればよろしいでしょうか。

Answer: Yes, run tdbbackup each time after stopping nmbd and before starting nmbd.

回答：そうですね。nmbdの停止後にtdbbackupを叩いて、それからnmbdを開始するようにするとイイでしょう。

Question: What I also would like to mention is that the service latency seems a lot lower than before the locks cleanup. Any ideas on keeping it top notch?

質問：私が聞きたいことは、ロックの解除時にサーバーの遅延が激しくなるようです。常に速度を維持したいのですが何かいい手はありますか。

Answer: Yes. Same answer as for previous question!
回答。さっきの回答と同じ対応でうまくいきますよ。

Samba Performance is Very Slow
Sambaの速度性能がイマイチです。

A site reported experiencing very baffling symptoms with MYOB Premier opening and accessing its data files. Some operations on the file would take between 40 and 45 seconds.

あるサイトで、MYOB Premierがファイルを開いて、書き込んでいました。いくつかの読み書きが40から45秒以上かかるのです

It turned out that the printer monitor program running on the Windows clients was causing the problems. From the logs, we saw activity coming through with pauses of about 1 second.

これは、Windowsに常駐するプリンタの監視プログラムが原因だと分かりました。ログを見ると1秒おきにアクセスしやがっていました。

Stopping the monitor software resulted in the networks access at normal (quick) speed. Restarting the program caused the speed to slow down again. The printer was a Canon LBP-810 and the relevant task was something like CAPON (not sure on spelling). The monitor software displayed a "printing now" dialog on the client during printing.

プリンタの状態モニタプログラムがネットワークの遅延原因とおもわれますプリンタの監視プログラムを停止したところ速度が回復しました。しかし、プリンタの監視プログラムを起動するとまたネットワークの遅延が発生しました。プリンタはキャノンのLBP-810です。そして、プリンタの監視プログラムはCAPONです（スペルはうろ覚えです）プリンタのモニタプログラムは「PrintingNow（印刷中です）」と表示するだけのプログラムです。

We discovered this by starting with a clean install of Windows and trying the application at every step of the installation of other software process (we had to do this many times).

今回、この調査に、Windowsをクリーンインストールし、プログラムを一つ入れてはSamba利用をテストする事を繰り返しました。すんごく時間かかった。

Moral of the story: Check everything (other software included)!
すぐ、Sambaサーバーの所為にしないという、モラルのお話でした（全てを調べる。他のソフトウェアも含めて）