2012年4月24日火曜日

TOSHIBA THNSNS120GBSPの速度低下について

前回の記事をアップしたあとに東芝の最新SSD「THNSNS120GBSP」をある程度使ったら、シーケンシャルライトの速度が低下したままになるというコメントを頂きました。
このコメントが非常に気になったので、僕の方でもこの現象について検証してみました。今回は、その結果をレポートしたいと思います。

検証は、IOMeterを使って行いました。ライトパターンは、1MBのシーケンシャルライト15秒間です。これをワンセットとして計40回、10分間の書き込みを行いました。その結果が、以下のグラフです。グラフの青の線が書き込み速度、赤の線が総書き込み容量です。


この結果をみてもらうとわかりますが、本製品の場合、公称記録容量(ユーザーデータエリア、本製品の場合111.79GiB)を超える120GiB(グラフではGB表記していますが、GiBです)のデータを書き込むとシーケンシャルライトの速度が約240MB/secに低下し、以降はこの速度のまましばらく推移します。Marvell製コントローラ採用製品では、これと同じテストを行っても、シーケンシャルライト速度が低下することはありません。しかし、Sandforce製コントローラの場合は、必ず、速度が低下するようです。これは、Intel SSD 520の結果から推測できます。


上記のグラフは、Intel SSD 520でTHNSNS120GBSPと同じテストを20分間行ったときのグラフです(計測時間が長くなっているのは、書き込み速度が異なるからです)。速度低下の大きさや速度低下するまでの総データ書き込み量はTHNSNS120GBSPとは異なりますが、Intel SSD 520も同じように速度が低下し、よく似た傾向のグラフとなっています。Sandforce製コントローラを採用したSSDの場合、初期速度と記録容量一周分のデータを書き込んだあとでは、明らかに書き込み速度が異なります。Sandforce製コントローラでは公称記録容量付近まで連続してデータを書き込むと、書き込み速度が低下する仕様なのだと思います。いうまでもありませんが、この状態から初期速度に戻すには、SecureEraseを行うのがもっとも手っ取り早い方法です。

なお、速度低下が始まる総書き込み容量が、THNSNS120GBSPとIntel SSD 520とで異なっています。これは、THNSNS120GBSPの方が、 より積極的に実際に記録可能なエリア(NANDメモリの総容量)を利用する仕様になっているからだと推測されます。

THNSNS120GBSPは、こんな盲点があるとは気づきませんでした。前回記事でコメントを頂いた方に感謝したいと思います。

5 件のコメント:

  1. この現象はOCZ Vertex 3 MI 120GB (SF-2281, 東芝 3xnm MLC)でも認められており( http://cuttingedge.blogzine.jp/blog/2011/08/anvils_storage_.html の記事後半)、Sandforceコントローラーに共通のようですね。

    あと、ベンダーによりますがSFコントローラー製品ではSandforce Life Time Performance throttling (使用時間に対して書き込み量が多いと書き込み速度を落とす機能 http://www.xtremesystems.org/forums/showthread.php?272545-Sandforce-Life-Time-Throttling )が実装されているものがあるので、ベンチのかけ過ぎには注意が必要です。この場合、低下した速度はSecure Eraseでは回復せず、使用時間が経過するのを待つしかないようです。OCZは実装、Intel SSD 520は非実装らしいですが、THNSNS120GBSPはどうなんでしょうね。

    返信削除
    返信
    1. cuttingedge様

      ご指摘、ありがとうございます。一周目だけが速いという現象をすっかり忘れておりました。テストをしながら、SF-1200のときにそういえばこういう現象あったな、と思い出した次第です。

      Sandforce Life Time Performance throttlingの機能ですが、東芝さんはどうしたんでしょうね。僕も気になります。

      削除
  2. はじめまして、いつも参考にさせていただいています。
    私は仕事上、Linux上でのSSDパフォーマンス測定をする機会が良くあるのですが、特に容量分書き込んだ後のパフォーマンス低下に関しては気をつけて見ています。
    私のテストのやり方は secure-erase直後、ddコマンドを使用して容量分(+α) zero fillした後、(SFの場合だけ)容量分 random dataで書き潰した後 の3つのパターンでテストしています。

    結果は Marvelでも SFでも、リード、ライト共に、かなり速度低下します。特に最近のMarvelを使用したSSDはリードが半分程度、ライトが10分の1以下程度と、とても使えた速度では無いのですが、そのような記事をあまり見ることがなく、不思議に思っています。
    今回同じような話しが出ていましたので、思わず書き込んでしまいましたが、そのような現象は、ご存知ではありませんか?
    例えば書込みパフォーマンスが落ちないと評判の PX-256M2Pでも、容量分書き込んだ直後はビックリするくらい遅くなるのです...

    返信削除
    返信
    1. 上記のLinuxについては、僕の方では未確認ですが、ライトが10分の1以下になっているなら、内部の状態は、IOMeterで4KBのランダムライト延々とやったときと同じような状態になっているのだと推測されます。この状態では、どのメーカーのSSDもSecureErase後とはかけ離れた性能になると思います。常にIOが発生しているという状態を想定する限り、特に書き込みに関しては、このあたりが限界かもしれません。

      また、あくまで個人的な意見ですが、このようなワーストケースは、実使用環境とはかけ離れているのであまり気にしなくても良いと考えています。

      というのも、実使用環境では、Trimで消去可能な論理LBAが通知されますし、同じLBAに対して書き込みが発生すれば、書き込み前のそのLBAに対応する物理アドレスは、消去可能なブロックして登録されます。

      SSDは、これらの情報を用いてイレース処理を行いすぐに書き込み可能なページを増やすように設計されています。このような機能があるので、常にIOが発生しているような特別な環境を除き、個人使用などの一般的な使用環境では、ご指摘のような状況にはなかなかならないのではないかと思います。

      また、リードの速度低下は、コントローラのCPUパワー不足も絡んでいるのではないかと思います。たとえば、同じシリーズの製品でも容量が少ない製品の方が速度低下が少ない場合は、恐らくですが、コントローラがサチっているのではないでしょうか。コントローラのCPUパワーが問題なら、時間が解決してくれると思います。

      削除
    2. ありがとうございます。返信が遅くなりすみません。
      最新LinuxではTrimが使えるようになってきていますので、気にしすぎかもしれませんね。
      今後もためになる記事を期待しております。
      よろしくお願いいたします。

      削除