ウイルス対策ソフトをご利用の場合、「トロイの木馬」を誤検出する記事があります。警告が出た際は、こちらの記事をごらんの上、お知らせいただければ幸いです。

« あなたは誰ですか? | トップページ | 仮想空間の可能性。 »

2009年3月13日 (金)

結論:SSDだからこそデフラグは要ります。でも条件付。

このエントリーをはてなブックマークに追加 このエントリーを含むはてなブックマーク この記事をクリップ! BuzzurlにブックマークBuzzurlにブックマーク

先日、SSDを換装したノートパソコン。
期待された(?)プチフリーズはほとんど発生せず、快調に使えていたわけですが…。
それでは面白くもなんともないので、ここは一発、無理くりにでもプチフリーズを発生させるべく、いろいろやってみることにしました。

で、タイトルにも書きましたが、

SSDにもデフラグは要ります!!ってか必須です!!でも条件付。

実際、別のサイトの実験結果(こちらの方がしっかり書かれてます)でもそういう結論は出てましたが、今回はたまたま別方向で検証してみた結果を書いておきます。

-----

たまたま、もともとのハードディスクの断片化状態は悪くなかったので、結果的にはいい状態で、快調ではありました。

じゃ、ここはいっちょ、わざと断片化させてみますかね。

その昔、「デデフラグ」という、ハードディスクをムリヤリ断片化させるソフトがあったのを思い出してぐぐってみましたら…ありました。

デデフラグ :仰天イカモノ堂

…MacOS用でした…。
ああ、そうか、今は亡き月刊MacPowerで見たんだな…。

さらに突っ込んで調べてみたら…ありました。

デ・デフラグ :笑ってパソコン

では早速やってみましょう。
とりあえず「使用前」のベンチということで、HDD換装直後のものを提示。

使用前

Sequential Read : 80.394 MB/s
Sequential Write : 39.261 MB/s
Random Read 512KB : 76.863 MB/s
Random Write 512KB : 18.081 MB/s
Random Read 4KB : 12.657 MB/s
Random Write 4KB : 0.298 MB/s

Test Size : 1000 MB

まぁこんな感じ。

さて、「デ・デフラグ」を実行。
ソフト自体は、コマンドプロンプトの黒画面で地味~に進行。
さて、結果は…。

断片化発生?
↑クリックで拡大します

…はて?
ずいぶんとブルーの帯が多いようですが…。
実際、分析してみたら、ファイル自体の断片化はほとんどありません。
「デ・デフラグ」のサイトでも、「断片化しないことがある」と書かれてますので、こちらも同じなのでしょう。
まぁ、「ジョークソフト」と銘打ってますので、こんなもんでしょう。仕方ないですね。
同じジョークソフトとはいえ、Mac版の本家「デデフラグ」には、「みじん切り」オプションがあります。できたらここまでして欲しかったなぁ~。
とりあえず、先日書いた断片化についての記事では、コメント欄などで散々

  • 毎日デフラグしてたからプチフリーズの原因は断片化!と決め付けるのは安易だ
  • SSDは読み出しが速いから断片化なんて関係ない
という根拠のない決め付けコメントなどが見受けられたので、図らずもファイル自体はほとんど断片化していないこの状況でベンチを取ってみれば、はっきりしそうです。

使用後

Sequential Read : 77.192 MB/s
Sequential Write : 14.739 MB/s
Random Read 512KB : 74.948 MB/s
Random Write 512KB : 4.453 MB/s
Random Read 4KB : 12.378 MB/s
Random Write 4KB : 0.067 MB/s

Test Size : 1000 MB

…うーむむむむむ。なんじゃこりゃ?
リードは「使用前」よりやや下がってはいるものの、ライトは…ひどい。こりゃひどいな。半分以下だ。SSD交換前に測ったHDDよりも遅い。

