ソースの表示以前のリビジョンバックリンク全て展開する／折り畳む文書の先頭へ Share via Share via... Twitter LinkedIn Facebook Pinterest Telegram WhatsApp Yammer Reddit Teams最近の変更Send via e-Mail印刷パーマリンク × 東芝のエンプラ向け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シリーズが同等ラインっぽい。 主に自宅鯖の仮想マシン置き場として使う予定。取り付けたら何故かアクセスランプが点きっぱなしなんだけど…ｗ 1) Drive Write Per Day ZFSが自動マウントされない時はzfs_enable="YES"になっているか確認する FreeBSDにおいて、起動時にルートプール以外のZFSファイルシステムが自動でマウントされない時は、/etc/rc.confにzfs_enable=“YES”があるかどうかを確認する。この指定がなくとも、ルートプール＝システムが入っているプールは自動マウントされるので、なかなか問題に気づきにくい。自動でマウントされないFSのcanmountやmountpointプロパティを見ても問題ないし、原因が判るまで苦労したんだぜ★ インストーラに頼らず手動で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である）。 Intel SSDSC2BB240G4 (DC S3500 240GB) のベンチマーク 購入時期は忘れたが、その昔、中古で買ったSSDSC2BB240G4が発掘されたのでベンチをうｐ。家鯖で、VM置き場/ZIL/L2ARCとして使っていたブツ。 ----------------------------------------------------------------------- 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) : 509.971 MB/s Sequential Write (Q= 32,T= 1) : 285.330 MB/s Random Read 4KiB (Q= 8,T= 8) : 312.081 MB/s [ 76191.7 IOPS] Random Write 4KiB (Q= 8,T= 8) : 271.718 MB/s [ 66337.4 IOPS] Random Read 4KiB (Q= 32,T= 1) : 271.167 MB/s [ 66202.9 IOPS] Random Write 4KiB (Q= 32,T= 1) : 252.995 MB/s [ 61766.4 IOPS] Random Read 4KiB (Q= 1,T= 1) : 33.345 MB/s [ 8140.9 IOPS] Random Write 4KiB (Q= 1,T= 1) : 94.851 MB/s [ 23157.0 IOPS] Test : 4096 MiB [D: 0.1% (0.1/223.4 GiB)] (x3) [Interval=5 sec] Date : 2018/03/01 1:41:52 OS : Windows 10 Professional [10.0 Build 16299] (x64) Intel SSDSC2BB240G4 < Newer Posts 1 2 ... 25 26 27 28 29 30 31 ... 83 84 Older Posts > start.txt 最終更新: 2022-07-27 15:26by Decomo