4

基本的にMSMQからメッセージを読み取り、.NETSqlClientを介してSQLサーバーと通信することでメッセージを処理する64ビットの.NETコンソールアプリケーションがあります。ほとんどの場合は正常に機能しますが、場合によっては、SqlCommandパラメーター配列の作成などの最も単純な操作でさえ、すべてが異常に遅く実行される状態になります。最悪のシナリオでは、アプリケーションは一度に30分間何も行わず（ログに何も書き込まれず、冗長モードがオンの場合はかなりおしゃべりになります）、遅延の原因を示すことなく、再び書き込みを開始します。これは、当社の製品の使いやすさに深刻な影響を及ぼします。

私は過去数時間、すべてのパフォーマンスカウンターなどを調べてきましたが、すべてが過剰なページ読み取りを示しています。これにより、ディスクI / Oが最大になり、プロセスが常にpagefile.sysなどから大量に読み取られていることがわかります。など。しかし、アプリケーションの合計メモリ使用量が使用可能なRAMをはるかに下回っているため、理由はわかりません。ワーキングセットは60M、合計コミットサイズは300M（高く、ピークワーキングセットと一致します。これがなぜであるかはわかりません）。 ）、しかしそれは利用可能なRAMの12ギガと比較してピーナッツであり、他にほとんど使用されていません。

アプリケーションのパフォーマンスの監視などに関するすべてのMSドキュメントを読みましたが、すべてが「アプリケーションにはより多くのメモリが必要」であることを示しています。わかりました...では、どうすればメモリを増やすことができますか？他に何も使用されていません！アプリケーションが何をするかを考えると、とにかくそれほど多くのメモリを必要としないはずであるという別の問題がありますが、それを減らすためにかかる労力は、おそらくハードウェアを増やす価値がありません。

もう1つ注意すべき点は、同じアプリケーションの2番目のインスタンスを起動すると、正常に実行されているように見えることです。したがって、これは明らかにシステム全体の問題ではありません。

私はここにstackoverflowに関するいくつかの同様の投稿を見ましたが、特に役立つ答えはまだありません...以前のポスターよりも幸運を願っています。

4

2 に答える 2

0

私も同じ問題を抱えていました。私の経験では、「常にオン」の激しいアプリケーションがある場合。コンソール アプリではなく、Windows サービスに配置する必要があります。

そうは言っても、ガベージ コレクションに問題がある可能性があります。

これを構成ファイルに追加します。

<runtime>
  <gcServer enabled="True"/>
</runtime>

構成ノードの下に配置する必要があります。

私の経験では、これによりアプリの PageFault が少なくなり、ワーキング セットが大きくなります。

銀の弾丸はありません。コードがなければ、コードがメモリ リークを起こしているかどうかを知る方法はありません。これは、過度のページングの別の原因になる可能性があります。

于 2016-10-20T12:29:02.743 に答える
0

タスク マネージャーのページ フォールトは、ディスク上のページ ファイルへのヒットを意味し、既定では、インストールした RAM の量の 1.5 倍になります。必ずしも悪いわけではありません。データがどこにあるかを示しているだけです。ページング ファイルをオフにして、この数値が 0 のままであることを確認できます。

SQL Server や MSMQ など、依存している製品のパフォーマンスとカウンターを確認しましたか? RAM をテストするために memtest86 を試しましたか?

于 2013-04-19T21:44:02.923 に答える