このたび、GIRIGIRI限界チャレンジ第1弾 Intel SSD DC S3500に選出していただきました。

私のGIRIGIRI限界チャレンジですが、物理的なGIRIGIRIではなく、GIRIGIRIのIO負荷を発生させ、DCというデータセンター向けとも取れる型番に恥じない性能を、引き出してみたいと思います。

普通に使うだけでは、GIRIGIRIのIOを発生させることはなかなかないため、複数のIO処理における性能を調査していきます。

具体的に言うと、DC S3500をメインマシンへ接続し、Windows8.1のHyper-Vで、サーバーOSを複数立ち上げます。

そこで、できる限りのIO負荷を同時に発生させ、その時のIO性能と温度変化などのパフォーマンス測定を行います。

・全サーバーへ同時にWindowsUpdateを実施、適用する
・全サーバーへ同時にSQLServerをインストールし、DBへのIOを同時に行う

最初、レビュー申し込み時点では、WindowsUpdateだけだったのですが、イマイチGIRGIRI感が足りない気がしていました。

サーバーでIOといえばDBサーバーなので、どうせServer立てるならSQLのIOもやってみようということで、追加してみました。

ということで、GIRIGIRIチャレンジ始めたいと思います。

諸事情により開封後のSSDの写真を撮りわすれ、PCへキッティングしてしまい、商品写真がありません。。。

なので、ざっくり行かせていただきます。

zigsow封筒内にプチプチでくるまれた状態で梱包され、佐川さんが持ってきてくれました。

さっそく箱を取り出しました。シンプルなパッケージです。

ふたを開けると、SpeedDeamonシールとSSD本体（写ってませんが）。。。！

風のうわさでは聞いていたが、やはり1.8インチのようです。やたら、小さいです。

どうやら、MicroSATAということで、普通のSATAの電源ケーブルは接続できないようです。

変換基板を他のレビューアーさんより情報を仕入れていましたので、迷わずポチリ。

こいつを使います。

そのまま、PCケース内のあいてる隙間へと思いましたが、すでに内蔵しているIntel 335 SSDもタイラップで固定されており、少々気が引けたので、3.5インチベイに2.5インチSSD2台格納できるマウンタもポチリとしました。

これです。

DC S3500は1.8インチでねじ穴すらないものなので、このマウンタにもDIYの味方、タイラップで止めることになりました。

マウンタのネジ穴に出っ張りが干渉して、おさまりが悪かったので、カッターで削り安定させました。

出来上がりがこれです。

この状態にした後で、DC S3500の写真を撮ってないことに気が付きましたｗ

早く動かしたい気持ちが大きくて、外すのも面倒なので、そのままPCの3.5インチシャドウベイに隠しましたｗ

ということで、開封写真にはSSD本体が写っておりませんｗ

CPU：Core i7-3770k

メモリ：4GB*2 + 8GB*2 = 24GB

SSD/HDD：
メイン：SSD Intel 335 240GB

データ：
HDD WD30EZRX 3TB＋WD5000AAKX＋WD20EZRX（iSCSI接続）の記憶域プール上のドライブ

M/B：BIOSTAR TH67+　（そろそろ変えたい。。。）

ケース：BTO付属のマイクロタワー（手狭になってきました。。。）

上記のハードウエアに今回のSSD DCS3500を内蔵しました。

そして、検証用のソフトウエア環境

ホストOS：Windows 8.1 Professional
ソフトウエア：Hyper-V

ゲストOS：Windows Server 2008 R2（評価版）
SQL Server 2012 Standard（評価版）

メモリ：1024MB～動的割り当て
HDD：20GB

※ 当初、10GB位あれば足りるだろうと思っており、20台いけるか？なんて思っていましたが全然無理でした。よって20GBで。
それでも、1台当たり、空き領域4GB無いくらいしか残ってませんｗ

上記、ゲストOSを11台用意しました。

合わせて、メインの別SSD上へ管理用のADサーバー1台を立てました。

すべての検証用サーバーは管理用ADサーバーへドメイン参加し、GPOで各種設定を省略します。FW無効、UAC無効、ESC無効、RDP有効、ネットワークドライブマウント、WindowsUpdate設定、その他もろもろ。。。

