キャッシュの設定とその効果を数値で比べてみてみよう!CrystalDiskMarkZ!


* このページの内容は書きかけです。
こちらはPNG版です。TEXT版はこちらCrystalDiskMarkZtext
TEXT版の方がより数値を正確に理解しやすいです。
[
2010May14 CrystalDiskMarkのバージョンが 3.0.0d になっていた。変更点は言語ファイルと署名とのこと。よって当方は変更の必要無し。
2010May13 一般公開
2010May05 クローズド公開

本ページは

EeePCでWindows7!
初代EeePC 4G-X初期モデルでWindows7を楽しもう!

リンク
から派生したスピンアウトページです
内容が EeePC ありきになっています

■本ページの公開の経緯■
Windows7を8GBのSDHCカードにインストールし、初代 Eee PC で使っています。
チューニングの際、CrystalDiskMarkを改造して設定を詰めたこともあり、
記録の意味も含めてここに公開しておきます。

■前置き■
SATA-HDDではAHCIが使えてNCQ(NativeCommandQueuing)が使えるようになったことにより、
デスクトップでもSCSIのときのような快適さが得られるようになりました。
ところが、体感ですぐにわかる程度にもかかわらず、「意味無い」という人が
少なからずいて、その根拠がCrystalDiskMarkの結果だったりしました。

当時のCrystalDiskMarkは、Queueを使っていない(queueの深さ1)ので効果は計れなかった
わけですが、queueの深さによってパフォーマンスが変わるグラフを見ると納得するようでした。
http://www.storagereview.com/
http://www.storagereview.com/HTS722020K9A00.sr
http://www.storagereview.com/images/HTS722020K9A00_iometer.png

今ではqueueを使ったテストも出来るようになったためか、そういうことを言う人は
少なくなったようです。標準ベンチマークの影響力とはすごいものです。

それで、 EeePC では当たり前のように RAMディスクを使っているわけですが、
これも「大容量メモリが安いので、64bitOSにしてメモリをいっぱい積んだほうが良い」
という人がいます。
これも仕組みを知ってどういうときに効果があり、どういうときに効果が無いかが
わかればよいわけですが、CrystalDiskMarkはキャッシュの効果は計れません。

また、EeePC のユーザー間では知られている HGST Hitachi Microdrive filter Driver と
いうドライバがありまして、こいつは設定によりキャッシュの効きが変わるのですが、
設定毎による効きの違いを数値化して記録しておくと説明の手間も省けます。


というわけで、キャッシュの効果を計れるようにCrystalDiskMarkを改造し、
数値化出来るようにしてみました。

■ download ■
CrystalDiskMarkZ3_0_0b


■キャッシュが効く場合、効かない場合■

システムキャッシュが効くアプリと効かないアプリがあります。
キャッシュが効かないアプリの代表はCrystalDiskMarkほかHDDベンチマークです。
そりゃHDDの性能を計測するのに「実はキャッシュを測定していた」なんてのは話になりません。

逆にキャッシュが効くアプリの代表?は本CrystalDiskMarkZです。(そりゃそうだ)

ようするに、キャッシュを使うか使わないかは、アプリの設計、すなわち
ポリシーに依存します。


たとえば簡単なファイル編集ソフトでも、
「HDD上にあるファイルを編集して、最後に上書き保存したつもりでHDDの電源を切ったら、
なんとまだ上書きされていなかった」
なんてことになったら困るような類のソフトでは、キャッシュさせないように仕組んであります。
またセキュリティ上の理由な場合も。

この手のアプリでは、OSを64bitにして、さらにメモリを大量に積もうと、全然早くなりません。
32bitでかつ少ないメモリのときと同じスピードしか出ないのです。
こういう時は、メモリを積んで RAMDISK を構築し、場合によってはジャンクションを
駆使して RAMDISK 上で動作させるようにすると、劇的に高速化されます。

一方、ログファイルなんかは、アクセスの度にログがHDD盤面に書き終わるまでいちいち
待っていたら、遅くてまったく話になりません。
そこで、「バッファ、キャッシュの制限は特に無し」でログを書き込むようにすると、
OSは即座にログ書き込み終了をアプリに返し、その後OSが5秒毎にまとめてHDDに
記録 (Flush) しています。
扱うサイズが大きくても、それに見合ったメモリがあればそこに溜め込んでくれます。
なので、メモリを積むと快適になります。
この手のアプリでRAMDISKを使っても効果が無いわけではないのですが、効果の程度は
低いので、限られたメモリとのバランスを考えて RAMDISK の設定を詰めましょう。

---

では、具体的にどう仕組んでいるのかというと、CrystalDiskMarkはソースが公開されて
いるのでそれを見てみましょう。


CreateFile 時に FILE_FLAG_NO_BUFFERING のフラグを設定している
FlushFileBuffers でバッファをフラッシュして、CloseHandle で閉じている


これによりメモリキャッシュのバッファに留めておかずに、しっかりHDDを読み書き
するようにしています。

---

ではここでちょっと FILE_FLAG_NO_BUFFERING を削ってみましょう。

CrystalDiskMarkZ3_0_0b

測定対象を HSB-HDD や USBmemory にすると光の点滅加減でアクセスの有無が
わかると思います。

当然ながら、最初の一回目の read はHDDから読むしかないので遅いです。
でも2回目からは点滅の仕方がCrystalDiskMarkとZでは異なっているのが
目で見てわかるでしょう。



■具体的にどんなアプリでキャッシュが効くのか、効かないのか■

おおまかな傾向はありますけど、結局自分が使うアプリでどうなのかが重要なので、


USBメモリや、SDHCのclass2など遅いメディアにインストールして使ってみる
次にRAMディスクにインストールして使ってみる


で比較(アプリ起動時とアプリ終了時ではなく、使った時の違い)して違いがなければ
メモリキャッシュをつかっているし、違いが多ければキャッシュは使われていないので
RAMディスクを使ったほうが良いということになります。

また、プログラム上ではメモリキャッシュを使うようにしていても、サイズが大きくて
キャッシュに収められない場合もあるので、そういうときにもRAMディクスは効果的です。
強制的にメモリ上に優先確保というわけです。


CrystalDiskMarkZではテストサイズをいろいろと変えられますので、
自分のマシンでどの程度の大きさでどういう数値になるか測定してみてください。

また、PCを複数台もっているのなら、それぞれで試してみるとよいでしょう。
メモリーを抜き差しして、搭載メモリー量を変えて測定してみるのも良いです。
マシンによってずいぶん違うのがわかるかと思います。



■本題■
冒頭に書いたように、実はここからが本題です。

SDHC に素のまま OS をインストールした方が良いのか、VHDブートが良いのか
Eee PC ではおなじみ HGST Hitachi Microdrive filter Driver の効果
これらを見ていきます

測定マシン EeePC 4G-X, RAM 2GB DDR2-5400 CL3
      eeectl にて FSB100 ( CPU 900MHz ) に設定
      SDHC 8GB SLC ( 白芝 ) windows7 OS用 EeePCのSDカードスロット使用
      USBmemory 8GB MLC ( RUF2-P8G ) DATA用のためFAT32 EeePCの右奥USBポート
      USB-HDD  EeePCの左側USBポート
      測定時は USB-HDD の windows7 からブートして、SDHC, USBmemoryを測定

ドライブ
C: USB-HDD Windows7 OS
D: EeePC SSD 4GB
F: 8GB MLC FAT32 MS標準ドライバ removableデバイス
G: 8GB MLC FAT32 HGSTドライバによるHDD化
H: 8GB SLC SDHC NTFS MS標準removable
I: VHD 2GB on H-Drive NTFS GPT, VHDは高パフォーマンス&キャッシュのみで選択不可
R: RAMFISK

Hドライブの中に VHD を 2GB 作成し、マウントすると I ドライブとして認識される。
F と G は実態は同じ。ドライバが異なるため、マウント時にドライブレターが変化。


テスト内容 100MB で 3回
      CrystalDiskMark 3.0 および CrystalDiskMarkZ 3.0 で比較
      ディクスのポリシーでは
      「取り外しポリシー」で「クイック削除」と「高パフォーマンス」で比較
      なお、VHD では「取り外しポリシー」と「書き込みキャッシュポリシー」は、
        「高パフォーマンス」&「キャッシュ有効」のみで選択不可

USBpropaty VHDpropaty

まず基準となるSSD, HDD および RAMDISK の値から

SSD
-----------------------------------------------------------------------
           Sequential Read :    30.918 MB/s
          Sequential Write :    22.509 MB/s
         Random Read 512KB :    30.645 MB/s
        Random Write 512KB :     9.360 MB/s
    Random Read 4KB (QD=1) :     8.261 MB/s [  2016.9 IOPS]
   Random Write 4KB (QD=1) :     0.109 MB/s [    26.6 IOPS]
   Random Read 4KB (QD=32) :    12.752 MB/s [  3113.2 IOPS]
  Random Write 4KB (QD=32) :     0.102 MB/s [    24.8 IOPS]

  Test : 100 MB [D: 91.2% (3454.7/3788.8 MB)] (x5)
    OS : Windows 7 Ultimate Edition [6.1 Build 7600] (x86)

ここでOSでの快適さに重要なのは、RW512KBとRR4KB, RW4KB の値。
いまどきの SDHC や USBmemory は、 SR や SW の値は 10MB を超えていて、
DATA用だとこの値が重要だが、 OS 用で重要なのは小さいサイズの RR, RW 性能。

class10 や class6 という値は SW の値なので、OS 用には当てにならない。
SLCの場合、RW4KB の値が 0.100 MB/s 前後なので、これが目安になる。
#なお、一部のUSBメモリーは特別なコントローラーを内蔵しているので、
#このような物の場合は TestSize を 2000MB にして測定する必要がある。


起動用 USB-HDD 20GB 2.5inch 5,400rpm VHDブート OSドライブ
-----------------------------------------------------------------------
           Sequential Read :    27.810 MB/s
          Sequential Write :    25.432 MB/s
         Random Read 512KB :    17.610 MB/s
        Random Write 512KB :    16.913 MB/s
    Random Read 4KB (QD=1) :     0.401 MB/s [    97.8 IOPS]
   Random Write 4KB (QD=1) :     0.779 MB/s [   190.1 IOPS]
   Random Read 4KB (QD=32) :     0.536 MB/s [   130.9 IOPS]
  Random Write 4KB (QD=32) :     0.791 MB/s [   193.0 IOPS]

  Test : 100 MB [C: 89.2% (6422.8/7201.0 MB)] (x5)
    OS : Windows 7  [6.1 Build 7600] (x86)

USB接続なので、最高速度は 30MB/s に抑えられる。これでも結構使えるのは、
OS用にはランダムアクセスの値が重要なため。SSDに比べてRR4Kの値が遅いのが HDD の特徴。


RAMDISK
RAMDISK-ERAM-FAT32 RAMDISK-ERAM-FAT32-Z
RAMDISKではシステムキャッシュが効くと、 SR, SW の値が悪くなっている。
一方、ランダムアクセスの値は良くなっている。
どちらにしても SSD の比ではないスピード。


では次にOS用のSDHC 8GB SLC を
「クイック削除」設定で、SDHCとその中のVHDを比較

H: 8GB SLC SDHC NTFS MS標準removable 「クイック削除」
SLC-SDHC-Quick SLC-SDHC-Quick-Z

I: VHD 2GB on H-Drive NTFS GPT Hドライブは「クイック削除」
SLC-SDHCvhd-Quick SLC-SDHCvhd-Quick-Z

取り外しポリシーが「クイック削除」でもシステムキャッシュが効く。
FAT32のときは効かないのだが、NTFSではキャッシュが効いているのがわかる。
また、小さいサイズではVHDの方がパフォーマンスが良い。
VHDはパフォーマンスが落ちるというのがあるが、EeePCにてSDHCを使う分には
VHDでよさそうだ。
VHDでは「書き込みキャッシュポリシー」が「キャッシュ有効」になっていて、
これが効いているのだろう。

---

今度はOS用のSDHC 8GB SLC を
「高パフォーマンス」設定で、SDHCとその中のVHDを比較

H: 8GB SLC SDHC NTFS MS標準removable 「高パフォーマンス」
SLC-SDHC-High SLC-SDHC-High-Z

I: VHD 2GB on H-Drive NTFS GPT Hドライブは「高パフォーマンス」
SLC-SDHCvhd-High SLC-SDHCvhd-High-Z

「取り外しポリシー」を「高パフォーマンス」したところで
CDM3.0 では「クイック削除」時とほとんど変化が無い。

名称は「高パフォーマンス」となっているが、実態は


リムーバブル ストレージ デバイス上のファイルに対する変更が蓄積されて
一括書き込みされる(WHDCより引用)


ということなので、CDM3.0 では途中で蓄積なんてさせないので変化が無いのは当然である。

一方、CDMZ3.0 でも、「クイック削除」時とほとんど変わらない。
もともと「クイック削除」でもキャッシュが効いているので、
「高パフォーマンス」にしたところで変わらないのである。

VHDについても同様で、傾向も「クイック削除」のときと同じである。


結論:
    NTFSではシステムキャッシュが効く。
    「高パフォーマンス」設定でも「クイック削除」設定でもキャッシュが効くため、
     パフォーマンスに変化は無いので、デフォの「クイック削除」のままでかまわない。
    OSは VHD ブートの方がパフォーマンスが良い。
    「クイック削除」の設定でもキャッシュが効いてしまうので、取り外し時には
    気をつけなければならない。
    
    たまに、「USBメモリでNTFSは鬼門」、「USBメモリをNTFSで使うとデータが壊れる」
    といわれる原因はたぶんコレ。
    自分では「クイック削除」にしてあるのですぐに抜いても大丈夫と思っていても、
    実際はキャッシュが働いていて、書き込みが終わっていないのである。


というわけで、「クイック削除」設定でSDHCからVHDブートした場合のデータ。
ブラウザなどいろいろ起動した状態で測定。プチフリ無し。

OS Boot
OS-SLC-SDHCvhd-Quick OS-SLC-SDHCvhd-Quick-Z

---

続いてデータドライブと HGST Hitachi Microdrive filter Driver の効果を計測する

DATAドライブには汎用性を考慮し FAT32 で使っているので、これを測定し計測する。
* EeePC のリカバリー時のOS は Xp-HOME sp2 *
すでに使っている物なので、XpのOSイメージなどデータがいっぱい入っているのはご愛嬌


まずDATA用のUSBmemory 8GB MLC を「クイック削除」設定で測定

F: 8GB MLC FAT32 MS標準ドライバ removableデバイス認識 「クイック削除」
MLC-FAT32-MS-Quick MLC-FAT32-MS-Quick-Z

FAT32では「クイック削除」設定だとwrite時にキャッシュが効かない。
read時はキャッシュは効く。


次に「高パフォーマンス」設定に変えて測定

F: 8GB MLC FAT32 MS標準ドライバ removableデバイス認識 「高パフォーマンス」
MLC-FAT32-MS-High MLC-FAT32-MS-High-Z

ほとんど変わっていないように見えるが、SWは少しだけ、RW512KB は結構違う。

再掲するが、「高パフォーマンス」設定とは、

リムーバブル ストレージ デバイス上のファイルに対する変更が蓄積されて
一括書き込みされる

というわけで、実際にtxtファイルをUSBメモリに書き込んでみると、
USBメモリのランプが一瞬点滅したあとすぐに書き込み処理は開放され、
その5秒後くらいにランプが再度点滅し、その瞬間「カクッ」とひっかかりを
感じる。よって動作自体は正常に「蓄積後一括書き込み」をしている模様。

こちらも再掲するが、CDM3.0は、

CreateFile 時に FILE_FLAG_NO_BUFFERING のフラグを設定している
FlushFileBuffers でバッファをフラッシュして、CloseHandle で閉じている

実はFlushFileBuffersをすると蓄積された変更が即座に書き込まれるので、
CDM3.0を使って遅延書き込みによる効果の計測をするのは難しいのである。
#ここの部分にも手を加えて改造してしまうと、根本的なところでCDM3.0とは
#変わってしまい、比較にならなくなってしまう。
#これでは冒頭の主旨に反するので、他にうまい方法がないものかと思案中である。



では今度はデバイスマネージャーにて HGST Hitachi Microdrive filter Driver
を適用し、「クイック削除」設定で測定

G: 8GB MLC FAT32 HGSTドライバによるHDD化 「クイック削除」
MLC-FAT32-HGST-Quick MLC-FAT32-HGST-Quick-Z

ドライバの違いによるパフォーマンスに変化は無い。
HGST ドライバでも write 時にキャッシュは効いていないので、
いわゆる窓辺ななみの「抜いても大丈夫だよ!」か


今度は、「高パフォーマンス」設定で測定

G: 8GB MLC FAT32 HGSTドライバによるHDD化 「高パフォーマンス」
MLC-FAT32-HGST-High MLC-FAT32-HGST-High-Z

Read, Write 共にキャッシュが効いている。

実際、使ってみると劇的に効果がある。
5秒後の引っかかりも無く、MLCであることを感じさせない。
効果絶大である。
こうして数値としてみてみれば納得である。


結論:
    データドライブ用USBメモリに使う FAT32 では
    HGST のドライバと「高パフォーマンス」設定でシステムキャッシュが効く。
    HGST ドライバの場合でも「クイック削除」では write 時のキャッシュは効かない。

キャッシュの効くアクセス
- MS標準ドライバ HGSTドライバ
「クイック削除」 read read
「高パフォーマンス」 read,(write) read,write

未確認事項:
    いろいろ試したところ、起動ドライブに HGST ドライバを適用し
    「高パフォーマンス」設定した場合、OSシャットダウン時のファイルの
    フラッシュ動作の信頼性に難があるようである。
    ファイルが高確率で壊れるのである。
    OSシャットダウン時はキャッシュ内のデータをフラッシュしているのだけれど、
    勝手な推測だが
    「キャッシュをフラッシュしたつもりがキャッシュにフラッシュしていた」
    という挙動になっているような気がする。
    データドライブの場合も、OSシャットダウン時にログを書き込むような使い方は
    危険な気がする。


■最後に■
こんなソフトが他に無いわけではないんだけど、
基本的にはHDDのベンチマークソフトはHDDを測定するものであり、
またキャッシュとは実態はメモリのことで、

メモリの計測だったらメモリ測定用のベンチが別にそれ専用にある

ため、それで計測すればよいということです。
でもPCを使っていればキャッシュの効果は体感でき、そしてそれの効果を
測定するベンチというのは、

HDD のキャッシュの効果の計測なら HDD のベンチが HDD のときと同じ仕組みで
メモリキャッシュの有効無効を切り替えて測定する


のが比較上、好ましいと思っていて、そこで標準の地位にあるCrystalDiskMarkを元に
いたしました。-- ゆかた