2016 年 5 月のエントリ

HDD を SSD にした話

自宅の PC の HDD を SSD に換装しました。このツイートをしたあとに勢いでぽちった感じです。いつまでもアンポンタンなのは嫌ですからね。


本業が本業だけに、いまだに自宅に SSD が一本もないというと驚かれることもしばしばあったのですが、そんな状況ともようやくおさらばです。

とはいえ、データ用の HDD までぜんぶ SSD にするメリットもあまりないので、ひとまずは C ドライブだけ。中身をまるごとクローンして物理的に置き換えたので、純粋にディスク種別の差異だけを抽出できる状態が得られたことになります。

体感でも起動速度をはじめ随所の挙動が目に見えて速くなったので、正直、定量的に比較するまでもなく圧倒的な効果が得られました、という結論はゆるがないのですが、そんなわけで、せっかくですしもうすこし細かく違いを見ることにします。

写真は撮らなかったので、おいしかったごはんの写真をところどころに挟んでおきます。

買ったもの

Crucial の CT240BX200SSD1 です。

対象の PC

@Sycom の 2008 年くらいのモデル、GZ1000P45 です。

SATA 3.0 が出る前なので、SSD を挿したところで SATA 2.0(3 Gbps)でしか動かないのです。しかたないのです。CPU は Intel Core 2 Quad Q9450 でした。

OS は 2011 年の Windows 7 のクリーンインストール以来、そのまま使い続けているので、相応にもっさりしています。

HDD は 300 GB で、140 GB くらいが使用済みです。

行わせる処理

ベンチマークを走らせても数字的なうれしさしか得られないので、実運用を考えて、『PC を起動させる』ときの様子を観察することにしました。

具体的には、停止状態から電源を入れて、OS が起動して安定するまでの処理の時間とパフォーマンス特性を比較します。ログイン後の処理の様子も観たかったので、ログイン画面が表示されたら直ちに(人力で)ログインするようにします。

起動の完了は、

  • ディスク I/O
  • CPU 使用率

のふたつで(人力で)判断するものとします。つまり、グラフが横ばいで推移しはじめたら完了、ということです。

判断の根拠には、Windows の標準のパフォーマンスモニタを使います。カスタムデータコレクタセットを作成して、タスクスケジューラから OS の起動毎にこれをキックさせるように仕込みました。

この状態での PC の起動を、HDD の場合と SSD の場合とでそれぞれ 2 回行います。

細かいことをいうと、そもそも HDD の場合と SSD の場合とで『電源を入れてからパフォーマンスモニタがキックされるまで』の時間がだいぶ違うはずですが、無視できることにしました。

まとめ

数値上、以下の改善が見られました。


ディスク 所要時間 平均 CPU 使用率 平均ディスク使用率 平均応答時間 平均キュー長 平均帯域幅 平均 IOPS
HDD 12:30 18.0 % 99.4 % 35.4 ms 6.0 5.4 MiB/s 216.4
SSD 3:35 32.3 % 26.8 % 1.0 ms 0.4 7.5 MiB/s 363.2

CPU やディスクの使用率、キュー長や応答時間から、HDD のときは典型的な I/O ボトルネックであったことが読み取れます。

SSD にしたことで、I/O の応答性が上がり、CPU がきちんと使われるようになったようです。

以下、グラフです。なお、先の記述通り HDD と SSD でそれぞれ 2 回計測していますが、似たようなグラフが 2 個できただけだったので、以下ではそれぞれの 1 回目の情報のみ掲載しています。そして SSD 分は起動が完了してしばらくした段階で計測を止めた関係で、グラフが途中までで切れています。

CPU 使用率

25 % くらいで横ばいになったときが起動完了のタイミングです。

HDD のときは CPU がロクに使えていないことがわかります。

ディスク使用率

ディスク使用率は、”100 – % Idle Time” で算出した値です。HDD には余裕がまるでありません。SSD はスパイクで 90 % くらいまで上がりはするものの、まだ余力がありそうです。

帯域幅

劇的なちがい、とはいえないですが、平均でいえば上がっています。

起動処理なのでやはり I/O は読み取りが中心のようです。

