NTFSのパフォーマンスが悪い


21

NTFSのパフォーマンスが、たとえばLinux / ext3に比べてそれほどひどいのはなぜですか?ほとんどの場合、Subversionから(大規模な)ソースツリーをチェックアウトするときに表示されます。NTFSではチェックアウトに約10〜15分かかりますが、Linux(ほぼ同一のハードウェア)で対応するチェックアウトは1桁(1〜1.5分)速くなります。

たぶん、これは多くの小さなファイルの処理に固有のものであり、大きなファイルに関してはNTFSの方が優れていますが、なぜそうすべきなのでしょうか?小さなファイルのNTFSパフォーマンスを改善することは、Windowsの一般的なパフォーマンスにとって非常に有益ではないでしょうか?

編集:これは「ext3と比較したNTFSの吸い込み」という炎症性の質問ではありません。NTFSが特定のケースでパフォーマンスが悪い理由に本当に興味があります。それは単に悪い設計ですか(疑わしい)、または他の問題がありますか?


4
おそらく、NTFSがext3と比較して吸う理由を尋ねるのではなく、多数の小さなファイルを処理するとき、NTFSのパフォーマンスを改善する方法を尋ねるように言い換えることができますか?
ChrisInEdmonton 2009

@Chrisに同意しますが、この質問は無意味なものです。
サーシャチェディゴフ2009

4
まあ、NTFSのパフォーマンスが悪い理由に本当に興味があります。答えが「Xを実行して高速化する」なら、それは素晴らしいことですが、私は問題を理解することに決心します。
JesperE 09

ああ、大丈夫、あなたを誤解して申し訳ありません。
サーシャチェディゴフ09

2
ところで、WindowsマシンでSVNを使用している場合、そのマシンにはリアルタイム保護が有効なウイルススキャナーがありましたか?それは悪いかもしれません。
dlamblin 2009

回答:


35

NTFSには、マスターファイルテーブルと呼ばれるものがあります。あなたがそれについて読むとき、それは本当にクールに聞こえます。

ext3のディスク使用率は最大で約95%であることがわかりますが、MFTの存在は、NTFSがディスクの90%以上を使用することを望んでいないことを意味します。しかし、それはあなたの問題ではなく、あなたの問題は多くの小さなファイルに対する多くの操作にあると仮定します。

ここでの違いの1つは、小さなファイルを作成するとどうなるかです。ファイルがブロックサイズよりも小さい場合、ファイル自体のブロックに書き込まれるのではなく、MFTに保存されます。これは、ファイルが作成時の状態のままである場合に便利です。ただし、実際には、svnがファイルに触れて作成し、そのファイルに追加、削除、またはそれを自分のブロックに移動するのに十分でないだけで変更すると、操作がかなり遅くなることを意味します。また、多くの小さなファイルを読むだけでは、それらがすべて存在するMFTに、ブロックごとに複数のストレスがかかります。なぜこれを行うのでしょうか?断片化を予防的に回避し、より多くのブロックをより効果的に使用することであり、一般的には良いことです。

対照的に、ext2および3では、すべてのファイルのファイルブロックは、ディレクトリメタデータがあるディレクトリの隣に格納されます(可能であれば、ディスクが断片化されておらず、空き容量が約20%の場合)。これは、svnがディレクトリを開いているときに、多くのブロックがドライブ上のその16MBキャッシュに基本的に無料でキャッシュされ、その後再びカーネルのキャッシュにキャッシュされることを意味します。これらのファイルには、.svnファイルと最後の更新のリビジョンファイルが含まれる場合があります。svnが次に見ているファイルの一部である可能性が高いため、これは便利です。NTFSはこれを行うことができませんが、MFTの大部分はシステムにキャッシュする必要がありますが、次に必要な部分ではない可能性があります。


2
これは小さなファイルが存在する場所であることは正しいですが、なぜこれがMFTにストレスをかけるべきかはわかりません。これらのファイルのいずれかをプルするときに、これらのファイルの多くをキャッシュにプルすることが保証されているので、これらのファイルを読むのがはるかに簡単になりませんか?
ChrisInEdmonton 2009

1
@ChrisInEdmonton隣接するスペースが利用可能なブロックに触れないため、MFTのキャッシュ部分を無効にすることになり、MFTの更新がそれを強調します。紙の上では、MFTが小さなファイルを処理する非常に高速な方法であることを認めます。実際には耐えられません。
dlamblin 09

6

さて、あなたの特定の問題は

  1. Subversion自体はUNIXの世界に由来するため、Windowsバージョンは同様のパフォーマンス特性を想定しています。
  2. NTFSのパフォーマンスは、膨大な数の小さなファイルでは本当に優れていません。

表示されているのは、特定のオペレーティングシステム用に設計された何かのアーティファクトであり、そのオペレーティングシステムのパフォーマンスを想定しています。これは、通常、他のシステムに移されるとひどく壊れます。他の例としては、フォークとスレッドがあります。UNIXライクでは、何かをパラレライズする従来の方法は、別のプロセスを生成することです。Windowsでは、プロセスの開始に少なくとも5倍の時間がかかりますが、これは非常に悪い考えです。

一般に、特定のOSのアーティファクトを、まったく異なるアーキテクチャを持つ他のOSに付与することはできません。また、NTFSには、ジャーナリングやACLなど、その時点で広く使用されていたUNIXファイルシステムにはなかった多くのファイルシステム機能があることを忘れないでください。これらのことにはコストがかかります。


いつか、私は多くの空き時間があるとき、トランザクションサポート(「何百万もの小さなファイルの問題」に対処する必要があります)や代替データなど、NTFSの機能を活用するSVNファイルシステムモジュールを書くことを計画していましたストリーム(個別の.svnディレクトリの必要性を排除する必要があります)。持っているのはいいことですが、SVN開発者が近い将来にそのようなものを実装するのを回避することはできません。

サイドノート:私が使用している大規模なSVNリポジトリの単一の更新には、約250,000のファイル操作がかかりました。いくつかの小さな声で、これは実際に変更された24個のファイルの多くであることがわかります...


1
しかし、何億もの小さなファイルを扱うときにNTFSのパフォーマンスが悪いのはなぜですか?他のものを得るためにそれを犠牲にする必要がありましたか?
JesperE 09

3

NTFSの仕組みに関するMicrosoftの情報を以下に示します。探しているものはやり過ぎかもしれませんが、それを調べることで、NTFSに問題があるシナリオを明らかにすることができます。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.