smectic_gの日記

2014-07-26

[][][]現行ファイルサーバのパフォーマンス

Asrock C2550D4I+DS380の構成がケースは狭苦しいはAtomの癖に消費電力は妙に多いわといい事なかったので,Q87+Fractal DesignのNode 804で組み直し。構成は以下のとおり。

CPUintel i3-4130T
【M/B】ASUS Q87M-E
【RAM】DDR3 8GBx2(CFD W3U1600HQ-8G)
【VGAintel 内蔵
【HDDIntel X18-M/X25-M 80GB,WD40EZRX*6
【光学】無し
【LANintel I217-LM
【HBA】LSI SAS 9207-8i 
【電源】KRPW-PT500W/92+ Rev2.0
【OSFreeBSD 10.0-STABLE #25 r266389
【ケース】fractal design Node 804

この状態で消費電力はアイドル48Wと以前のファイルサーバからかなり減った(以前のファイルサーバHDD普通に回してると70Wくらいだったので)。

stripingとraidzでのパフォーマンスは以下の通り

f:id:smectic_g:20140726205523p:image:w480

まあ速いけど,C2550D4Iより思ったより速くないかも。

比較はこちら

f:id:smectic_g:20140726205524p:image:w480

C2550D4Iのwriteは挙動が妙なので,それと比べるとLSI SAS 9207-8iの方が速いけど,readは同じくらいで意外と健闘してる。

fractal designのNode 804は,高さ34cmくらいのA4の書類用の高さにセットしたメタルラックにそのまま突っ込めるのが一番のメリット。

f:id:smectic_g:20140614113110j:image:w360

内部のサイズはかなり大きくてかなり余裕があるのだけど,唯一気をつけないといけないところは写真の電源側のHDDケージの下部のスペース。電源ケーブルをL字型のものにしないとHDDコネクタに無理な力がかかりやすい。

2014-03-15

[][][]Asrock C2550D4I+WD40EZRXでのZFSパフォーマンス

そろそろ前のファイルサーバが手狭になってきたので,ファイルサーバの更新を予定。去年の年末から少しずつ部品を買い集めて,ほぼ組み上がったので,ベンチマーク中。

構成は以下のとおり

CPU】Avoton C2550
【M/B】ASRock C2550D4I
【RAM】DDR3-1600 8GBx2 (SMD-8GB28EC2P-16K)
【VGA】ASPEED
【HDDADATA S511 120GB,WD40EZRX*6
【光学】無し
【LANIntel i210
【電源】FSP 300-60GHS
【OSFreeBSD 10.0-STABLE #20 r262794
【ケース】DS380(冷却ファン*3)

消費電力はidle 55W,起動時最大100W,ベンチマーク中最大72W。

f:id:smectic_g:20140315142148j:image:medium

ケースのD380がかなり狭苦しいのとなんか3.5inch HDDケージの接続の安定性があんまり良くないのではっきり微妙。さっきもHDDが一つ認識されなくてかなり慌てた。

この写真だとあまり伝わらないけど,ケーブルの取り回しはかなり微妙。フラットケーブルだと,マザーボード側から出てるキシメンと3.5inchケージが干渉するので,ラウンドケーブルを使うべき。HDD側も全部L字にするとケージへの電源コネクタが干渉するが,全部ストレートにすると反対側にある2.5inchのSATAコネクタと干渉する。2.5inchのSATAをL字にして,3.5inch側は全部ストレートにするのが正解かもしれない。どちらにしてもかなり窮屈。

あと,メンテナンス性という意味では,3.5inchケージを取り外さないと2.5inchケージに触れないし,マザーボードにもアクセス出来ないのはかなりめんどくさい。

ケースへの愚痴はここまでで,ZFSにした際のベンチマーク

benchmarkはbonnie++で実施して,block readおよびwriteを10回測定して,平均と標準偏差プロット。具体的なコードはこれ。4TB HDD*6はSATA M0-M5に接続*1

まずは,普通に/dev/ada*をそのまま認識させた時の結果

f:id:smectic_g:20140315143148p:image:w360

かなり極端。writeは300MB/sでリミット。readも540MB/sくらいでリミットがかかる。これは,ASRock C2550D4Iに搭載されているMarvell SE9172とMarvell SE9230が多分原因なので,C2550内臓のSATA分散して接続すればもう少しパフォーマンスの上積みが期待できるかもしれないが,何も考えずにつなぎ替えると起動ディスクがマウントできなくなるので,テストはfstabをlabelベースに書き換えてからかなあ。

次に,全部を

gnop -S 4096 /dev/ada*

で,強制的に4kセクターとして認識させた場合

f:id:smectic_g:20140315143147p:image:w360

次はgnopありなしでの比較。前やった時には結構変わったのだけど,この環境では殆ど変わらないので不要みたい。

f:id:smectic_g:20140315143146p:image:w360