帯域幅と時間を掛けると総転送量が求められるはずですが、HDD だと 4 GB、SSD だと 1.5 GB くらいになるのがちょっと謎です。

同じシステムを起動させているなら総転送量も同じくらいになりそうなものですが、パフォーマンスモニタがキックされる前に大半が読み取り済みだったとか、短期間に I/O が集中したことでキャッシュヒット率が上がった(不要ページとしてキャッシュから破棄される前に再利用されてディスクへのアクセスが発生しなかった)とか、なにかあるのかもしれないです。

応答時間

HDD のひどさがすごいです。三桁にまで行くと、馬鹿にされている気さえしてきます。

SSD は優秀です。ほとんどの期間が 1 ms 以下でした。

キュー長

非 RAID 構成なので、単一ディスクに対するキュー長です。通常は 2 以下であるべきなので、HDD は待ちが発生しすぎですね。

SSD はほとんどが 1 以下でした。待たせずにさばけているようです。

IOPS

SSD で 2,500 くらい出ているのは納得ですが、HDD でも IOPS が 750 以上出ているというのが信じられないですね。このカウンタは正しいのでしょうか……。

ブロックサイズ

これはこれ単体ではあまり意味のあるグラフではなさそうです。

おわりに

IOPS と応答時間の相関とか、ブロックサイズと応答時間の相関とか、おもしろい傾向が出てくることを期待して散布図を吐いてみたものの、有意な結果にはなりませんでした。相関が見たいなら、それこそベンチマークツールなどで負荷をかけて、そもそものワークロードを安定させないと、あまり意味がないですね。

なにはともあれ、ディスクがボトルネックであることを確かめる前に SSD を買ったわけですが、ねらい通り速くなってくれてよかったです。ディスクがサチらなくなったので、M/B と CPU をよいものにすればもう少し早くなりそうですね。

よいころあいなので、PC を買い替えがてら、いい加減 Windows 10 にしておきたい気もしています。起動が遅いならクリーンインストールするのがいちばん確実です。


行ったコンサートとか

だいたい一年前の コレ を最後にコンサートのまとめエントリ的なものを書かなくなってしまっていました。

単にそれどころではなくなった、というだけですが、中途半端なのも気持ち悪いからせめて 2015 年分はメモを残しておきます。

  • ソニー吹奏楽団 第 51 回定期演奏会
    • 6 月 27 日(土)練馬文化センター 大ホール
  • libertas ライブ vol. 6 “ピアソラ × 日本の歌”
    • 6 月 14 日(日)MFY サロン
  • ARTE TOKYO 第 5 回定期公演
    • 6 月 21 日(日)東京オペラシティコンサートホール タケミツメモリアル
  • 某社某イベント
    • 8 月 19 日(水)都内某所
  • 全国学校ギター合奏コンクール 2015
    • 8 月 22 日(土)東京芸術劇場 コンサートホール
  • 向日葵ギターアンサンブルコンサート
    • 8 月 29 日(土)和光大学ポプリホール鶴川
  • イ・ムジチ合奏団
    • 10 月 20 日(火)紀尾井ホール
  • イ・ムジチ合奏団
    • 10 月 24 日(土)サントリーホール
  • JAGMO 伝説の音楽祭 – 勇者たちの響宴 –
    • 10 月 25 日(日)新宿文化センター 大ホール
  • サウザンドまつり
    • 11 月 1 日(日)サウザンドシティ 多目的ホール
  • ソニー吹奏楽団 ファミリーコンサート
    • 11 月 3 日(火)大田区民ホール アプリコ
  • 第 5 回 岡上分館カフェコンサート
    • 11 月 28 日(土)岡上分館
  • リード×シエナ ~リードイヤー・クライマックス!~
    • 12 月 12 日(土)東京オペラシティコンサートホール タケミツメモリアル
  • ギタークリスマスコンサート 2015
    • 12 月 20 日(日)杜のホールはしもと

なんだかんだでいろいろ行っているっぽさがあるですね。

イ・ムジチ合奏団の公演に 2 回行けたのはすごくよかったです。ぜんぜん違うプログラムの日を選んだのでまるごとオイシイ感じでした。JAGMO は相変わらずイケイケでした。

2016 年は書きたくなったときだけ書くことにします。