ライブラリから多くのデータを復元するアプリケーションがあります。私たちはWindowsサーバー2003を使用しています。プロセスが進行するにつれて、パフォーマンスが低下しています。私は4つの主要なタスク、ファイルの作成、ライブラリからの読み取り、WriteData、ファイルのクローズのためのいくつかのパフォーマンスカウンタを追加しました。私たちは何百万というファイルを復元しています。 私が観察したことは、プロセスが進行するにつれてcreatefile APIのパフォーマンスが低下していることです。その他の操作は一貫しています。CreateFile APIのパフォーマンス低下
何が原因なのですか？
ありがとうございます。すべての回答/提案をありがとうございます。
よろしく、 Bhushanの
おそらくシステムキャッシュを戦って？ドキュメントのキャッシュ動作のセクションをCreateFileに見てください。
ライブラリデータの保存場所とファイルの作成場所に関する情報を提供できますか？
たとえば、すべての出力ファイルを同じディレクトリに作成している場合、衝突のためにより多くのファイル名に対してチェックする必要があるため、CreateFileが減速している可能性があります。
私の精神的なデバッガはあなたがハンドルを漏らしていると言います。あなたはCloseHandle'ingあなたはCreateFile'ingているそれらの呼び出しのすべてですか？
ファイルシステムはNTFSですか？何百万ものファイルが同じディレクトリに置かれていますか？それらは同じような名前を持っていますか？ technet article on NTFS internalsから：
あなたは、ファイル、フォルダ内（30万以上）の数が多い、とファイルが同じ初期文字、ファイルの増加を作成するのに必要な時間と長いファイル名を持っている場合。この増加は、NTFSが短いファイル名を長いファイル名の最初の6文字に基づいているために発生します。ファイルが300,000を超えるフォルダでは、NTFSが長いファイル名に似た8.3の名前をすべて使用した後、短いファイル名が競合します。生成された短いファイル名と既存の短いファイル名との競合が繰り返されると、NTFSは短いファイル名を6回から8回まで再生成します。
あなたは「FSUTIL」コマンドラインユーティリティを使用して、この動作を照会することができます
fsutil behavior query disable8dot3
私は記事を読んだとき、私が考えたもの厥。 –