さて、この状況で使ってみたら…いやぁ、ひどいもんです。
使ってる状況をお見せできないのが残念ですが、何かするたびにひっかかります。
「使用前」は、ブラウザとかはかなり快適に使えていたのに、「使用後」は…表示まで時間がかかるならまだしも、タイムアウトで「ページが表示できません」になってしまうことも。
なんかいろいろひどい状態です。
こういう時の使用感を定量的に示せる基準が欲しいもんですが…グラフィックベンチとかかければいいのかも知れませんが、このパソコンはかなり非力なノートですので、使えるものも限られます。
まぁ使用前・使用後の比較には使えるのかもしれませんが…。

今回は、図らずもファイル断片化なし・空き領域の断片化あり状態での検証ができました。
予想以上にパフォーマンスが下がったのにはびっくりです。

さてさて、一応こうなることは折り込み済みで試しにやってみたのはいいけど、メンテ用のパソコンですので、できれば早いところ復旧させたい。
ということで、空き領域のデフラグをもきっちりやってくれる「Defraggler(「Defragger」ではなく「Defraggler」です)」というソフトを使ってみました。

断片化ファイルだけを最適化できるデフラグソフト「Defraggler」正式版が公開 :窓の杜

これは、先日の記事のコメントでもご紹介させていただいた、

■[SSD]SSDのデフラグの効果を検証 :博士課程大学院生の現実逃避日記

ででも使用されているソフトです。
Windowsのデフラグは、ファイルの断片化がない状態では、空き領域の断片化解消をしてくれないようなので、あまり時間もないことですし、こちらを使ってみることに。
結果は…。

断片化解消!
↑クリックで拡大します

はい、かなり空き領域の断片化が解消できました。
この環境では、数時間かかりましたが…。

ということでまたベンチ。

Crystaldiskmark2009031401

Sequential Read : 77.915 MB/s
Sequential Write : 41.210 MB/s
Random Read 512KB : 74.428 MB/s
Random Write 512KB : 16.915 MB/s
Random Read 4KB : 9.686 MB/s
Random Write 4KB : 0.277 MB/s

Test Size : 1000 MB

…ほぼ元通り…ですかね。
リードはほぼ変わりなく、ライトのみ改善した、というのがよくわかります。

実際の使用感も、ほぼ元通り。
漢字変換で引っかかったり、ブラウザが止まってしまうとかの現象は出なくなりました。
かなり快適な状態です。

まとめてみると…

  • 空き領域の断片化は、書き込み性能に著しく影響が出る。
  • ファイルの断片化が少なくて読み出しが速い状態でも、空き領域の断片化で書き込みが遅くなると、Windowsのパフォーマンスにはかなり影響が出てくる
ということ。
出現当初から「SSDは断片化は関係ない」と言われ続けていたわけですが、起動ドライブへの書き込みが頻発するWindowsにおいては、空き領域の断片化により、HDD以下の書き込み性能に落ち込むことがあるため、HDD以上にデフラグが必要と言えます。

つまり、SSDのウェアレベリングによる「意図的な断片化」処理と、ATA接続でOSへ「論理的にHDDだと見せかける」処理における「仮想的な断片化」処理との兼ね合いによるネックがかなり出てくる、というのは容易に想像できるわけです。

結論:
SSDだからこそデフラグは必須。
ただし空き領域の断片化解消が重要なので、Windows標準のデフラグでは効果が出にくい。

以前の記事で引用した記事、「毎日デフラグ実施」は、繰り返しのデフラグで空き領域の断片化が起こりにくい状態と言えるため、それなりに効果があると言えます。
ただ、デフラグによる寿命低下の検証は、まだまだ未知数です。
SSDのウェアレベリングは、容量が大きくなればなるほど効果が高いので、今後は寿命なんて気にしなくてもよくなるのかもしれませんね。

あとは、ハードディスク前提のファイルシステムではなく、SSD前提のファイルシステムがOSでサポートされれば、OSへ「論理的にHDDですよ」と見せかける処理が必要なくなり、相当な効率アップが見込まれるわけですが…。
OSの開発スピードとSSDの進化スピードのバランスが取れてませんので、当面は、SSDは「羊の皮をかぶった狼」状態になるのではないでしょうか。もったいない話です。

