1

継続的に実行され、無人のコンソール アプリであるべき問題があります。コール スタックの奥深くにある多種多様なメソッドからアプリが頻繁に終了するのを見ていSystem.OutOfMemoryExceptionますSystem.String.ToCharArray()。呼び出しのスタック内の呼び出し、およびその他のありそうもない場所。System.String.CtorCharArrayStartLength()System.Xml.XmlTextReaderImpl.InitTextReaderInput()System.String.Concat()MongoCollection.Save()

価値のあることとして、並列タスクを使用していますが、これは本質的にサーバー上で実行されている唯一のアプリであり、アプリの合計スレッド数が 60 を超えることはありません。これらのケースのいくつかでは、他の例外の理由を知っています。スローされますが、OutOfMemoryException はこれらのコンテキストでは意味がなく、問題を引き起こします。

  • TaskManager と Perfmon のログによると、これが発生したとき、システムには 8 GB の空きメモリのうち少なくとも65% がありました。
  • 例外ハンドラーは例外を起動してログに記録することがありますが、アプリのクラッシュを防ぐことはできません。
  • ユーザーの操作なしでは、この例外から続行することはできません (システム全体で望ましくない Windows エラー報告を抑制したり、アプリをサービスとして実行したりしない限り、これは可能ですが、ユースケースには最適ではありません)。

したがって、上記の回避策は認識していますが、適切な継続ロジックを使用できるように、予期しない OOM 例外の説明 (理想的にはコードベースのハンドラー) が本当に必要です。何か案は？

4

3 に答える 3

2

3GB 未満のメモリを使用しているときにその例外が発生する場合は、32 ビット アプリを実行していることを示唆しています。64 ビット アプリとしてビルドすると、使用可能なメモリを最大限に使用できます (8 GB 近く)。

そもそもなぜ失敗するのか...どのくらいのデータを扱っていますか? それほど大きくない場合は、必要以上に長く保持されているデータへの参照 (つまり、メモリ リーク) を探し、適切な GC を妨げていますか?

于 2012-07-07T01:04:14.560 に答える
2

アプリケーションをプロファイリングする必要がありますが、これらの例外の最も一般的な理由は、過剰な文字列の作成です。また、過剰なシリアライゼーションは、これと過剰な Xslt 変換を引き起こす可能性があります。

于 2012-07-07T01:07:13.503 に答える
1

85000バイト以上のオブジェクトがたくさんありますか？このようなオブジェクトはすべて、圧縮されていないラージオブジェクトヒープに移動します。つまり、Small Object Heapとは異なり、GCはオブジェクトを移動してメモリホールを埋めることはありません。これにより、断片化が発生する可能性があります。これは、寿命の長いアプリケーションの潜在的な問題です。

.NET 4の時点でもこれは当てはまりますが、.NET4.5でいくつかの改善が行われたようです。

手っ取り早い回避策は、アプリケーションが「x64」または「任意のCPU」として構築することにより、使用可能なすべてのメモリを使用できるようにすることですが、実際の解決策は、大きなオブジェクトの繰り返しの割り当て/割り当て解除サイクルを最小限に抑えることです（つまり、オブジェクトプーリングを使用するか、可能であれば大きなオブジェクトを完全に避けてください）。

また、これを見たいと思うかもしれません。

于 2012-07-07T09:36:26.703 に答える