*1:FreeBSD10での認識順序はSATA M0-M5→SATA 0-2となるので,何も考えずにC2550側のSATA0に起動ディスクを搭載して設定等をした後にHDDをつなぐと,ada0からada6に移って起動しなくなってはまるので注意。

2011-06-05

[][][]次期ファイルサーバ用の構成のテスト

H67MA-E45だとFreeBSDが起動しないとか,いろいろトラブルに見舞われつつも,次期ファイルサーバとして運用すべくいろいろとテスト中.

マザーボードの入れ替えは終わったので,今度はストレージの方.旧マザーの方で次期ファイルサーバのストレージ構成をテストしてみたので結果を.

CPU】 i3 530 1.86GHz
【M/B】 DH55TC
【電源】KRPW-V600W
【FAN】 120mm*2
【VGA】 オンボード
【HDD】 SHD-NSUM60G, WD30EZRS*3,WD30EZRX*3
【メモリ】 DDR3 1333 2GB*4
【Sound】 オンボ
【SATALSI SAS 9211-8i
【LAN】 オンボ(82758DC)
【OSFreeBSD 9.0-CURRENT
【光学ドライブ】なし

初めて,8portのインターフェースカードを導入してみた.mini-SASのケーブルは内部の配線がすっきりするので便利.

ここでのポイントはWDの4k通知タイプのディスクを使ってみたことで,どうなるのかなというあたり.ただ,結局のところSATAにつなぐと物理4kの取得が出来るけど,9211-8i経由だとcamcontrol identifyでもcamcontrol inqueryでも,物理セクターサイズの取得は出来ないから期待通りの効果はなさそう.

で,ベンチマーク.今回はddを使ったシーケンシャルアクセスのスピードを各種構成で測定してみた.

具体的にはメモリが8GBなので,ARCがあふれるように16GBのデータを読み書きするスピードを計測し,10回測定した平均を記載.

グラフの中で,w/4kとあるのは

gnop -S 4096 <disk>

として,4kセクタとして無理やり認識させた場合のアクセススピード.

f:id:smectic_g:20110605135230p:image:w360

f:id:smectic_g:20110605135231p:image:w360

一見してわかるように,4kセクタとして認識させた方がストライピング構成(raid0)でも,raidz構成でも明確に速い.単独だと2割程度だけど,ディスク数が増えるにつれて差が拡がる.

面白いのは,raidzの方で何も考えずに認識させると5個ディスクを使ったところでreadの性能がガタっと落ちること.この問題は他のところでも指摘されてたのだけど,本当にそうなんだと驚いた.

あと,ほぼ常にwriteの方が性能良いのは何故なんだろう?atimeを切ってもつけても変わりなかった(グラフはatimeを切って測定).

2010-12-18

[][]バックアップ用サーバを作ったので,性能テスト

一時期prefetchを切らないとvlc+無線LANで途切れずに再生できないとかいろいろあったけど,2010年12月現在の9-currentだと,prefetchを入れてもそんな問題なく普通に使える.が,全体的なパフォーマンスの低さが如何ともしがたい状況.

ということで,本体のバックアップとしてファイルサーバをほぼ新規に作ったので,ベンチして比較してみた.

メインのファイルサーバ

CPU】 i3 530 1.86GHz

【M/B】 DH55TC

【電源】KRPW-VII-600

【FAN】 120mm*1 140mm*1

VGA】 オンボード

HDDADATA SSD 300, WD20EARS*5, Crucial C300 128GB(L2ARC)

【メモリ】 DDR3 1333 2GB*4

【Sound】 オンボ

LAN】 オンボ(82758DC)

OSFreeBSD 9.0-CURRENT

光学ドライブ】なし

bonnie++のベンチ結果.

Version  1.96       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
hafnium.smectic 16G   143  98 127373  28 92973  22   390  98 238798  23 359.4  48
Latency               528ms   13595ms    9883ms   59052us    2137ms     338ms
Version  1.96       ------Sequential Create------ --------Random Create--------
hafnium.smectic.com -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 23266  80 +++++ +++ 13923  63 21873  88 +++++ +++  4419  22
Latency             10946us    5103us   62986us   46032us      59us    4811us
1.96,1.96,hafnium.smectic,1,1292647596,16G,,143,98,127373,28,92973,22,390,98,238798,23,359.4,48,16,,,,,23266,80,+++++,+++,13923,63,21873,88,+++++,+++,4419,22,528ms,13595ms,9883ms,59052us,2137ms,338ms,10946us,5103us,62986us,46032us,59us,4811us

メモリを大量に積んでるわ,C300をL2ARCを積んでいるのにこのスペックってのは,はっきり言って異様に遅い.特にレイテンシーが異様に悪い.

適当に作ったバックアップサーバ

CPU】 Athlon X4 630 (2.8GHz)

【M/B】 MSI 785GM-P45

