最近の変更サイトマップ

NETGEARのLAGのAdmin ModeメニューはLAGの有効/無効指定を意味するらしい

ネットギアのL2スイッチのLAG設定に「Admin Mode」なる謎の項目がある。

 XS512EMのLAG設定画面

スイッチの内蔵ヘルプを見ても“Admin Mode - Select Enable or Disable to set the Admin Mode.”という何の役にも立たない情報しかなく、全く以て意味がわからない。確実な情報は見つけられなかったんだけど、結局のところ機能のオン/オフを切り替える程度のものっぽい。もちろん、Enableが有効でDisableが無効ね。

機種は違うが公式フォーラムでは、Enableだとトラフィックが流れてDisableだと全く流れない、という回答になってるが、少なくともXS512EMのLAG設定のに関してはLAGのEnable/Disableにしか影響してなさそう。実際、Admin Modeの状態を問わずパケットは流れてるし、LAGを設定してもDisableならLAG StatsuはDownのまま、Enableにして初めてUpになった。

フォーラム回答の挙動は、マネージドスイッチ以上で設定できるポート毎のAdmin Modeの解説なんじゃないかって気がする。いずれにせよ、もっと分かりやすい名前にしとけよと思うけど…。

参考サイト

東芝のエンプラ向けSSD THNSNJ960PCSZ (HK3R2 960GB) 購入

これまでSSDはIntel DCシリーズを買ってきたが、今回はTOSHIBAの読み出し重視型エンタープライズ向けSSD THNSNJ960PCSZを買ってみた。例によって例によって中古。新品じゃ高くて買えませんからね。それでもっていつものごとくベンチ。今回もSATA接続。

-----------------------------------------------------------------------
CrystalDiskMark 6.0.0 x64 (C) 2007-2017 hiyohiyo
                          Crystal Dew World : https://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes

   Sequential Read (Q= 32,T= 1) :   552.067 MB/s
  Sequential Write (Q= 32,T= 1) :   519.592 MB/s
  Random Read 4KiB (Q=  8,T= 8) :   377.485 MB/s [  92159.4 IOPS]
 Random Write 4KiB (Q=  8,T= 8) :   353.540 MB/s [  86313.5 IOPS]
  Random Read 4KiB (Q= 32,T= 1) :   269.954 MB/s [  65906.7 IOPS]
 Random Write 4KiB (Q= 32,T= 1) :   231.575 MB/s [  56536.9 IOPS]
  Random Read 4KiB (Q=  1,T= 1) :    35.232 MB/s [   8601.6 IOPS]
 Random Write 4KiB (Q=  1,T= 1) :    91.411 MB/s [  22317.1 IOPS]

  Test : 4096 MiB [D: 0.0% (0.2/894.3 GiB)] (x5)  [Interval=5 sec]
  Date : 2018/04/26 22:49:50
    OS : Windows 10 Professional [10.0 Build 16299] (x64)
    TOSHIBA THNSNJ960PCSZ

ベンチ結果もS.M.A.R.T.情報も取り立てて何かあるという事もなく。強いて言えば、総読込量より総書込量が圧倒的に多いことくらい。この使い方ならHK3Eシリーズの方が合ってるんじゃねー?>前のオーナー。まぁ、このくらいの使い方ならどっちでも変わらんだろうけどさ。

THNSNJ960PCSZの耐久性はと言うと、1 DWPD1)──つまり定格寿命たる5年間、毎日1回ドライブ全体に書き込むとTBWに達するということだから5×365×960=1752000GB、つまりTBWは1.752PBである。公称耐久性はDC S3500以上、S3700未満ということになる。そう考えるとDC S3700シリーズの10 DWPDって半端ない耐久性だよなぁ…。東芝のSSDでいえば書き込み重視型のPXシリーズが同等ラインっぽい。

主に自宅鯖の仮想マシン置き場として使う予定。取り付けたら何故かアクセスランプが点きっぱなしなんだけど…w

1) Drive Write Per Day

