ASP.NET で高いメモリ レベルが発生したときにチェックする簡単な操作

  • [アーティクル]

この記事では、Microsoft ASP.NET で高いメモリが発生したときにチェックする簡単な操作について説明します。

元の製品バージョン: ASP.NET
元の KB 番号: 893660

この記事では、いくつかの一般的な問題、これらの問題を解決するためのアクション、およびこれらの状況が問題を引き起こす可能性がある理由の簡単な説明から始めます。

ASP.NET サポート音声列

2005 年 4 月のサポート音声列で、誤って間違ったファイルへのリンクが提供されました。 Web サービスのダウンロードにリンクする代わりに、Web サービスから返される XML ファイルにリンクしました。 そのリンクが修正されました。 正しいファイルが添付された記事を確認する場合は、「 XMLHTTP を使用した動的ページの更新」を参照してください。

高メモリと見なされるもの

明らかに、この質問は、特定のアプリケーションのボリュームとアクティビティに依存します。 一般に、高いメモリは、ASP.NET ワーカー プロセス (Aspnet_wp.exe) またはインターネット インフォメーション サービス (IIS) ワーカー プロセス (W3wp.exe) のメモリが一貫して増加しており、快適なレベルに戻っていない場合です。

一般に、既定の 2 GB のユーザー メモリ アドレス空間では、快適なレベルは 600 MB 未満になります。 メモリ レベルがその快適なレベルより高くなると、実行する必要があるよりも少なくなります。 この動作は、システム上で実行されている他のアプリケーションに影響する可能性があります。

重要なのは、一部のアプリケーションが他のアプリケーションよりも多くのメモリを必要とすることを理解することです。 これらの制限を超えている場合は、メモリを追加するか、Web ファームに別のサーバーを追加できます (または Web ファームを検討してください)。 このような場合は、プロファイリングも推奨されます。 これにより、開発者はより無駄のないアプリケーションを作成できます。 この記事では、サーバーの実行が停止するまでメモリが一貫して増加する状況について説明します。

デバッグ用にアプリケーションを設定する

ここで多くのサポートに表示されるメモリが多い理由の 1 つは、アプリケーションに対してデバッグ、トレース、またはその両方が有効になっている場合です。 アプリケーションを開発するときは、デバッグとトレースを有効にする必要があります。 既定では、Visual Studio .NET でアプリケーションを作成すると、Web.configファイルに次の属性セット が 表示されます。

<compilation
 ...
 debug="true"
 />

または

 <trace
 enabled="true"
 ...
 />

また、アプリケーションの最終的なビルドを行う場合は、デバッグ モードではなくリリース モードで実行してください。 運用環境に入ると、デバッグは不要になります。 それは本当にあなたのパフォーマンスを遅くし、あなたの記憶を食べることができます。 この属性を設定すると、アプリケーションの処理方法に関するいくつかの点が変更されます。

最初に、バッチ コンパイルは、この compilation 要素で設定されている場合でも無効になります。 つまり、アプリケーション内のすべてのページにアセンブリを作成して、そのページに分割できるようにします。 これらのアセンブリはメモリ領域全体にランダムに分散できるため、メモリを割り当てる連続した領域を見つけるのが難しくなります。

次に executionTimeout 、属性 (<httpRuntime> 要素) が高い数値に設定され、既定値の 90 秒がオーバーライドされます。 コードを忍耐強くステップ実行して失態を見つける間にアプリケーションをタイムアウトにできないため、デバッグの場合は問題ありません。 ただし、運用環境では重大なリスクです。 これは、何らかの理由で不正な要求がある場合、スレッドに保持され、数分ではなく何日間も有害な動作を続けるということです。

