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 年は書きたくなったときだけ書くことにします。


VMware Labs の Onyx に Web Client 用が出ていた

ぜんぜん知らなかったのだけれど、ふと VMware PowerCLI Blog を見たら、VMware Labs の Onyx の Web Client 対応版、Onyx for Web Client のリリースの案内が出ていた。

System Requirements には vSphere Web Client 6.0 用と書いてある。6.0 の Web Client から 5.5 につなげば 5.5 でも使えそう(後方互換、あったよね?)。

Onyx というのは、vSphere Client の操作を PowerCLI や C# や vCO 用の JS などのコードにしてくれるとても便利なもので、ぼくも三年前に『vSphere Client の操作を PowerCLI のコードにしてくれる VMware の Onyx がすごく便利』というエントリを書いている。

このエントリ、いまでもちょくちょくアクセスがあるのだけれど、この末尾にこんな一文を入れていた。

vSphere 5.1 からは vSphere Client ではなくて vSphere Web Client が標準になってくるので、Onyx たんがアップデートしてくれないといずれ使えなくなる疑惑がある。

結局、従来の C# 版クライアント用の Onyx も 2014 年までは継続的にアップデートされていて、なんだかんだで vSphere 5.5 の C# 版クライアントでも使えてはいる。とはいうものの、根本的に C# 版クライアントだとできないことも多いわけで。

Web Client 用のが出てくれないとそのうち困りそうだなあと、このときからつらつら考えてはいたのだけれど、無事にリリースされてくれてよかった。安心した。


PowerShell と bash で任意のコマンドの出力の全行頭にタイムスタンプを付ける

Tera Team でログを取るときの “タイムスタンプ” オプションみたいなことを、OS のネイティブの機能でやりたいシーンがあった。一時的な人力監視とか作業の証跡とかで。

以下、Windows の場合(PowerShell)と Linux の場合(bash)のそれぞれで。

Windows の場合(PowerShell)

ワンライナでやる

こうする。

<任意のコマンド> | foreach-object {(get-date -f "[yyyy/MM/dd HH:mm:ss.ff] ") + "$_"}

コマンドによっては表示が崩れるので、その場合は Out-String -Stream を通してやるとだいたいうまくいく。

<任意のコマンド> | out-string -stream | foreach-object {(get-date -f "[yyyy/MM/dd HH:mm:ss.ff] ") + "$_"}

結果、こうなる。

PS> ping 8.8.8.8 -t | foreach-object {(get-date -f "[yyyy/MM/dd HH:mm:ss.ff] ") + "$_"}
[2015/11/02 01:04:43.31]
[2015/11/02 01:04:43.32] 8.8.8.8 に ping を送信しています 32 バイトのデータ:
[2015/11/02 01:04:43.32] 8.8.8.8 からの応答: バイト数 =32 時間 =7ms TTL=56
[2015/11/02 01:04:44.32] 8.8.8.8 からの応答: バイト数 =32 時間 =9ms TTL=56
[2015/11/02 01:04:45.32] 8.8.8.8 からの応答: バイト数 =32 時間 =4ms TTL=56
[2015/11/02 01:04:46.32] 8.8.8.8 からの応答: バイト数 =32 時間 =12ms TTL=56

関数にする

関数にする場合は、例えばこんな感じ。

function add-timestamp {
	[cmdletbinding()]
	param (
		[parameter(valuefrompipeline = $true, mandatory = $true)][psobject] $object,
		[string] $format = "[yyyy/MM/dd HH:mm:ss.ff] ",
		[switch] $trim
	)
 
	process {
		$object | foreach-object {
			if ($trim) {
				(get-date -f $format) + "$_".trimend()
			} else {
				(get-date -f $format) + "$_"
			}
		}
	}
}

-format(-f でもよい)で任意のフォーマットを指定できる。何も指定しなければデフォルト(”[yyyy/MM/dd HH:mm:ss.ff] “)。

-trim(-t でもよい)は、行末の不要な空白を削除するオプション。なにかの結果を format-table してから add-timestamp に渡すと、行バッファがあふれて折り返されて、全行間に空行が入って見えることがあるので、これを見掛け上抑止するためのもの。

使うときはこんな感じ。ワンライナの場合と同様、場合によっては out-string -stream を噛ませた方がよさそう。

<任意のコマンド> | add-timestamp
<任意のコマンド> | add-timestamp -f "<HH:mm:ss> "
<任意のコマンド> | add-timestamp -t
<任意のコマンド> | out-string -stream | add-timestamp

結果、こうなる。

PS> ping 8.8.8.8 -t | add-timestamp
[2015/11/02 01:16:18.65]
[2015/11/02 01:16:18.65] 8.8.8.8 に ping を送信しています 32 バイトのデータ:
[2015/11/02 01:16:18.66] 8.8.8.8 からの応答: バイト数 =32 時間 =4ms TTL=56
[2015/11/02 01:16:19.66] 8.8.8.8 からの応答: バイト数 =32 時間 =4ms TTL=56
[2015/11/02 01:16:20.66] 8.8.8.8 からの応答: バイト数 =32 時間 =5ms TTL=56
[2015/11/02 01:16:21.66] 8.8.8.8 からの応答: バイト数 =32 時間 =8ms TTL=56