簡単に図にすると、こんな感じでしょうか。

その結果、SSDはこの状態です。

パフォーマンス取得のために、ホストOS上でパフォーマンスカウンタを作りました。IO関連、メモリ、CPU、VMごとのIOなんかを取得します。

さくっと検証環境を構築しました（なんか、職場でやってることと同じことやってる気がする。。。）が、SSD上へのサーバー構築は楽ですね。

SSDの速さもあるんでしょうが、待ち時間が少ないので、サクサクできます。
再起動なんかも、1分もあれば完了します。複数動かしても、IO待ちということがほとんどありませんので非常に快適でした。

職場でも、開発環境やテスト環境はPCにSSD入れてHyper-Vで作ると幸せなような気がします。
冗長さえ取れれば、このまま本番でいけそうですね。容量が稼げないので、2012R2の記憶域の階層化でカバーするとか、インフラ屋さんの妄想が膨らみますｗ

簡単にHyper-Vマネージャからサーバーの起動～シャットダウンまでを動画にしてみました。

どうですか？この動きだけでもワクワクしますｗ
Windows2008R2にSQLServerが入ったサーバーの起動、停止です。普通なら1台5分はかかる作業です。

ついでに、手持ちのIntel SSD 335とCDMで比較してみました。
DC S3500

335

CDMの結果ですが、どちらもデータがたんまり入っている状態で取得しました。
DC S3500のほうが、ランダムIOに関して落ち込みが少ないです。

このことから、使い込んでも性能の変化が少ないと感じられ、安定性がありそうです。

無事に11台のサーバー機が起動したわけですが、WindowsUpdateを一切していない状態なので、こいつらに一斉にWindowsUpdateを仕掛けます。

その時の温度変化とパフォーマンス測定をしてみようと思います。

11台を次々にやっていると同時実行ができないので、管理用ADサーバーより、どこぞで拾ってきたスクリプトで一気に実行します。

http://msdn.microsoft.com/en-us/library/aa387102.aspx

ここにあるスクリプトを改造して公開してくださっている方がいましたので、ありがたく使わせていただきます。

スクリプトは、パッチ検索→パッチダウンロード→インストール→シャットダウンまでを自動で実行するものです。

職場で遠隔操作などで活用しているしているPsToolsのPsExcecコマンドで全台にリモート実行します。

PsToolsは、Microsoft謹製の管理ツールの一つです。

http://technet.microsoft.com/ja-jp/sysinternals/bb896649.aspx

PsExecは、リモートでコマンドやバッチを実行することができるツールです。

テストでいろいろやってみたのですが、パッチは89個あるようです。
これをダウンロードからやると、時間がかかりすぎで複数IOの検証にならないので、
スクリプトを分割し、パッチ検索～パッチダウンロードとパッチインストール～シャットダウン部分で分割しました。

分割したスクリプトで、パッチダウンロードまでを済ませておきます。

落ち着いた頃合いを見て、管理サーバーから全台に対して、WindowsUpdateのインストールを実行しシャットダウンまでをパフォーマンスカウンタを使って計測しました。

参考程度に1台で実行したときと比較して時間にして

1台で実行したときは、20分でした。11台では、およそ1時間で完了しました。

SSDの温度ですが、VM未起動時 通常24℃のところ、最大34℃ぐらいでした。

そして、IOPSグラフ

経過時間とIOの様子を10秒間隔のグラフにしました。左軸がIOPS、右がQueueLengthです。

IO負荷が一番高かったのは、VMを一斉に起動したときが一番高かったという、微妙な結果です。。。

開始5分ころからパッチ適用を開始しています。

開始14分でDCS3500の容量不足のため、全VMが一時停止状態になってしまい、急きょVM1台削除し、11台→10台での実行です。この辺もGIRIGIRIですねｗ

開始も同時でしたが、完了もほぼ同じでした。

結果としては、最大でも7400IOPS程度でした。

実行中SSDアクセスLEDがつかなくなることが多々あり、なんとなく予想はついていました。