【電源】KRPW-V600W

【FAN】 120mm*1 120mm*1

VGA】 オンボード

HDD】 SHD-NSUM60G, HD154UI*5

【メモリ】 DDR3 1333 2GB*2

【Sound】 オンボ

LAN】 オンボ

OSFreeBSD 9.0-CURRENT

光学ドライブ】なし

ベンチ結果

Version  1.96       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
copper.smecti 3544M   128  99 162523  40 120427  30   405  99 359213  45  56.2  37
Latency               776ms    1163ms    1750ms   80935us     404ms    4326ms
Version  1.96       ------Sequential Create------ --------Random Create--------
copper.smectic.com  -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 21001  95 +++++ +++ 30337  95 30320  97 +++++ +++ 29914  94
Latency             11618us     113us     183us   22433us      36us      69us
1.96,1.96,copper.smectic,1,1292716694,3544M,,128,99,162523,40,120427,30,405,99,359213,45,56.2,37,16,,,,,21001,95,+++++,+++,30337,95,30320,97,+++++,+++,29914,94,776ms,1163ms,1750ms,80935us,404ms,4326ms,11618us,113us,183us,22433us,36us,69us

えーっと,悲しくなるくらい圧倒的です.レイテンシーも遅いといえば遅いですが,常識的な値をたたき出してます.

これも全て512Bに偽装するAFTが全部悪い.

2010-08-27

[][]ZFSが落ちる

ZFSが落ちているのかどうかはkernel panic画面を終えていないので実はわからないんだが,状況証拠的に完全に黒(ファイルコピーした瞬間に落ちる).ログをとろうにもZFSが落ちてしまうのだとするととりようがなかったり.

1週間に数回落ちるのはあまりにもあまりだということで,9-CURRENTから8.2-RELEASEにバージョンを落としたが,頻度は落ちるものの,相変わらず.(1週間に1回か,2週間に1回くらい)

メモリは8GB積んでいて,

vm.kmem_size_max=4096M

vfs.zfs.zrc_max=2048M

だから,もしメモリ不足で落ちるとしたら,どう考えてもバグだろという状況.

とりあえず,FreeBSD 7の時代にprefetchをonにしてると落ちるという話を見かけたので,

vfs.zfs.prefetch_disable=1

として,様子を見ようと思う.

ちなみに,これによるパフォーマンスロスはかなり大きく,HDD5台(WD20EARSを5台)でのraidzで

prefetchあり

Version  1.96       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
hafnium.smectic 16G   136  99 104866  27 78585  17   442  99 256528  25 103.9  30
Latency               394ms    9918ms   24498ms   52799us    2031ms    8202ms
Version  1.96       ------Sequential Create------ --------Random Create--------
hafnium.smectic.com -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 13801  44 13681  29 16383  66 20207  70 +++++ +++ 25460  90
Latency               248ms     715ms   89906us     155ms      39us     134us
1.96,1.96,hafnium.smectic.com,1,1282861996,16G,,136,99,104866,27,78585,17,442,99,256528,25,103.9,30,16,,,,,13801,44,13681,29,16383,66,20207,70,+++++,+++,25460,90,394ms,9918ms,24498ms,52799us,2031ms,8202ms,248ms,715ms,89906us,155ms,39us,134us

prefetchなし

Version  1.96       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
hafnium.smectic 16G   162  92 98551  26 47690  21   454  98 84866  25 110.3  39
Latency               600ms   15254ms   10784ms   61884us    1337ms    6822ms
Version  1.96       ------Sequential Create------ --------Random Create--------
hafnium.smectic.com -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 19138  57 +++++ +++ 22525  78 29514  87 +++++ +++ 22507  74
Latency             47679us     113us   23869us   16782us      41us      92us
1.96,1.96,hafnium.smectic.com,1,1282854889,16G,,162,92,98551,26,47690,21,454,98,84866,25,110.3,39,16,,,,,19138,57,+++++,+++,22525,78,29514,87,+++++,+++,22507,74,600ms,15254ms,10784ms,61884us,1337ms,6822ms,47679us,113us,23869us,16782us,41us,92us

てな感じ.遅い.

追記

懸案だったVLC(1.12)でのTS再生がprefetchをoffにすると普通にできるようになった。

実はprefetchって実使用だとむしろ有害?

うーん、こういうことらしい。

Java.net Maintenance outage

streamingアクセスに対してprefetchをonにすると、がんばってアクセスするわりにパフォーマンスが落ちてしまうらしい。

追記2

prefetchをoffにしたら笑っちゃうくらい落ちなくなった.あまりにも落ちなくてつまらないので,8-stableから9-currentに戻したくらい.

パフォーマンス関係の唯一の不満点はTMPGEncXP4で編集するときに少し遅いくらい.でも,それ以外の用途では大抵速い.prefetchダメすぎる.