6

問題は単純です。いくつかのxmlファイルでETLを実行するプロセスがあります。非常に大きなxmlファイルを取得し始め、OutOfMemoryExceptionsを取得し始めました。

プロセスの修正は比較的簡単です。ただし、NUnitスイートの単体テストを実行して、プロセスが非常に大きなファイルを引き続き処理できることを確認したいと思います。ただし、実際に開発ワークステーションのメモリが不足すると、マシンの速度が低下し、時間がかかります。巨大なテストファイルをバージョン管理に保存することも悪い考えです。プロセス、スレッド、またはアプリドメインを人為的に制限して、固定量のRAM、たとえば128メガバイトのみを使用することができれば、ワークステーションをひざまずかせない小さな単体テストを作成できます。

助言がありますか？P / InvokeできるアンマネージAPIはありますか？

4

4 に答える 4

2

メモリ割り当てにモックフレームワークを使用してOutOfMemoryException、テストの1つとしてスローさせることはできませんか？

そうは言っても、本当にメモリが不足している場合、アプリケーションが安全に実行できることはあまりありませんが、少なくとも正常に失敗することができれば、ユーザーは感謝するでしょう。

例： 前の仕事で、工場の3Dモデルをリアルタイムで表示していたケースがありました。モデルが非常に大きくなったため、テクスチャをロードしようとすると、メモリ障害が発生しました。コードの残りの部分がテクスチャ情報があるべきだと考えていたとしても、コードがnullポインターに対処できるようにすることで、アプリケーションを存続させてレンダリングすることができました。

于 2009-05-07T18:41:58.850 に答える
1

嘲笑するのが一番です。実際に OOM を発生させることは、定義上、単体テストではありません。メモリを扱うときは、負荷テストを扱っています。この電子メールの下部にあるリンクを読むと、実際の OOM は、最良の場合でも再現およびデバッグするのが非常に困難であることがわかります。人為的な OOM 例外は例外の真の原因ではないため、テスト用のモックよりも興味深いものではありません。

検証用のモックを使用した単体テストに固執します。それでも OOM が発生する場合は、サーバーにより多くのメモリを投入し、プロセスのリサイクル/再起動をより頻繁に行います。

最後にそれらと戦ったときに収集した OutMemoryExceptions に関する興味深い読み物を次に示します。概要: OOM は、要求した量をシステムが割り当てることができない場合に発生します。これは、メモリが不足しているという意味ではありません。

于 2009-05-07T20:06:43.703 に答える
0

プロセスでメモリ不足の例外が発生するのは非常に簡単です。

大きなオブジェクト ヒープに収まらないほど小さなブロックにメモリを割り当てるループを作成するだけで (ただし、例外の原因となるブロックが多すぎない)、小さなファイルを開こうとすることができます。十分な連続メモリを割り当てることができず、巨大なファイルを必要とせずにファイルを開くと、OOM 例外が発生します。このようなもの...

List<byte[]> items = new List<byte[]>();
for (int i = 0; i < 10000; i++)
{
     byte[] c = new byte[160000];
     items.Add(c);
}

byte[] next = new byte[1000000000];

上記のコードをそのまま実行すると、最終行で OOM 例外が発生します。ただし、最初にループをコメントアウトすると、エラーなしで実行されます。ファイルを開くたびに失敗するようにするには、おそらくループを少し調整する必要がありますが、それは可能です。テストでファイルを開く呼び出しの前にループを実行するだけで、大量のメモリを使い果たし、開くことができなくなります。

また、オプションである場合は、/3GB スイッチの設定を検討することもできます。これは必ずしも正しい答えではなく、それに伴う欠点もありますが、仮想メモリ分割が 2GB/2GB から 1GB/3GB に変更され、プロセスがより多くの仮想アドレス空間にアクセスできるようになります。これにより、開くことができるファイルのサイズに少し余裕ができます。繰り返しますが、解決策としてこれを行う前に、これを行うことの欠点について読んで、状況に役立つ場合はそれが価値があることを確認する必要があります.

サーバーで有効にする方法は次のとおりです

于 2009-05-07T23:10:59.673 に答える
0

あなたがここで何を得ているのかよくわかりません。どういうわけか、メモリの大きなチャンクを割り当てることができない人為的に小さな「テスト環境」を作成したため、小さなファイルに OutOfMemoryExceptions がスローされたとします。あなたは何を得ましたか？単体テストは、実際のシステムでより大きなファイルを処理できるかどうかをテストすることになっていましたよね?

重要なことは、おそらく、ファイルを実行するシステムが何であれ、「必要な大きさの」ファイルを処理できることです。そのシステムでそのファイルを試す以外に、単体テストを行う実際の方法はありません。

(より小さく、あまり重要でないことは、 s を適切に処理するかどうかかもしれませんがOutOfMemoryException、それをテストするために実際にメモリ不足になる必要はありません。メソッドが時々例外をスローし、それが正しいことを行うことを観察するだけです.)

于 2009-05-07T18:30:50.330 に答える