ZFSが自動マウントされない時はzfs_enable="YES"になっているか確認する

FreeBSDで起動時にルートプール以外のZFSファイルシステムが自動マウントされない時は、/etc/rc.confzfs_enable=“YES”しているか確認する。この指定がなくとも、ルートプール=システムが入っているプールは自動マウントされるので、なかなか問題に気づきにくい。自動マウントされないFSのcanmountmountpointプロパティを見ても問題ないし、原因が判るまで苦労したんだぜ★

インストーラに頼らず、手動でFreeBSDをインストールした場合なんかは特に注意が必要だ。

Samba 4.7.4 on NAS4Free 11.1.0.4がメモリバカ食いする原因がわかった

知人NASのCIFS共有が調子良くない問題の調査中、smbdがアホほどメモリ確保する現象に見舞われた。1プロセスあたりギガ単位で消費し、最終的に16GBの物理メモリとスワップ64GBを食いつぶし、強制的に電源落とすしかなくなるなんて、どう考えても異常だ。smbdがメモリをバカ食いするせいでARCにメモリが割り当てられず、ストレージの実効性能が上がらないのもCIFSが遅い問題の遠因になってると思われる。

Sambaのオプションをあれこれイジった所、シャドウコピーを有効にするとダメっぽい。下図がシャドウコピーオプション有無でのtopを比較したものだ。

もうね、笑っちゃうくらい一目瞭然。メモリ消費量が文字通り桁違いである。シャドーコピー有効の方は、1日足らずでメモリ枯渇しかけてるのに対し、無効の方は4日程度経過のロードアベレージが13行くほどの負荷が掛かってるのに余裕のよっちゃんイカ。(ちなみにこの状態でもつつがなくファイル共有が行われている。)

Sambaでシャドーコピーってことは、vfs_shadow_copy2モジュールあたりがバグってんのかしらね?NAS4Free 9か10の頃は、シャドーコピー有効でもこんなこと起こらなかった記憶があるんだけど…。(超おぼろげなので保証はできない。)

今更ながらZFSはキャッシュのヒット率が超重要

この記事には技術的裏付けがない、個人の感想、雑感、推測がふんだんに含まれています。ご利用の際は用法・用量を守り正しくお使いください。

知人のNAS4Freeなファイルサーバが重い問題、Sambaが原因で一件落着かと思いきや解決してなかった。(こっちはこっちで別の問題が発生してたりするので別途書く予定。)

知人とやり取りしつつCPU, ネットワーク, ディスクI/O, その他諸々を継続的にモニタリングしてみると、どーにもディスクアクセスがボトルネックになっている事があるようで…。ファイルサーバのターミナルで直接cpしても、全然速度が上がらないのだ。対象のファイルは、50~200kBの数十万個のPNGを含む膨大なファイル群で、ファイルシステム的に結構厳しい条件ではあるものの、ストレージは仮にもHDD 2ペア×3セットからなるRAID10である。十数MB/sは出るだろうと思ってたが、実際には1MB/s以下になることさえある。

いくらなんでもオカシイだろうとzpool iostatしてみた結果がこちら。

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zdata       4.56T  6.31T  5.65K    435  25.5M  4.94M
zdata       4.56T  6.31T  7.43K      0  32.7M      0
zdata       4.56T  6.31T  5.44K      0  24.1M      0
zdata       4.56T  6.31T  6.20K      0  27.3M      0
zdata       4.56T  6.31T  6.44K      0  28.4M      0
zdata       4.56T  6.31T  5.81K    398  26.6M  3.89M
zdata       4.56T  6.31T  4.36K    215  34.8M  10.8M
zdata       4.56T  6.31T  2.76K    391  12.5M  3.47M
zdata       4.56T  6.31T  3.58K      0  19.7M      0
zdata       4.56T  6.31T  3.65K      0  20.1M      0
zdata       4.56T  6.31T  3.15K      0  17.7M      0
zdata       4.56T  6.31T  4.05K      0  19.0M      0
zdata       4.56T  6.31T  2.59K    343  14.6M  3.15M
zdata       4.56T  6.31T  3.66K      0  19.6M      0
zdata       4.56T  6.31T  4.99K      0  32.5M      0
zdata       4.56T  6.31T  2.93K      0  19.1M      0
zdata       4.56T  6.31T  6.38K      0  28.4M      0
zdata       4.56T  6.31T     3K    344  13.6M  2.99M
zdata       4.56T  6.31T  3.86K      0  17.9M      0
zdata       4.56T  6.31T  3.77K      0  16.9M      0
zdata       4.56T  6.31T  3.72K      0  16.8M      0
zdata       4.56T  6.31T  2.91K    226  13.3M  2.39M