IO検証になっておらず、すみません。。。

気を取り直して、次やっていきます。

今度は、立ち上げた全台のSQLServerへテストデータ100万レコードのInsertとDELETEを実行し、IOの限界にチャレンジしてみます。

各SQLServer上へストアドプロシージャで作成します。それを、管理サーバーからスクリプトで全台に対して呼び出します。各サーバー上でSQLCMDでストアド実行しました。

1台で実行すると、Insert 約4分、Delete 約4分ほどです。
比較用に1台でのIOPSグラフ

パフォーマンスグラフを確認してみたところ、いい感じでIO発生している様子がわかります。

それではさっそく、10台同時のINSERT実行してみました。

IOPSは35000IOPS、Queueの長さに関しても最大14とまだ余裕がありそうです。

SSDのQueueに関しては計算できないので意味があるかどうかわかりませんが、処理待ちの多さということで記録します。HDDだとスピンドルの数とかで簡易で計算できるのですが。。。

時間もそれほど大きく変化がなく長くて11分弱と多重で処理しきれているようです。

温度に関しても、最高40度で、まだ大丈夫そうです。

もう少し試してみたいなぁと考えた結果、サーバーはこれ以上増やせないので、ストアドを多重で実行することでIOを増やせるのでは？　ということで、やってみました。

1VMあたりストアドを2つ同時に走らせ、10台のVMで同時に実行させてみます。
現状のストアドは多重で実行すると、Deleteの時に不具合が発生するので、識別用のキー盛り込んだ、テーブルの拡張とストアドの変更を実施しました。

パラメーターに識別子をつけて同じテーブルにInsert・Deleteを実行していきます。

結果IOPSグラフ

新たに取り直した後のIOPSグラフ（2013/11/11）

。。。

そんな単純ではなかったようです。40000IOPSどまりで、普通に完了しました。

若干Queueの長さが増えたくらいです。

実行完了までが、約18分かかりました。

それでも、1台で実行したときに比べ約2.25倍、10台の時から約1.64倍で済んでいるので、まだ、多重で処理しきれている感じがします。

2013/11/11 新たに取得しなおしてみました。

１VMあたり2ストアドでそれぞれ別のテーブルへのINSERT、DELETEを行ってます。

結果、時間も1分ほど余計にかかり、最大IOPSが34000IOPSでした。

多重度が上がり、IOも処理待ちになるのでしょうか。

SSDの温度は現状最高温度の42度をマークしました。

とりあえず、特に結果も何もなく、GIRIGIRIでもないですが、複数同時処理にも十分耐えられる！　安定して利用できそう！ということは証明できたと思います。

どこかでIOが頭打ちになり、Queueがたまり処理できなくなるはずだと思われます。

どこかのサイトで、SQLベンチマークで43000IOPSを出しているのを見かけたので、もう少しやれば、限界まで行きそうです。どんな結果が出るか見てみたいですね。

それについては後日追記します。

2013/11/08 追記

2013/11/11 追記

さっそくほぼ30台同時実行してみました。

新たに取得しなおしたものがこちら

？？？　IOPSが伸びずにQueueのたまり具合が増えてきました。

そろそろ限界なのでしょうか？最大のIOPSも38000IOPSと伸びませんね。

2013/11/11 追記

取得しなおした結果、最大IOPSが39000IOPSで、実行時間も3分ほど短くなってます。

立て続けに、ほぼ40台同時実行も試してみました。

こちらも、新たに取得しなおしました。

今度は、IOPSがばらつくようになってきました。最大のIOPSも36000IOPSとこれも伸びませんね。逆に下がってきました。

取得した結果、最大IOPSは39000IOPSと30台同時とほぼ同じ結果です。

実行時間も、20多重→30多重→40多重と時間の変化は5～6分づつ増加します。

この結果から、

IOPSは書き込み側で39000IOPSぐらいが限界のようです。

1つのSSD上の違う領域に同時にIOを発生させ、限界値を探る検証でしたが、

ここで1つの答えにたどり着きました。

このテストが完了した段階で、DiskInfoの状況ですが、

