MFTの断片化は、ビジー状態のファイルサーバーで問題になる可能性がありますか？
SAN）からマウントされたWindows Server 2003 SP2 LUN数十万のディレクトリ（合計100GB）の数百万の小さなファイルNTFS、クラスターサイズ4k
バックアップのために最初のファイルクロールを実行している間、またはこのドライブ上のファイルへの通常のユーザーアクセスをアーカイブしている間、大幅に遅くなります。
SANとネットワークの担当者は、最初の調査で異常なアクティビティを示していませんが、より詳細な調査が続けられています。 NTFSまたはWindowsに関する何らかのサーバーレベルの問題が疑われます。
ほとんどすべてのファイルが10k未満であるため、1〜3個のクラスターに収まるため、通常の断片化が問題になるとは思われませんが、MFTの断片化が問題になる可能性があります。バックアップとクリーンアップが時間外でもユーザーの混乱を引き起こすことを考えると、私はWindowsデフラグを使用して断片化を分析することを躊躇し、MFT断片化だけを本当に気にしています。フルディスク分析よりも迅速にそれを理解することはありましたか？
誰かが推奨事項を持っている場合でも、行儀の良いサードパーティのデフラグプログラムは問題外ではありません。私たちの分析でユーザーをさらに邪魔しないことが大きな優先事項です。
NtfsDisableLastAccessUpdateのregキーを挿入することも検討しています。誰かがこれが本当に大きな改善であり、単なる小さな調整ではないことを発見しましたか？
ビジー状態のドライブのファイルロック/アクセス競合を測定するための優れたツールはありますか？ procmonのようなsysinternalsのGUIツールは、もはやそのレベルでは拡張できません。
プレフィックスと同じ5文字のファイルが何万も実行されると、速度が低下することがわかりました。私の考えでは、この場合、NTFS MFT B +ツリーが作成されすぎて、バランスが崩れます。ファイルを新しいディスクに復元しても問題が繰り返されなかったため、ファイルがランダムに作成される場合（これらのプレフィックスファイルの1つである場合とそうでない場合があります）よりも、ファイルがすべて連続している新しい作成で、これが何らかの形で適切にバランスされていると思われます。すでに断片化されたディスク。
名前をランダム化し、将来的に8dot3名を無効にすることも検討する予定です。
そのようなボリュームをバックアップするときは、基盤となるストレージを真剣に実行することになります。ファイルシステムに散在する数百万の小さなファイルの読み取りを開始すると、制限要因は、SANの基盤となるディスクが配信できるランダム読み取りIOPSになります。SAN自体にはまったくストレスがかからない可能性がありますが、読み取り元のボリュームがヒットし、バックアップアクティビティを抑制しない限り、他の処理を同時に実行しようとする他のプロセスは影響を受けます。
確認するのは、そのボリュームのキューの深さです。ボリュームをバックアップするディスクの数よりも大幅に多くピークに達している場合は、IOPSの制限に達しています。 Perfmonがアイデアを提供しますが、それらを取得できる場合は、ストレージアレイ独自の分析から最良のデータが得られます。私はあなたの問題がファイルロックと関係があるのではないかと真剣に疑っています。ストレージ担当者は、ボリュームが切り分けられたRAIDパック内のディスクのIOPSを確認する必要があります。これらのディスクは、それぞれ最大150 IOPに達していると思われます（15kの場合は高く、7.2kの場合は低くなります）。 。そのボリュームをホストしている6ディスクRAID10グループがある場合、それが本当に数百万の10kファイルをバックアップし、それよりはるかに大きいものがほとんどない場合、10Meg /秒よりもはるかに良い速度で最大になります。
NtfsDisableLastAccessUpdateは、あなたの場合に役立ちます-各ファイルアクティビティからIOPSのセットを削除し、特に、各ファイルに関連付けられた2、3の余分な読み取りと書き込みを回避します。あなたが何百万も持っていて、あなたのファイルまたは非常に小さいことが重要な勝利があるはずであることを考えると、それは50％もの勝利になるかもしれません。とはいえ、最も可能性の高い効果は、バックアップが高速化されるが、それでもIOPS制限に達することです。
まだ行っていない場合は、 ディスクパーティションの調整 も検討する必要があります。このような場合（小さな読み取りが多い）、他のIOパターンの場合ほど大きなメリットはありません。RAIDストライプサイズが128kで、平均読み取りは約10kですが、努力する価値があるかもしれません。ボリューム全体をバックアップし、再パーティション化して再フォーマットしてから、データを復元する必要があるため、簡単な作業ではありません。
ディスクデフラグツールを分析モードで実行することが、MFTフラグメントの数を確認する唯一の方法です。
ボリュームが24時間年中無休で使用されている場合は、おそらくユーザーを「邪魔」していることになります。そうでない場合は、「defrag -a -v C：」コマンドをスケジュールして、出力がファイルにリダイレクトされる時間外に実行します。これにより、日曜日の午前4時に実行するために目を覚ましている必要のないコマンド出力が得られます。 >笑顔<
「NtfsDisableLastAccessUpdate」に関する統計情報を提供することはできませんが、最終アクセス時間を保存する必要がない限り、必ず設定します。 （レジストリに設定するのではなく、「fsutil Behavior set disablelastaccess 1」コマンドを使用します。変更を有効にするには、再起動する必要もあります。）
必要がない場合は、8dot3ファイル名の作成を無効にすることも検討してください。これは、特に1つのディレクトリに多数のファイルがある場合に実行してください。 （これをオフにしても、すでに存在する8dot3の名前は削除されません...）
この遅い「初期クロール」の前後の問題のボリュームでの「fsutilfsinfostatistics」の出力を比較すると、何が起こっているかについて何かがわかるかもしれませんが、それは恐ろしい量のメタデータ読み取りが行われていることを示しているだけだと思います。
SANに、ボリュームのコンテンツ全体を同様に構成された新しいLUNに復元するのに十分なスペースがありますか（SANプロパティ（RAIDレベルなど）を本番LUNとして使用しますか？最初から8dot3名の作成が無効になっている、新しく作成されたNTFSファイルシステムと、おそらく異なるサイズのMFTゾーンがどのように動作するかを確認するのは興味深いことです。本番LUN（ステージングLUNの機能が向上した場合は、変更されたファイルを本番LUNからこのステージングLUNにコピーして移行を調整することもそれほど難しくありません。）