Linux の場合(bash)

ワンライナでやる

こうする。

<任意のコマンド> | awk '{print strftime("[%Y/%m/%d %I:%M:%S] ") $0}'

strftime() はミリ秒単位の表示ができないっぽい。date で代替もできなそう[1]だし、しかたない。

結果、こうなる。

[kuro@localhost ~]$ vmstat 1 | awk '{print strftime("[%Y/%m/%d %I:%M:%S] ") $0}'
[2015/11/01 05:04:04] procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
[2015/11/01 05:04:04]  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
[2015/11/01 05:04:04]  1  0      0 483204  23324 363936    0    0   145     2   32   44  0  1 99  0  0
[2015/11/01 05:04:05]  0  0      0 483172  23324 363960    0    0     0     0   26   36  0  0 100  0  0
[2015/11/01 05:04:06]  0  0      0 483172  23324 363960    0    0     0     0   26   36  0  0 100  0  0
[2015/11/01 05:04:07]  0  0      0 483172  23324 363960    0    0     0     0   27   42  0  0 100  0  0

関数にする

関数にする場合は、例えばこんな感じ。

#!/bin/bash
function add-timestamp () {
        f="[%Y/%m/%d %I:%M:%S] "
        for opt in "$@"; do
                case "$opt" in
                        '-f' | '-format' )
                                f="$2"
                                ;;
                esac
        done
        cat - | awk "{print strftime(\"$f\") \$0}"
}

-format(-f でもよい)で任意のフォーマットを指定できる。何も指定しなければデフォルト(”[%Y/%m/%d %I:%M:%S] “)。

こうやってつかう。

<任意のコマンド> | add-timestamp
<任意のコマンド> | add-timestamp -f "<%I:%M:%S> "

結果、こうなる。

[kuro@localhost ~]$ vmstat 1 | add-timestamp
[2015/11/01 05:18:48] procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
[2015/11/01 05:18:48]  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
[2015/11/01 05:18:48]  2  0      0 482800  23648 364060    0    0   110     2   30   42  0  0 99  0  0
[2015/11/01 05:18:49]  0  0      0 482768  23648 364060    0    0     0     0   33   46  0  1 99  0  0
[2015/11/01 05:18:50]  0  0      0 482768  23648 364060    0    0     0     0   27   38  0  0 100  0  0
[2015/11/01 05:18:51]  0  0      0 482768  23648 364060    0    0     0     0   23   37  0  0 100  0  0

どうにかしてミリ秒出せないかな、これ。


  1. やってみたら全行のタイムスタンプが同じ時刻になってダメだった []

ウクレレベースのジャックを交換する

Rubinetto で使っているウクレレベースのジャックが接触不良気味だったので交換。

ウクレレベースは KALA の UBASS-SMHG-FS というモデル。これについているピックアップシステムは、Shadow の SH NFX EQ-T UK というものらしい。


ジャックは金属の弾性を利用してプラグの固定と導通の確保を同時に実現する構造なので、極の曲がりっぷりが弱くなるとユルくなって導通も死ぬ。特に何もしなくても、経年劣化で死ぬ。

保証期間内であれば販売店持ち込みが楽だけれど、すでに過ぎていたし、難しい話でもないので自分で。

外す

本体の裏には作業用の穴がある。蓋は磁石での固定なのですぐ外せる。


ジャックは内と外の両側からのナットの締め付けで固定されているので、どちらかのナットを外して抜き取る。

DSC01623

調べる

元の配線がわからないと部品の交換ができないのだけれど、インタネットでは配線図が見つけられなかったので実物を基に書き起こした。

模式的に描くとこう。

似非回路図っぽくするとこう。いろいろと省略しているけれど。

ubass02

バッテリとプリアンプのグラウンドが両方ともジャックのスリーブにつながっているのがめずらしいけれど、シールドを挿さない状態(リングとスリーブがショートしない状態)でもチューナ機能を使えるようにするためかな、たぶん。

チューナ側にも別にスイッチがあるから、きっとそういうことだと思う。

交換する

配線がわかれば、あとは新しいジャックを同じ配線で繋ぐだけ。今回買ったのは SCUD の EP=JACK2。

最初にブッシングを通さないと詰む。ありがちなミスだけれどまじで実際やらかした。

あとは適当に熱収縮チューブで絶縁しながら繋いでいく。

繋ぎ終わったらこの時点でいちど音を出してみた。問題なし。

あとは取り付け。

板の厚みを適当に読んで内側のナットの位置を決めたら、外側から締め付けてやる。

内側のナットが外側すぎると、シールドが挿し込みきれなくなって接触不良につながるので気をつける。内側のナットの位置はとてもだいじ。

固定できたらブッシングも締め付けて、外側にキャップをつけて完了。

おわり。