総書込量は2.2TBと、他の方のレビューに比べれば、使い込まれていない感じですね。

ですが、同じセクタは約10回ほど書き換えられているはずですが、CDMの結果を見るとスコアの変化がわかりません。

SnadForce系のコントローラでは書き込みがあからさまに落ちるのですが、Intelの独自コントローラはすごいですね。

左は最初に計測したときのCDM結果　右は2.2TB書込後のCDM結果

もしかして、同じテーブルに4多重で書き込んでも、行ロックやページロックなどで、多重にはならず待ち状態で効率悪くなってるかもしれないです。

テーブルは別々に作ったほうがよかった気がします。

ということで、テーブルを別々に作成し、20,30,40・・・とやり直そうと思います。

今のところ40000IOPSがGIRIGIRI IOですね。

参考までに、ストアド実行中の各サーバーのCPU使用率は平均5~6%ほどです。

2013/11.25 追記

Write側は、公称値を上回る値を叩きだしていましたが、Read側は？

ということで、やってみました。

せっかく、10台の仮想マシンがあるので、全台でCDMとったら面白いことになる？

まずは動画で撮ってみましたので、ご覧下さい。

いかがでしょう？長すぎて全部見てない？

ですよね。。。

Hyper-Vが賢いのかどうかは何とも言えないのですが、見事に1/10のスコアになってます。

QD32ランダムの時のスコアがいいのでタイミング悪かったかもと思いながら、パフォーマンスグラフ作ってみました。

丁度、5:50秒くらいに、公称値75000IOPSを超えてます。QD32ランダムの時でしょうか。

正確にいうと75015IOPSを記録しました。

急に跳ね上がるので、念のため数回繰り返してみましたが、同じような結果でした。

シーケンシャルの時は伸びませんでしたが、ランダムで細かく読み書きするときに性能を発揮してます。

これは、データベースやファイルサーバーなどで、ランダムアクセスが多い場合、非常に有効なストレージになりそうです。

Intel SSD DC S3500のIO性能は半端じゃなかったです。

素人のIOチャレンジはこんな感じでしたが、まだまだこいつは行けそうです。

そして、ほぼギリギリのIOを発生させた際も、このSSDの発熱はそれほど高くないようです。

私のGIRIGIRIチャレンジはまだ続きますが、いったんここまででアップしたいと思います。
後日、追加の検証結果と写真などの加筆修正なども行います。

SSDにこんなことをしたことがないので、比較できませんが、低発熱、安定した性能、データセンター用としては比較的低価格設定といいことずくめなSSDだと思います。

可能であれば、ディスクレスモデルのサーバー機にDC S3500を詰め込んだ、仮想化基盤なサーバーを設計してみたいです。ベンダー純正品はMLC 100GBで16万（耐久性が違うようですが。）とか、アホみたいに高いので、限られた予算で設計するインフラ屋さんとしては見逃せない選択肢だと思います。

2013/11/11　追記

期限まで時間もあるので、今度はRead側の限界値を探るべく検証を続けたいのですが、いいアイデアを思いつきません。
テストデータを1件ずつselectするか？そんなんで、IO発生するか？

この環境を使って、Read側の限界も探れればと思ってます。

2013/11/25　追記

なんだかんだで後回しになってしまいましたが、Read側の限界値というより、総合的な限界値の調査になってますね。

ただ、複数同時のIOであっても、DC S3500はへこたれず、公称値以上の働きをしてくれました。1本で、サーバー10台の動作でもローカルとそん色ない動作をしてくれる、性能に脱帽しました。

今回の検証でも、全く性能も、寿命も劣化していないため、RAIDを組んで冗長性を持たせれば、基幹サーバーでも問題なく利用できると思います。

別のSSDが入手できた際には同様なテストで比較してみたいですが、壊すのは怖いですね。

変更履歴

2013/11/06　いったん公開

2013/11/08　追加で取得したデータを追記

2013/11/11　写真にシリアルあったのをぼかし入れる

2013/11/11　データ再取得し、キャプチャ画像入れ替え、文言修正・追記

2013/11/25　全台CDM取得し掲載