5

現在、ディスクの読み取りと書き込みを行う MFC アプリケーションに取り組んでいます。このアプリケーションは、驚くほど高速に実行される場合もあれば、非常に遅い場合もあります。ディスクアクセスが関係しているためだと推測しているので、プロファイリングしたいと思います。この点に関して、次のような質問があります。

(1) .現在、アプリケーションのプロファイリングにAQTimeプロファイラーを使用しています。これを使用してディスクアクセスのプロファイリングを試みた人はいますか? または、使用できる他のツールはありますか?

(2)。確認すべき最も重要なディスク パラメータは何ですか?

(3)。複数のスレッドがディスクからデータを読み書きしようとしている場合、パフォーマンスに影響しますか? つまり、ディスクへのシングル スレッド アクセスを使用した方がよいのでしょうか?

4

3 に答える 3

2

これには、 Windows Performance Toolkitを使用できます。ディスク I/O イベントのトレース プロバイダーを有効にして、それぞれの I/O 時間とディスク サービス時間を確認できます。ただし、少し学習曲線があります。これにより、どのファイル I/O が実際にディスクへの実際のアクセスをもたらし、キャッシュ マネージャーによって処理されないかを判断することもできます。

最も重要なパラメータは、ディスク サービス時間とキューの長さです。ディスク サービス時間は、ディスクが要求を処理するのに実際にかかった時間です。キューの長さは、ディスク リクエストが他のリクエストの後にバックアップされているかどうかを示します。

読み取りと書き込みを伴う多くのスレッドの場合 - 多くのディスクは、バックグラウンド書き込みによる読み取りに直面すると、パフォーマンスが低下します。さまざまなスレッドがディスク上のランダムな場所に対して大量のディスク I/O を実行している場合、特定の要求が枯渇する可能性があります。

于 2009-04-21T18:42:57.483 に答える
1

私がすることは、すべてのスレッドを同時に一時停止してその状態を調べることができない場合は、そのうちの 1 つに焦点を合わせて一時停止することです。これはあまり知られていませんが効果的なテクニックです。

可能性に比べて非常に遅いため、待機しているものはおそらく 99% の時間待機しているため、一時停止すると表示されます。それが 1 回の大きな待ち時間であろうと、無数の小さな待ち時間であろうと、それは真実です。コールスタック全体を見てください。原因はスタックのどこかにある可能性があります。

よくわからない場合は、2 ~ 3 回一時停止してください。原因はすべてのスタック サンプルにあります。

于 2009-04-23T00:01:55.867 に答える
1

(2)を支援するには:

  1. ディスクへの書き込みをバッチ処理して、多数の小さな書き込み呼び出しを避けるようにしてください。バッファのフラッシュが完了したら、commit を呼び出します。コミット (別名 fsync) はコストのかかる操作であるため、小規模な書き込みが多数ある場合はさらにコストが高くなります。
  2. Windows ファイル ハンドルでは、書き込み速度を上げるためにFILE FLAG WRITE THROUGHを試すことができます。おそらく、このフラグを使用してハンドルで commit を呼び出す必要はありません。
  3. ディスクに書き込むデータが読み取りによってもアクセスされる場合は、最初にインメモリ構造に書き込み、別のスレッドでその構造から読み取り、ディスクに書き込むことを検討してください。これにより、書き込んだばかりのディスクからデータを読み取るための呼び出しを回避できます。

うまくいけば、これは役に立ちます....

于 2009-04-21T18:50:58.070 に答える