最後に、 一時 ASP.NET ファイル フォルダーにさらにファイルを作成します。 System.Diagnostics.DebuggableAttribute と (System.Diagnostics 名前空間が生成されたすべてのコードに追加され、パフォーマンスが低下する可能性があります。

あなたがこの記事から他に何も得なかったら、私はあなたがこの情報を得ることを願っています。 デバッグを有効にしたままにすることは不適切です。 この動作は頻繁に見られますが、変更は簡単です。 ページ レベルで設定できることに注意してください。 すべてのページで設定されていないことを確認します。

文字列の結合

サーバー側のコードを使用し、ブラウザーに送信する 1 つの大きな HTML 文字列を作成するだけで HTML 出力を構築するアプリケーションがあります。 問題ありませんが、 と & 連結を使用+して文字列を構築している場合は、構築している大きな文字列の数がわからない可能性があります。 例:

string mystring = "<html>";
mystring = mystring + "<table><tr><td>";
mystring = mystring + "First Cell";
mystring = mystring + "</td></tr></table>";
mystring = mystring + "</html>";

このコードは十分に無害なようですが、メモリに格納しているものは次のとおりです。

<html>
<html><table><tr><td>
<html><table><tr><td>First Cell
<html><table><tr><td>First Cell</td></tr></table>
<html><table><tr><td>First Cell</td></tr></table></html>

最後の行だけを格納しているが、これらの 行をすべて 格納していると思われる場合があります。 特に、大きなレコードセットをループして大きなテーブルを構築している場合に、手に渡らない可能性がある方法を確認できます。 それがあなたがやっていることであれば、1つの大きな文字列を格納するように、クラス System.Text.StringBuilder を使用してください。 「Visual C# を使用して文字列連結のパフォーマンスを向上させる」を参照してください

.NET Framework Service Pack 1 (SP1)

.NET Framework SP1 をまだ実行していない場合は、メモリの問題が発生している場合は、この SP をインストールします。 詳しくは説明しませんが、基本的には SP1 でメモリをより効率的に割り当てるようになりました。 基本的には、一度に 64 MB ではなく、大きなオブジェクトに一度に 16 MB を割り当てる必要があります。 私たちは皆移動しましたが、大きな箱ではなく、多くの小さな箱を使用している場合は、車やトラックにもっと多くを詰めることができることを皆が知っています。 ここでのアイデアです。

定期的にリサイクルすることを恐れてはいけません

既定では、IIS のアプリケーション プールを 29 時間ごとにリサイクルします。 Aspnet_wp.exe プロセスは、タスクを終了するか、IIS を再起動するか、コンピューターを再起動するまで継続されます。 この動作は、このプロセスが数か月間実行される可能性があることを意味します。 一部のアプリケーションでは、数日おきに便利なタイミングでワーカー プロセスを再起動することをお勧めします。

質問する

以前は、すぐに修正できるすべてのものでした。 ただし、メモリの問題が発生している場合は、次の質問を自問してください。

  • 多数のラージ オブジェクトを使用していますか? 85,000 KB を超える KB が大きなオブジェクト ヒープに格納されます。

  • セッション状態でオブジェクトを格納していますか? これらのオブジェクトは、使用して破棄する場合よりもはるかに長くメモリに残ります。

  • オブジェクトを Cache 使用していますか? 賢明に使用される場合は、パフォーマンスに大きなメリットがあります。 しかし、それが賢明でないとき、あなたは解放されない多くのメモリを使用して巻き上げる。

  • Web アプリケーションで返す recordsets サイズが大きすぎますか? Web ページで 1,000 件のレコードを確認する必要はありません。 1 回の旅行で 50 から 100 件を超えるレコードを取得しないように、アプリケーションを設計する必要があります。

デバッグ

WinDbg の設定に入りません。 ただし、より複雑な問題のトラブルシューティングを行う場合は、次のコマンドを使用して、メモリ内の正確な内容を確認できます。

!eeheap -gc

このコマンドは、マネージド メモリの量を示します。 この値が高い場合は、マネージド コードでビルドしているものがあります。

!dumpheap -stat

メモリが大きい場合でも、このコマンドの実行にはかなりの時間がかかります。 ただし、このコマンドでは、すべてのオブジェクトの一覧、各型の数、および各オブジェクトが使用しているメモリの量を示します。 (たとえば、クラスの StringBuilder 場合、多くの System.String オブジェクトが表示されます)

オブジェクトが多くのメモリを取っているのを見つけたら、次のコマンドを使用してさらに掘り下げてみます。

!do <addr>

探しているオブジェクトのアドレスは、コマンドで dumpheap 取得できます。

これらの列の特定の状況に対してこの診断ツールを使用する方法をさらに組み込もうとしています。 良い仕事をしている場合は、お知らせください。

メモリとパフォーマンスに関する記事

ガベージ コレクターの基本とパフォーマンス のヒント

High-Performance ASP.NET アプリケーションの開発

パフォーマンス監視の ASP.NET と管理者に警告するタイミング

.NET アプリケーションのパフォーマンスとスケーラビリティの向上