読み込み操作数(operations)と読み込み量(bandwidth)の割に、書き込み量が著しく少ない。コピーと並行してSambaへ断続的なアクセスがあるってことを差し引いても全然スループットが出てない。つーか、書き込み量とネットワークに出ていく量を合わせても全然読み込み量に足らん罠。

大量の読み込みoperationsが走ってても、いい感じに処理できてる時は↓こんな感じで順当にbandwidthが上がる。CIFSによるリクエスト分がそのまま処理されてネットワークに流れていっている。

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zdata       4.70T  6.17T  15.3K    638  64.8M  7.06M
zdata       4.70T  6.17T  23.8K      0   101M      0
zdata       4.70T  6.17T  20.4K      0  85.9M      0
zdata       4.70T  6.17T  23.6K      0  98.7M      0
zdata       4.70T  6.17T  18.4K      0  76.5M      0
zdata       4.70T  6.17T  7.06K    720  30.1M  8.41M
zdata       4.70T  6.17T  16.6K      0  70.0M      0
zdata       4.70T  6.17T  13.7K      0  57.7M      0
zdata       4.70T  6.17T  18.1K      0  77.3M      0
zdata       4.70T  6.17T  16.7K    536  72.3M  6.52M
zdata       4.70T  6.17T  7.63K     80  32.5M   376K
zdata       4.70T  6.17T  12.3K      0  52.7M      0
zdata       4.70T  6.17T  9.78K      0  42.4M      0
zdata       4.70T  6.17T  11.8K      0  51.0M      0
zdata       4.70T  6.17T  9.32K    586  40.4M  6.41M
zdata       4.70T  6.17T  9.47K      0  40.6M      0
zdata       4.70T  6.17T  11.6K      0  49.2M      0
zdata       4.70T  6.17T  12.1K      0  51.8M      0
zdata       4.70T  6.17T  5.05K      0  22.2M      0
zdata       4.70T  6.17T  4.88K    579  22.1M  6.61M

rsyncでディスク内コピーを行うと更に悲惨で、びっくりするほど速度が出ない。ネットワーク(1000BASE-T)越しの別マシンにzfs sendし、そいつとrsyncで同期した方が早いっていうね…。すわ、断片化か!?と思ったけど、プールは半分以上空いてるしちょっと考えにくい。

あれこれ考えてるうちに、ZFSはキャッシュのヒット率が重要って事を思い出した。1フォルダに大量の細かなファイルがあるって事は、その分メタデータ処理が重いと考えられる。とすれば、メタデータを使いまくってそうなrsyncで速度が出ないってのも説明が付く………気がしなくもない。

zfs-statsを入れてキャッシュのヒット率を見てみたら、なんと2割を切ってるじゃないの。キャッシュに乗り切らなかったメタデータに毎度アクセスしに行くために、read operationsの割にbandwidthが上がらなかったのかしら…?

とりあえずarc関連のカーネル変数を調整したところ、いい感じでキャッシュヒットするようになった。問題のプール内のディレクトリ間でrsyncした時の結果が↓これ。

キャッシュヒット率が90%ほどに改善し、書き込みも12MB/s程出ている(zdata iostatは1秒毎、vfs.zfs.txg.timeout=5である)。

start.txt · 最終更新: 2016-05-07 17:46 by decomo
CC Attribution-Noncommercial-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0