[netatalk-ja:0479] Re: ZFS ARCとの組み合わせ

[なまえだよ]

特に記載がなかったのでApple製品以外のNICを想定していませんでした…。
Small Treeの製品は独自のドライバを使用しているため、
システムのネットワークスタックにどのような影響を及ぼしているのかは実機がなければ検証が難しい気がします。
ドライバ(のkext)によって様々な独自のチューニングが行われているようなので、
一般のOS X向けのチューニングとの相互作用はメーカーにしかわからないでしょうね。

これ以上はメーリングリストの趣旨に沿うかどうかわかりませんが、
Small Tree製品はsysctlだけでは操作できない部分をstexutilコマンドで設定するそうです。
# stexutil getConfig の結果を示したりすると、誰かがアドバイスできるかもしれません…

2015年6月12日 16:22 Yoshiyuki HARAOKA <haraoka ＠ gmail.com>:
> ちなみに、10GbEだと
> nvram boot-args="ncl=131072"
> も圧倒的に遅くなりますね…
> GbEだと最適なのかもしれませんが…
>
> 2015-06-12 14:57 GMT+09:00 Yoshiyuki HARAOKA <haraoka ＠ gmail.com>:
>>
>> あー、お久しぶりです。
>>
>> MTUは当然9000以上にしてます。基本的には(デバイスによって)9216ですね。
>> net.inet.tcp.delayed_ack=0
>> が邪悪なのは重々承知しております。
>> しかし、1や2だと望んだ結果になりませんね。
>> Mac側の10GbEもchelsioにした方がよいのかもしれませんが、とりあえず
>> Promise SanLink2とかSmall-Treeですね…
>>
>>
>> 2015-06-08 12:29 GMT+09:00 なまえだよ <namaedayo00+netatalk ＠ gmail.com>:
>>>
>>> 以前勉強会でお会いしましたね。お久しぶりです。なまえだよです。
>>>
>>> net.inet.tcp.delayed_ack=0 は設定としては少し邪悪(Fairnessではないという意味)なので注意が必要です。
>>> 私が数年かけて調整した設定ではこうなりました。
>>> /etc/sysctl.conf
>>>
>>> net.inet.tcp.delayed_ack=2
>>> net.inet.tcp.win_scale_factor=8
>>> net.inet.tcp.autorcvbufmax=16777216
>>> net.inet.tcp.autosndbufmax=16777216
>>>
>>> デフォルトのバッファサイズでは少し足りないので
>>> $ sudo nvram boot-args="ncl=131072"
>>> を実行してNVRAMに値を書き込んで再起動する必要があります。
>>>
>>> // 元に戻す際は $ sudo nvram boot-args=""
>>>
>>> 10GBASE-T以上であればJumbo frameを有効にすべきとも思います。
>>> MTU 9000くらいが安定的だとは思いますが…他の端末の状況も考慮されるべきですね。
>>>
>>> なまえだよ
>>>
>>> 2015年6月8日 10:40 Yoshiyuki HARAOKA <haraoka ＠ gmail.com>:
>>> > ARM版NAS4FreeとかだとRAMを大きくしても、せいぜい4GBが最大なんですよねぇ。
>>> > そうすると、ZFSのARCを止めないと使い物にならないのですが、
>>> > それだとNetatalkのreadが使いものにならないし、現状非常に悩ましいです。
>>> >
>>> > パフォーマンスを上げる方法をOS X側にも問題あるという前提でも調べてみましたが、
>>> > /private/etc/sysctl.conf
>>> > に
>>> >
>>> > net.inet.tcp.delayed_ack=0
>>> >
>>> > を追加してみましたところ、ARCを止めてない状況でのAFPでのアクセスが
>>> >
>>> > 割りと速くなりました。
>>> > ARCを止めると結果は同じなんですが…
>>> >
>>> > こういったOS X側のチューニングでパフォーマンスを改善する方法って
>>> >
>>> > 他におすすめのレシピみたいなのってありますかねぇ?
>>> >
>>> >
>>> > はらおか
>>> >
>>> >
>>> >
>>> >
>>> > 2015-05-28 23:38 GMT+09:00 i <oichinokata ＠ oichinote.com>:
>>> >>
>>> >> 追加実験をしてみました。最初に実験した時は、SMB1でした…。
>>> >>
>>> >> Netatalk3.1.7, Samba3.6.25(SMB1/SMB2), Samba4.1.18(SMB2/SMB3)で実験しています。
>>> >>
>>> >> ZFSのL2ARCの効果も調べる : プラスα空間
>>> >> <https://oichinote.com/plus/2015/05/effect-of-l2arc-on-zfs.html>
>>> >>
>>> >> ZFSのL2ARCの効果も調べる(SMB編) : プラスα空間
>>> >>
>>> >> <https://oichinote.com/plus/2015/05/effect-of-l2arc-on-zfs-via-smb.html>
>>> >>
>>> >> たしかに、Netatalkだと、キャッシュをOffにした時にReadの方が、速度低下率が大きい様に見えます。
>>> >>
>>> >> SambaだとRead/Writeで差があまりありません。
>>> >>
>>> >> キャッシュをOffにすると、何故か速度が上がるなど、不可解な現象があります。
>>> >>
>>> >> 実験したものの、結論は出せずです。
>>> >>
>>> >> お市のかた
>>> >>
>>> >> > 2015/05/28 0:44、Decomo <ml ＠ decomo.info> のメール：
>>> >> >
>>> >> > Decomoです。
>>> >> >
>>> >> > ・FreeBSD 10.1
>>> >> > ・Netatalk 3.1.7
>>> >> > ・Samba 4.1 (max protocol = SMB2)
>>> >> > ・2.5” HDD x 2のミラープール + SSD ZIL
>>> >> > ・ARC 5GB
>>> >> > ・OS X 10.9.5
>>> >> >
>>> >> > 上記環境でARCをON/OFFし、OSXからafp/cifsで古のXbenchしてみた所
>>> >> > 確かにreadだけ極端に遅くなる現象が出ました。
>>> >> > しかし、NetatalkとSambaで落ち込み方は同傾向のようでした。
>>> >> >
>>> >> > ARCを切ったときにreadが遅くなるのは、単純にDMUによるプリフェッチが
>>> >> > 効かなくなるからだと思われます。primarycache=metadataとして、
>>> >> > メタデータだけをARCに置いても読み込み速度は然程回復しないので、
>>> >> > やはりデータプリフェッチの影響が大きいのではないかと。
>>> >> > （聞きかじり程度の知識なのでハズしてる可能性があります。）
>>> >> >
>>> >> > Sambaに影響しないというのは・・・分かりません。
>>> >> >
>>> >> > --------
>>> >> > Decomo
>>> >> > ml ＠ decomo.info
>>> >> >
>>> >> > 2015/05/25 17:47、Yoshiyuki HARAOKA <haraoka ＠ gmail.com> のメール：
>>> >> >
>>> >> >> 原岡でございます。
>>> >> >>
>>> >> >> FreeBSD9.3とNetatalkを組み合わせて使ってます。
>>> >> >> Netatalk 3.1.xとZFSを組み合わせた場合に、ZFSの
>>> >> >> ARCの設定を
>>> >> >> zfs set primarychache=none  /mnt/a/
>>> >> >> とかにしてZFSのARCを止めてみました。
>>> >> >>
>>> >> >> すると、readだけ極端に遅くなってしまいます。
>>> >> >> Sambaも同時に動かしたりしてますが、そちらは
>>> >> >> 何も影響が出てない様にみえます。
>>> >> >>
>>> >> >> これについて何か経験された方とかいらっしゃいますか?
>>> >> >>
>>> >> >>
>>> >> >> --haraoka
>>> >> >
>>> >>
>>> >
>>
>>
>