検証 ディスク・デフラグメント完全マスター 7.検証:フラグメントはシステム・パフォーマンスにどれだけ影響を及ぼすのか?(1)デジタルアドバンテージ2000/10/21 |
|
|
これまで、Windows 2000に標準添付されるデフラグ ツール、およびフル機能版のDiskeeperについて、これらを使ったデフラグメント処理の実際や、さまざまな機能について説明してきた。しかし機能性は分かったが、そもそもフラグメントが発生したとき、ディスク入出力のパフォーマンスはどれほど低下するのだろうか? フラグメント発生のメカニズムは分かったが、実際にフラグメントはどれほど発生するものなのか?
こうした基本的な疑問に答えるために、本稿の最後は、いくつかのベンチマーク・テストで締めくくることにしよう。なお今回のテストは、次のような環境で行っている。
CPU | Celeron-500MHz |
メモリ | 256Mbytes |
テスト用ハードディスク | 4.3Gbytes IDEハードディスク *1 |
OS | Windows 2000 Professional(+SP1) |
テスト・マシンのスペック | |
*1:4.3Gbytesのうち、先頭1Gbytesのパーティションを使用。 |
テスト1:フラグメント状況とファイル・コピーの実行速度
まず最初の実験は、フラグメントがディスク入出力の性能に及ぼす影響を調べるために、意図的にフラグメントを起こしたボリュームを作り、ここにファイルをコピーして時間を計測した。フラグメントを起こしていない状態での実行時間と比較すれば、フラグメントによって、ファイル・コピーの性能がどれほど低下しているかが分かる。
■テスト環境の作成
フラグメントを人工的に発生されるために、まず1Gbytesのパーティションを「圧縮」属性を付けてフォーマットし、ここに総計で約800Mbytes分の複数のファイルをコピーする。ここでコピーするファイルは、まちまちのサイズをしており、数Kbytesという小さなものから、数Mbytesという大きなファイルも含まれている。コピー先のボリュームは圧縮属性を有効にしているので、これらのファイルは圧縮されながら連続したクラスタに順次コピーされるはずだ。そしてコピーが完了したら、ボリュームの圧縮属性を解除する。これにより、圧縮コピーされていたファイルは元のサイズに伸長されるが、空き領域は200Mbytesしかないため、伸長されたファイルは激しくフラグメントするはずだ。
この処理を行った後で、Diskeeperでボリュームの分析を行うと次のようになった。
人工的にフラグメントを発生させたボリュームの状態 |
NTFSのファイル圧縮機能を逆手にとって、人工的にフラグメントを発生させた直後のボリュームの状態。ボリューム全体がフラグメント(赤色の部分)を起こしていることが分かる。 |
画面から分かるとおり、ボリューム全体が断片化したファイルを示す赤色に染まっている。このとき分析結果を確認したところ「ファイルあたりの平均の断片は3.02」であった。つまり、1つのファイルあたり、平均して約3つに断片化していることになる。
■過度のフラグメントを発生させた直後にファイルをコピー
この状態で、別のドライブに用意した100Mbytesのファイル(単一のファイル)を、このボリュームにコピーして、コピー完了までの時間を計測する(グラフ中の「過度のフラグメント」)。なお、ファイルのコピー元である別ドライブは、フォーマット直後の状態(クラスタが連続した状態)でテスト用のファイルだけをコピーした。またディスクのアクセス性能が結果に影響を及ぼさないように、十分高速なハードディスクを用いている。
■デフラグメントを1回実行してファイルをコピー
次に、Diskeeperを使用して、フラグメントを発生させたテスト用ボリュームに対してデフラグメントを1回実行し、同様に100Mbytesのファイルをコピーして実行時間を計測する(グラフ中の「デフラグ1回実行」)。テストでは、フラグメントを発生させた直後のボリューム・イメージをDrive Image(ディスク・イメージ・バックアップ・ツール)を使ってバックアップしておき、フォーマットした直後のディスクにこのイメージを書き戻して、デフラグメント処理を実行している。
デフラグメントを1回実行した直後のボリュームの状態は次のようになった。ファイルあたりの平均の断片は1.97となった。
デフラグメント処理を1回実行した直後のボリュームの状態 |
意図的に過度にフラグメントを発生させた状態から、Diskeeperを利用してデフラグメントを1回実行したところ。まだ赤い部分(フラグメントを起こしている部分)がかなり残っているが、青い部分(連続している部分)も大幅に増加した。ファイルあたりの平均の断片は1.97となった。 |
■デフラグメントを2回実行してファイルをコピー
繰り返しデフラグメントを実行した場合の効果について調査するため、再度デフラグメントを実行し、同じテストを行った。デフラグメント処理を2回行った直後のボリュームの状態は次のとおり。
デフラグメント処理を2回実行した直後のボリュームの状態 |
デフラグメントを1回行った状態から、さらにもう1度デフラグメントを実行したところ。ひと目で分かるように、今度はほとんどの領域が青色(連続領域)になった。ファイルあたりの平均の断片は1.02と、ほとんどフラグメントがない状態になった。 |
■テスト結果
以上の状態を順次作り出し、別ドライブから100Mbytesのファイルをボリュームにコピーし、コピーを完了するまでの時間を計測した結果が次のグラフである。なお比較のために、テストと同一ドライブを使用して、フォーマット直後の状態でファイルをコピーした場合の時間を「フラグメントなし」に示している。
フラグメントを発生させたボリュームへのファイル・コピー |
人工的に発生させたとはいえ、過度にフラグメントを発生させた直後の状態と、フォーマット直後の状態(「フラグメントなし」)を比較すると、その差は前者は30%以上も性能が低下していることになる。しかしデフラグメントを1回実行すれば、その差は8%、2回実行すれば6%と、大幅にアクセス性能が回復している。 |
グラフから分かるとおり、人工的に過度に発生させたとはいえ、フラグメントを発生させた直後の状態(20.8sec)では、フォーマット直後の状態(15.8sec)から比べて、約30%以上も性能が低下していることが分かる。しかしデフラグメントを1回実行すればその差は約8%と大幅に縮まり、さらにもう1回デフラグメントを実行することで、差は6%になっている。
このテストは、意図的に激しいフラグメントを発生させているということ、ファイルのコピーにだけに注目していることから、このような差が直接アプリケーションの利用環境に反映されるわけではない。しかし、ディスクのフラグメントを放っておくと、それが無視できないオーバーヘッドになる可能性はありそうだ。
検証 |
- Azure Web Appsの中を「コンソール」や「シェル」でのぞいてみる (2017/7/27)
AzureのWeb Appsはどのような仕組みで動いているのか、オンプレミスのWindows OSと何が違うのか、などをちょっと探訪してみよう - Azure Storage ExplorerでStorageを手軽に操作する (2017/7/24)
エクスプローラのような感覚でAzure Storageにアクセスできる無償ツール「Azure Storage Explorer」。いざというときに使えるよう、事前にセットアップしておこう - Win 10でキーボード配列が誤認識された場合の対処 (2017/7/21)
キーボード配列が異なる言語に誤認識された場合の対処方法を紹介。英語キーボードが日本語配列として認識された場合などは、正しいキー配列に設定し直そう - Azure Web AppsでWordPressをインストールしてみる (2017/7/20)
これまでのIaaSに続き、Azureの大きな特徴といえるPaaSサービス、Azure App Serviceを試してみた! まずはWordPressをインストールしてみる
|
|