ちなみに、人気blogランキング参加中です。 よろしくお願いします。

このエントリーをはてなブックマークに追加 このエントリーを含むはてなブックマーク この記事をクリップ! BuzzurlにブックマークBuzzurlにブックマーク

2009年03月13日(金) ネットにつながらない・遅い, ハードウェアアップグレード関連, ハードウェア不具合関連(ハードディスク), パソコントラブル, パソコン・インターネット, フリーズ・ブルースクリーン・再起動・電源切れる, 基本操作・便利技関連, 日記・コラム・つぶやき, 起動しない・起動が遅い |

« あなたは誰ですか? | トップページ | 仮想空間の可能性。 »

ネットにつながらない・遅い」カテゴリの記事

ハードウェアアップグレード関連」カテゴリの記事

ハードウェア不具合関連(ハードディスク)」カテゴリの記事

パソコントラブル」カテゴリの記事

パソコン・インターネット」カテゴリの記事

フリーズ・ブルースクリーン・再起動・電源切れる」カテゴリの記事

基本操作・便利技関連」カテゴリの記事

日記・コラム・つぶやき」カテゴリの記事

起動しない・起動が遅い」カテゴリの記事

トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/13757/44364543/void
↑トラックバックをいただく際は、最後の「/void」を抜いてください。お手数ですがよろしくお願いいたします。

※あまりにも無関係なトラックバックが多いため、当面はトラックバックの公開は承認制にしました。トラックバックを送っていただいてもすぐには反映されません。ご了承願います。

※トラックバックをいただく際は、この記事のURLを記事中に記載(もしくはリンク挿入)願います。
この記事と無関係な内容であったり、明らかな宣伝もしくは宣伝活動目的と判断されるもの、トラックバック元がトップページへのリンクであるもの、もしくは当方が不適切と判断されたものは、公開の承認はなされません。あらかじめご了承願います。

この記事へのトラックバック一覧です: 結論:SSDだからこそデフラグは要ります。でも条件付。:

» SSDでもデフラグは必要な理由 トラックバック pclog
結論:SSDだからこそデフラグは要ります。でも条件付。(パソコントラブル出張修理・サポート日記) こちらでSSDを断片化状態にしての実験記事がありました。 ディスクが断片化している状態では、読み込み速度に目立った変化はないようですが書き込み速度は著しく低下して....... 続きを読む

受信: 2009/03/16 20:42:52

» それは世間によくある誤解。SSDのプチフリーズ・デフラグ編。 トラックバック パソコントラブル出張修理・サポート日記
このブログでも、ちょっと前にかなりアクセス数を稼いだ前の記事。はてなブックマークやらリンクによる言及などで散々コメントされたんですが、ちょっと観点が違うんですよね…。 続きを読む

受信: 2009/04/17 21:56:17

コメント

http://www.dosv.jp/other/0903/16.htm にSSDのプチフリーズについてのさらなる検証記事があります。 それにしても手を出したくもちょっと考えたくなりますね。 いろいろ手間かけないとだめだと。

投稿: alphonse1342 | 2009/03/16 12:48:15

ささもとさん、こんにちは。
空き領域のデフラグについては、当のブログにて、ささもとさんのコメントを見ていましたので、いつネタにするか待っていました。
JMicron社のインタビュー記事についても読んでいらっしゃいますか?
また、Tech-On!の以下の記事でも、ファイルの断片化による速度低下の問題について大変有用な情報がまとめられています。
http://techon.nikkeibp.co.jp/article/FEATURE/20090219/165972/?ST=print

投稿: mfigure | 2009/03/16 13:06:31

