[samba-jp:22537] Re: Samba4の動作要件とチューニング要素

[Kenichi Okuyama]

奥山です。
アレ、MLの方に出し忘れてた…荒巻さん、同じ内容を受け取ることになってごめんなさい。

>> じゃぁ、中間でいっぱいバッファリングさせるとどうなるか…と言うと、Round Trip Time が派手にばらつきます。
> すいません。中間でバッファリングさせるとは，どういう意味ですか？

L2, L3..の別を問わず、スイッチ・ルーターの類は Store & Forward 方式を取っています。つまり一度パケットを全部受け取り、
ヘッダを解析して正しいポート経由で送出するわけです。という事は「パケットを受け取るためのバッファ」がある事になります。

1GbEが3つつながっているスイッチを考えてください。ポート1とポート2がたまたまどちらもポート3宛てのパケットを、
これまたたまたま同じタイミングで受け取ったとします。全ポート同速度ですから、片方は送れます。でももう一方は?
当然まだ送れません。片方が終わるのを待たなくちゃいけない。でもポート1もポート2もどちらも「次のパケット」が後ろから来ている…。

このような状況の際に「未送出なパケットを一時的に蓄えておくバッファ」がスイッチにはあります。
そうする事で、パケットが簡単にロストしないようにしている。
優秀なスイッチになると、このバッファのサイズを変更する事もできます。

特に速度が異なるネットワーク間をブリッジするスイッチでは、速い⇒遅い方向の速度変化が起こっている部分で滞留が
起こりやすいので、このバッファがたっぷりあると有効です。ところが、バッファが大きいと

- パケットがほとんど溜まっていない ⇒ すぐ送出の順番が回ってくるので待ち時間が短い
- パケットがいっぱいたまっている ⇒ 送出の順番がなかなか回ってこないので待ち時間が長い

という現象が起こって、end-to-end で見ると送ってから受け取るまでに掛かる時間がものすごくばらつくことになります。

バラつかないようにするにはバッファが大きくなくても簡単に溢れないようにすればよいので、Ethernet には PAUSE Frame
というものがあります。ただし、これ、サポートしているスイッチやNICとサポートしていないスイッチ・NICが混在している
ネットワークですとサポートしていない部分でパケットが落ちることになり…

まぁ、今回はスイッチが1つだけとのことですので、そのスイッチが「優秀である」事を祈るしかありません。


>> 一方で、メモリ容量を大きくすると必ず「メモリの動作速度が遅くなる」という拘束条件が発生します。
> これって，どういう理屈ですか？

メモリ容量を増やすという事は、メモリカードを「たくさん」刺すという事です。

という事はマザーボード上で、メモリコントローラーとの配線距離が長いメモリカードと
短いメモリカードが出てきます。正確にはメモリカードスロットがチップセットから遠い奴と
近い奴が出てきます。

配線距離にばらつきが少なければ高速に通信できるのですが、配線距離にばらつきがある場合、
そのばらつきを吸収できるレベルにまでメモリバスの動作クロックを落とさなくてはいけません。

結果として「メモリ動作速度が遅くなる」のです。

基本的にこの辺りの調整は BIOS/EFIが自動的にやってくれます。ですので「早い速度で動作するメモリ」を
沢山刺しても、自動的に「低速度モードで」メモリを動かしてくれます。なので、ほとんどの人は意識しないでしょう ( w )
お金の無駄ですけどね。



> 今後は実機計測して評価はするのかなと思いますが，にしても
> 机上でも前提条件付きだとしても動作要件を整理しとかんと，計測したときに
> マシンをうまいことつかえてるのかつかえてないのかもわかりませんので。

でも、その辺りは Samba のバージョンが変化しただけで変動します。
ＯＳ Kernel のバージョンが上がっても変動します(というかスケジューラー関係が変化すると変動幅が大きい)。



あと、チューニングにおいて注意しなくてはいけない点が1つ。
「チューニングの目標をどう立てるのか」


昔、あるお客様の所で、「ストレージを新しくしたら性能が大幅に劣化した!」という問題がありました。
遅いストレージを、新しくて速いストレージにしたら性能が出ない、と言うんですね。

調べた結果判ったのは、昔の「遅いストレージ」の場合、応答速度やデータがやってくる速度が遅いために、
サーバ側の swap IO 等の処理が間に合っており、実にすばらしいタイミングでメモリが必要量解放されていた。
素晴らしいバランス、素晴らしいチューニング。

が、これを新しいストレージにしたら、応答速度が速すぎて swap IO が追い付かず、メモリが必要な速度で
解放できなくなった。しょうがないのでOSは read only な領域…ファイルキャッシュですとか、実行プログラムの
一部ですとか…を破棄するようになった。これらは必要になったら「また読んでくれば良い」イメージですから。

短期的にはそれでもいいんですが、この状態が長期化すると、全体の性能が急激に落下します。
「再び読んでくる」必要があるという事は、その部分を処理する速度＝disk IO速度になり、
一気に遅くなるという事ですから。



チューニングされたシステムと言うのは特定の条件下では素晴らしい性能を示します。
が、ちょっと条件が変化しただけでも性能はがた落ちします。

なので、様々な環境、変化する環境で利用するサーバーは、あえてデチューン…性能が落ちるように
バランスをわざと崩してやります。
と言ってもでたらめに崩すのではなく、環境が変化したり、構成機材の一部が早くなったり遅くなったりしても
トータルの性能が大幅にふらつかないように、各所にあえて余裕を持たせておきます。
あえて「うまいこと使いきれていない」部分を作っておいて、ちょっとした変動はそこに吸収させるわけです。

でも、特定環境で「だけ」使うなら…そのような余裕は全部そぎ取るのが正解です。


この辺りは、サーバーを作る人の腕の見せ所です ( w )
頑張ってください。