So-net無料ブログ作成
検索選択

プチフリ SSD いまそこにある苦労 [がらくた日記]

SSD 購入者で話題になるのがプチフリである。

細かなランダムWriteを繰り返すと、Write部分のパフォーマンス低下にトリガーされ、読み込みも遅延することにより、数秒から数十秒のあいだシステムフリーズしたような状態のことを指す。

プチフリこの、プチフリは特定のフラッシュコントローラーの現象であることが解っていたため、このコントローラーをつかっているSSDを避けて購入したつもりなのがPhotoFast G-Monster PF25S128GSSD だったのだが、長期間つかっているうち、明らかにプチフリを起こすようになったところを見ると、選択は正しくなかったらしい。 orz

問題が発生しないと確定しているのは、インテルなどハイエンド系SSDであり、また、最近出てきた、内部キャッシュ尽きの機種であるため買い換えたばかりで手が出ない。そこで、対策を行ってみることにした。

対策は2つに別れる。最初のカテゴリーは設定により、書き込みそのものを抑制することであり、

1.スワップメモリーの停止
2.インデックスの未使用やNTFSファイルシステムの設定などによる、抑止
3.RAMdiskの活用による、ブラウザーキャッシュなどの抑止

二つ目のカテゴリーが、「書き込みそのものをまとめる」ことであり、書き込みをプリフェッチする、ドライバーレベルの対応

1.SSD専用ドライバー
 http://www.easyco.com/home/index.htm

2.EWF  Enhanced Write Filter 
3.SteadyState
http://www.microsoft.com/japan/windows/products/winfamily/sharedaccess/default.mspx

2は、書き込みをメモリーに蓄積するしくみで、3は、本来、システムの書き換えを防ぐ仕組みなのだが、そのなかのディスクへの書き込みをフェッチし、差分ファイルとしてまとめる仕組み を書き込み回数の抑制に利用しようというものだ。

このなかで、もっとも手軽な SteadyState を適用してみた。

して、結果として、きわめて効果的だった。うそのようにプチフリの症状がなくなる。細かい書き込みの抑制が本質的にパフォーマンスに寄与していると言うことだ。反面差分を再起動の時に反映するため、起動時間が極めて長くなる。

ある意味、起動時間の短縮のためにSSDしたのなら本末転倒となる。

ちなみに、RAMDISK に関して、フリーのものもずいぶん出てはいるのだがメモリーを4G積んでいたため RamPhantom 3 を利用してみた。32ビットOSがアクセスできない領域の活用のためである。

これはこれで、ブラウザーのキャッシュ領域として利用するのであれば極めて快適である。



個人的には、SteadyState による解決は評価にあたいするのだが、これからやる人であれば、まずはプチフリを起こさないSSDを買うべきだろう。また、不幸にして買ってしまったのなら、遠からず 安価なドライバー が出てくるような気がするので、それまでの回避策として SteadyState をつかうということだろうか。

nice!(0)  コメント(8)  トラックバック(1) 

nice! 0

コメント 8

Hiroshi

RamPhantom 3 & Skype

どうも、RamPhantom 3 導入後 temp or TMP ファイル領域をRAMDISKに設定したらSkype が「I/Oエラー」を返し、ログインできないようになった。

どうやらSkype は、起動時にtemp or TMP領域に、参照ファイルを作成し、起動後は、それを読み取れないとログイン出来ないのだが、

RAMDISK が起動後に作成され

Skype -> Ramdisk の順番であるために エラーとなるらしい。

あらためて、Skypeの再起動を行うことにより正常に利用できた。RAMDISK をバックアップするモードで生成すれば問題ないのかもしれない。


by Hiroshi (2009-04-23 02:26) 

Hiroshi

RamPhantom 3 &Skype
バックアップ設定にしたら、起動時のエラーは起きなくなった。
by Hiroshi (2009-04-23 11:54) 

まっしゅ

SSDのプチフリに関しては、空き領域のデフラグで解消する、という話がありますね。まあ空き領域が再度断片化すれば、デフラグしないといけなくなりますが。
一部にはSSD専用のデフラグソフトが出始めているようです。
by まっしゅ (2009-04-23 15:46) 

Hiroshi

おおっSSDの特性に合わせたデフラグでプチフリ防止ですか。面白いですね。

私見では、SSD向けのコントローラーで回避するより、OSレベルで、回避して、安価なフラッシュモジュールを積めるようするのが正しい方向性な気がしてるので、MSあたりも次のWindowsあたりで対応して欲しいですね。
既に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) 

jniino

ここにSSDのプチフリをデフラグで解消って話が載ってますので、ご参考まで。
http://orbit.cocolog-nifty.com/supportdiary/2009/03/ssd-3f22.html

あとLinuxでもカーネルレベルでSSD用のFilesystemどうするって議論があったらしいですが、リーナスが「んなもんはデバイスの方で透明化するのがスジだろ」って一蹴したとか聞いたことがあります。
by jniino (2009-04-28 01:01) 

Hiroshi

Diskeeper 大喜びですよね。

Linux でフラッシュ対応が検討されたのですか。リーナスの対応をみると、組み込みLinuxの人たちの苦労が忍ばれます。
 カーネルに入れることに関して言えばフラッシュの特性が変化の最中であり流動的なため問題はあるのかもしれませんね。ただ、リード動作とライト動作の速度性大きいとか、デバイスモデルを入れることは組み込みターゲットを考えれば意義あることなんですが、カーネルにデバイス特性などの複雑化の要因を持ち込みたくないのでしょうね。

 私見としてはI/O応答の高速性を要求されない動作領域、つまりASIC的な応答を要求されない部分、レベルウェアリング、遅延書き込み、ファイルシステム的部分は、はやり、ドライバーレベルで対応するべきだと思っています。
 なにより、上位層の方がアプリケーションの動作も把握しやすいですしメモリーリソースもふんだんに利用でき、高速CPUを利用できますから。

by Hiroshi (2009-04-29 03:14) 

コメントを書く

お名前:
URL:
コメント:
画像認証:
下の画像に表示されている文字を入力してください。

トラックバック 1

この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。

×

この広告は1年以上新しい記事の更新がないブログに表示されております。