示しましたURLにもある通り,断片化の影響もあるようですね.ただコントローラーにも依存(キャッシュの有り無し)するとの事で,結局どちらも正しいのだと思います.
ただ,これだけの影響が出るのにもかかわらず,プチフリーズは仕様だと言わんばかりにキャッシュ無しでコントローラーを製品化したメーカーに対しては非常に不快感を覚えます.
一方でDRAMキャッシュを搭載し,プチフリーズと分からなくなるくらいまで性能を改善させたコントローラーを作っているメーカーもあるので,それらを一緒くたに扱い,すべてのSSDがデフラグしないとプチフリーズするかのような内容には違和感を覚えます.
まぁ,プチフリーズも結局は程度問題なのでどこまで許容できるか・・・なのですが.

投稿: とおりすがり | 2009/03/16 13:15:29

alphonse1342 さん
mfigure さん
とおりすがり さん

有用な情報をありがとうございます。
今回は、あえて「プチフリーズ」という言葉をほとんど使わずに書いてます。
定義しづらい現象のため、あえて外しました。

>一方でDRAMキャッシュを搭載し,プチフリーズと分からなくなるくらいまで性能を改善させたコントローラーを作っているメーカーもあるので,それらを一緒くたに扱い,すべてのSSDがデフラグしないとプチフリーズするかのような内容には違和感を覚えます.

逆に、コントローラーがどうとか言ってはばからない意見の方が、私には違和感があります。
そういう人がどう思っているのかはわかりませんが、「ハードディスクドライブ」から「ソリッドステートドライブ」への転換というのは、本来は、ケーブル差し替え程度の安直なレベルではなく、もっと革新的な出来事なんですよね。

私は、一連の記事では、あくまで原理の話をしています。
実験の結果にも合致しましたので、程度の差こそあれ、現状の「HDD置き換え」のインターフェースでは、空き領域の断片化が(プチフリーズとして目立つかどうかは別として)パフォーマンスに影響するのは避けられない、ということは間違いないと思います。

現状のSSDは、フラッシュメモリの宿命として、書き込み寿命対策の「ウェアレベリング」があるため、現状のファイルシステムでは、書き込みがあった場合は、どうあがいても本来やらなくてもいい消去・書き込みが発生します。
コントローラー性能とか、キャッシュとかバッファとかでうまく「目立たなくする」ことはできるでしょうけど、結局は小手先のテクニックであり、根本原因は別にある、ということ。

前の記事のコメントにも書きましたが、結局は起動ドライブに一切の書き込みが行われない形になって、SSDに最適化されたファイルシステムが出現しないと、SSDはその真価を発揮しきれないまま、なんですよね。

だからこそ今のSSDは「時期尚早」であり、「マニアのおもちゃ」であり、誤解を恐れずに言えば「キワモノ」だと思います。
今回提示していただいたTech-On!の記事を読む限りでは、メーカーはとっくに気づいているように思えます。
いかがでしょう。

投稿: ささもと | 2009/03/16 14:29:26

なるへそ(死語)
さっそくDefraggler使ってみます。
最近RAID-SSDにもかかわらず起動が異様に遅くなりました。
立ち上がっちゃえば快適なので何が原因か検証中です。

投稿: ぶいち | 2009/03/16 22:32:44

ぶいち さん
RAIDになると、さらに原因がつかみづらいんじゃないかと思われます。
メディア側からすれば、

記録素子 → SSDコントローラー → RAIDコントローラー → ATAインターフェース

という具合になりますし、RAIDが読み出し時になにか書き込みをしていたりすると、余計にややこしくなりますから…。
お時間があれば、また結果を教えてくださいね。

投稿: ささもと | 2009/03/18 11:36:54

はじめまして。いつも楽しく読ませてもらっています。

ささもとさんの
「結局は起動ドライブに一切の書き込みが行われない形になって、SSDに最適化されたファイルシステムが出現しないと」ですが、前者は既にそういう風に使っているものがあります。

