プチフリ ＳＳＤ いまそこにある苦労 [がらくた日記]
SSD 購入者で話題になるのがプチフリである。
細かなランダムＷｒｉｔｅを繰り返すと、Ｗｒｉｔｅ部分のパフォーマンス低下にトリガーされ、読み込みも遅延することにより、数秒から数十秒のあいだシステムがフリーズしたような状態のことを指す。
プチフリこの、プチフリは特定のフラッシュコントローラーの現象であることが解っていたため、このコントローラーをつかっているＳＳＤを避けて購入したつもりなのがPhotoFast G-Monster PF25S128GSSD だったのだが、長期間つかっているうち、明らかにプチフリを起こすようになったところを見ると、選択は正しくなかったらしい。 orz
問題が発生しないと確定しているのは、インテルなどハイエンド系ＳＳＤであり、また、最近出てきた、内部キャッシュ尽きの機種であるため買い換えたばかりで手が出ない。そこで、対策を行ってみることにした。
対策は２つに別れる。最初のカテゴリーは設定により、書き込みそのものを抑制することであり、
１．スワップメモリーの停止
２．インデックスの未使用やＮＴＦＳファイルシステムの設定などによる、抑止
３．RAMdiskの活用による、ブラウザーキャッシュなどの抑止
二つ目のカテゴリーが、「書き込みそのものをまとめる」ことであり、書き込みをプリフェッチする、ドライバーレベルの対応
１．ＳＳＤ専用ドライバー
http://www.easyco.com/home/index.htm
２．EWF Enhanced Write Filter
３．SteadyState
http://www.microsoft.com/japan/windows/products/winfamily/sharedaccess/default.mspx
２は、書き込みをメモリーに蓄積するしくみで、３は、本来、システムの書き換えを防ぐ仕組みなのだが、そのなかのディスクへの書き込みをフェッチし、差分ファイルとしてまとめる仕組み を書き込み回数の抑制に利用しようというものだ。
このなかで、もっとも手軽な SteadyState を適用してみた。
して、結果として、きわめて効果的だった。うそのようにプチフリの症状がなくなる。細かい書き込みの抑制が本質的にパフォーマンスに寄与していると言うことだ。反面差分を再起動の時に反映するため、起動時間が極めて長くなる。
ある意味、起動時間の短縮のためにＳＳＤしたのなら本末転倒となる。
ちなみに、RAMDISK に関して、フリーのものもずいぶん出てはいるのだがメモリーを４Ｇ積んでいたため RamPhantom 3 を利用してみた。３２ビットＯＳがアクセスできない領域の活用のためである。
これはこれで、ブラウザーのキャッシュ領域として利用するのであれば極めて快適である。
個人的には、SteadyState による解決は評価にあたいするのだが、これからやる人であれば、まずはプチフリを起こさないＳＳＤを買うべきだろう。また、不幸にして買ってしまったのなら、遠からず 安価なドライバー が出てくるような気がするので、それまでの回避策として SteadyState をつかうということだろうか。
細かなランダムＷｒｉｔｅを繰り返すと、Ｗｒｉｔｅ部分のパフォーマンス低下にトリガーされ、読み込みも遅延することにより、数秒から数十秒のあいだシステムがフリーズしたような状態のことを指す。
プチフリこの、プチフリは特定のフラッシュコントローラーの現象であることが解っていたため、このコントローラーをつかっているＳＳＤを避けて購入したつもりなのがPhotoFast G-Monster PF25S128GSSD だったのだが、長期間つかっているうち、明らかにプチフリを起こすようになったところを見ると、選択は正しくなかったらしい。 orz
問題が発生しないと確定しているのは、インテルなどハイエンド系ＳＳＤであり、また、最近出てきた、内部キャッシュ尽きの機種であるため買い換えたばかりで手が出ない。そこで、対策を行ってみることにした。
対策は２つに別れる。最初のカテゴリーは設定により、書き込みそのものを抑制することであり、
１．スワップメモリーの停止
２．インデックスの未使用やＮＴＦＳファイルシステムの設定などによる、抑止
３．RAMdiskの活用による、ブラウザーキャッシュなどの抑止
二つ目のカテゴリーが、「書き込みそのものをまとめる」ことであり、書き込みをプリフェッチする、ドライバーレベルの対応
１．ＳＳＤ専用ドライバー
http://www.easyco.com/home/index.htm
２．EWF Enhanced Write Filter
３．SteadyState
http://www.microsoft.com/japan/windows/products/winfamily/sharedaccess/default.mspx
２は、書き込みをメモリーに蓄積するしくみで、３は、本来、システムの書き換えを防ぐ仕組みなのだが、そのなかのディスクへの書き込みをフェッチし、差分ファイルとしてまとめる仕組み を書き込み回数の抑制に利用しようというものだ。
このなかで、もっとも手軽な SteadyState を適用してみた。
して、結果として、きわめて効果的だった。うそのようにプチフリの症状がなくなる。細かい書き込みの抑制が本質的にパフォーマンスに寄与していると言うことだ。反面差分を再起動の時に反映するため、起動時間が極めて長くなる。
ある意味、起動時間の短縮のためにＳＳＤしたのなら本末転倒となる。
ちなみに、RAMDISK に関して、フリーのものもずいぶん出てはいるのだがメモリーを４Ｇ積んでいたため RamPhantom 3 を利用してみた。３２ビットＯＳがアクセスできない領域の活用のためである。
これはこれで、ブラウザーのキャッシュ領域として利用するのであれば極めて快適である。
個人的には、SteadyState による解決は評価にあたいするのだが、これからやる人であれば、まずはプチフリを起こさないＳＳＤを買うべきだろう。また、不幸にして買ってしまったのなら、遠からず 安価なドライバー が出てくるような気がするので、それまでの回避策として SteadyState をつかうということだろうか。
2009-04-21 21:54
nice!(0)
コメント(8)
トラックバック(1)
カスタムぺイン2
RamPhantom 3 & Skype
どうも、RamPhantom 3 導入後 temp or TMP ファイル領域をRAMDISKに設定したらSkype が「Ｉ／Ｏエラー」を返し、ログインできないようになった。
どうやらSkype は、起動時にtemp or TMP領域に、参照ファイルを作成し、起動後は、それを読み取れないとログイン出来ないのだが、
RAMDISK が起動後に作成され
Skype -> Ramdisk の順番であるために エラーとなるらしい。
あらためて、Ｓｋｙｐｅの再起動を行うことにより正常に利用できた。RAMDISK をバックアップするモードで生成すれば問題ないのかもしれない。
by Hiroshi (2009-04-23 02:26)
RamPhantom 3 &Skype
バックアップ設定にしたら、起動時のエラーは起きなくなった。
by Hiroshi (2009-04-23 11:54)
SSDのプチフリに関しては、空き領域のデフラグで解消する、という話がありますね。まあ空き領域が再度断片化すれば、デフラグしないといけなくなりますが。
一部にはSSD専用のデフラグソフトが出始めているようです。
by まっしゅ (2009-04-23 15:46)
おおっＳＳＤの特性に合わせたデフラグでプチフリ防止ですか。面白いですね。
私見では、ＳＳＤ向けのコントローラーで回避するより、ＯＳレベルで、回避して、安価なフラッシュモジュールを積めるようするのが正しい方向性な気がしてるので、ＭＳあたりも次のＷｉｎｄｏｗｓあたりで対応して欲しいですね。
既にTurboBoost の実装で十分デバイスの特性は分析してると思ううんですがどうでしょう。
by Hiroshi (2009-04-24 01:45)
なんか，とっても，unixのファイルシステムが
出来上がるプロセスを，再訪しているような
感じがしますね．
（低速のウインチェスターディスクしかないから
なるべくデータを書くのはまとめて，アロケーションテーブルも
メモリーで展開→ファイルのアロケーションがずれることが
あるので，fsckで自動サルベージ）
だったとおもうんだけど，もう20年以上前の知識なので
まちがってるかな？
by 石原茂和 (2009-04-24 09:16)
SSDに最適化したファイルシステムが出てくるの待ちでしょうね。＞プチフリの根本解決
Windows7でもSSD対応が入っているらしいですが。
by まっしゅ (2009-04-24 15:16)
ここにSSDのプチフリをデフラグで解消って話が載ってますので、ご参考まで。
http://orbit.cocolog-nifty.com/supportdiary/2009/03/ssd-3f22.html
あとLinuxでもカーネルレベルでSSD用のFilesystemどうするって議論があったらしいですが、リーナスが「んなもんはデバイスの方で透明化するのがスジだろ」って一蹴したとか聞いたことがあります。
by jniino (2009-04-28 01:01)
Diskeeper 大喜びですよね。
Linux でフラッシュ対応が検討されたのですか。リーナスの対応をみると、組み込みＬｉｎｕｘの人たちの苦労が忍ばれます。
カーネルに入れることに関して言えばフラッシュの特性が変化の最中であり流動的なため問題はあるのかもしれませんね。ただ、リード動作とライト動作の速度性大きいとか、デバイスモデルを入れることは組み込みターゲットを考えれば意義あることなんですが、カーネルにデバイス特性などの複雑化の要因を持ち込みたくないのでしょうね。
私見としてはＩ／Ｏ応答の高速性を要求されない動作領域、つまりＡＳＩＣ的な応答を要求されない部分、レベルウェアリング、遅延書き込み、ファイルシステム的部分は、はやり、ドライバーレベルで対応するべきだと思っています。
なにより、上位層の方がアプリケーションの動作も把握しやすいですしメモリーリソースもふんだんに利用でき、高速ＣＰＵを利用できますから。
by Hiroshi (2009-04-29 03:14)