産業用機器にWindowsを搭載するために使用するのですが、HDDでは寿命に心配があるため、CFやSSDにWindowsを搭載しています。
ROM-WINという製品を利用したりするのですが、これはCドライブの書き込みをすべてRAM上に行うことで、一切書込みが発生しないようにしています。
読込みはCドライブから直接行うのですが、書き込みはRAM上に行います。
Cドライブのデータを編集して保存するとRAM上に保存され、次回読み込むときにはRAM上を優先して読み込みます。
欠点としては電源を切ってしまうと、Cドライブのファイルがすべて元通りになることですが、かえってウィルスなどに感染しても電源を入れなおせば元通りというメリットもあったりします。
決まったことしかしない簡易ノートなんかには有効な方法かもしれません。

投稿: ぱちゃぽ | 2009/03/18 13:12:50

メインの内容には関係ありませんが,MacPowerは健在です.
本日18日,最新号発売
http://ascii.asciimw.jp/books/books/detail/978-4-04-867776-9.shtml

投稿: htfs | 2009/03/18 14:19:33

空き領域のデフラグはHDDにも効果はあるのでしょうか?

投稿: にょろにょろ | 2009/03/18 22:49:23

ぱちゃぽ さん
ROM-WINは前回の記事のコメントですでに情報をいただいてますね。
http://orbit.cocolog-nifty.com/supportdiary/2009/02/ssd-f7e3.html#comments
ノートパソコンで、スタンバイ/スリープでの使用なら、かなり快適に使えそうですが…。

htfs さん
昨日の時点では最新号は2008年版でしたので…。
正確に言えば、今は亡き「月刊PacPower」でしょうか。
修正しておきます。

にょろにょろ さん
空き領域のデフラグは、HDDでも有効だと考えます。
即効果が出るかどうかはなんとも言えませんが、空き領域の断片化は、その状態からファイルの書き込みがあるとファイル自体の断片化が発生しやすくなるわけですから、先行きパフォーマンス低下につながりますから。

投稿: ささもと | 2009/03/19 5:39:48

アロケーションユニットサイズの影響があるかも知れません。
アロケーションユニットサイズを大きくするとどうなるでしょうか。

投稿: kururu | 2009/04/03 20:52:13

kururu さん
クラスタサイズの影響というのは、おそらくフラッシュメモリのブロック単位の消去の管理サイズとの絡みということなのでしょうけど、大きくすればいいというわけではなく、管理サイズの倍数と合わせなければ意味がないですよね。
何を根拠にどのサイズにすれば最適か、kururu さんがもしご存知であれば教えてください。

投稿: ささもと | 2009/04/06 5:06:15

クラスタサイズがページサイズより小さい場合、ページサイズより少量の書き込み、読み込みでもページサイズを踏み越えて割り付けられていれば、書き込み、読み込みすべきページ数が増えて遅くならないでしょうか。

投稿: kururu | 2009/04/12 1:23:25

ちょっと前のコメントの返答になりますが…。

kururu さん

…うーん。

SSDに対しての「HDDとみなして書き込みをする」クラスタ管理サイズは、必ずしもSSD内部のフラッシュメモリのブロック消去・書き込みのサイズに反映されるわけではないと思いますよ。
よしんばクラスタサイズがブロックサイズに近づけられるとしても、内部の管理アルゴリズムが明確になっていないので、そこをどう最適化すればいいかは不明です。

ですので、「どのサイズにすれば最適か、kururu さんがもしご存知であれば教えてください」と書いたのですが。
そこの回答が欲しかったんですけどね…。

いずれにせよ、当方はクラスタサイズをいじってまで検証する手間も時間もありませんので、kururu さん自身が実験されてはどうでしょうか。
おそらく、かなりの注目を浴びると思います。

投稿: ささもと | 2009/04/17 10:27:44

コメントを書く




※Spam対策のため、コメント公開時E-Mailは非表示となります。









※当面コメントは承認後の公開となります

« あなたは誰ですか? | トップページ | 仮想空間の可能性。 »