2

Windows Server 2003 Service Pack 2で実行されているWin32コンソールアプリケーションの中には、次の場合に定期的に失敗するものがあります。

エラー1450（ERROR_NO_SYSTEM_RESOURCES）：「要求されたサービスを完了するのに十分なシステムリソースが存在しません。」

私たちが見つけたすべてのドキュメントは、それが不足している無料のシステムページテーブルエントリの数にリンクされていることを示唆しています。これらのマシンには16GBのRAMがあり、/3GBオペレーティングシステムスイッチを使用してWindowsカーネルを1GBに圧縮し、プロセスが3GBのアドレス空間にアクセスできるようにします。これにより、空きシステムページテーブルエントリの総数が大幅に減少するため、MapViewOfFile（）を多用することと組み合わせると、カーネルページテーブルエントリが不足していることはおそらく驚くべきことではありません。

ただし、パフォーマンスモニターを使用して[空きシステムページテーブルエントリ]カウンターを表示する場合、値は再起動時に約36,000であり、アプリケーションの起動時に低下しません。多くの大きなメモリマップファイルを開くアプリケーションがカーネルページテーブルに影響を与えないとは信じがたいです。カウンターが信じられない場合は、システムの変更による影響をテストするのがはるかに困難になります。

有望なナレッジベースの記事があります。パフォーマンスツールは、Windows Server 2003で利用可能な無料のシステムページテーブルエントリを正確に表示しませんが、問題はService Pack 1で修正されており、すでにServicePack2を使用しています。

他の誰かがこの問題に苦労したり解決したりしましたか？

更新： windbg（カーネルのデバッグ）で！sysptesをチェックしましたが、値はパフォーマンスカウンターと一致し、約36,000です。これは、実際には多くの空きページテーブルエントリがあり、Windowsが真実を語っていることを意味している可能性が高いと思います。PTEが不足していないのに、なぜ1450エラーが発生するのかという疑問が残ります。

さらなる更新： 1450エラーが発生した理由の根底に到達することはありませんでした。 ただし、代わりに、これらのサーバーのOSを64ビットWindowsにアップグレードしました。これにより、既存の32ビットアプリケーション（再コンパイルなし）が4 GBの仮想アドレス空間全体にアクセスできるようになり、厄介なページテーブルエントリを含むカーネルメモリ領域も必要なだけ大きくなります。それ以来、1450エラーは発生していないと思います。

4

3 に答える 3

1

システムの PTE 情報を取得するために、windbg コマンド「!sysptes」を試すことができますか? ライブ カーネル デバッグでこれを実行できるかどうかはわかりません。メモリ ダンプを取得する必要があるかもしれません。

于 2008-09-13T21:36:38.977 に答える
0

なぜそれが無料のシステムページテーブルエントリの不足によってのみERROR_NO_SYSTEM_RESOURCES引き起こされていると思うのかわかりませんか？私の知る限り、このような一般的なエラーコードは複数のリソースタイプに使用されます。実際、最初のGoogleヒットは、ファイルキャッシュメモリが不足するとそれも発生する可能性があることを示唆しています。（このエラーモードを作動させたXPバグのKB）。

あなたの場合、私は「ハンドルカウント」をチェックしているでしょう。もう1つの考えられる問題は、アドレス空間の断片化です。1GBのファイルマッピングビューを作成する場合は、1GBの空きアドレス空間が必要であり、連続している必要があります。1GBファイル、800 MBファイル、および1GBファイルをマップし、800MBファイルを閉じて900MBファイルを開くと、900MBファイルが残っている穴に収まらない場合があります。

于 2008-09-26T13:33:06.733 に答える
0

MSには、32ビットOSが4 GB以上のRAMを搭載したハードウェアを「処理」できるようにする2つの方法があります。

オプション 1: Boot.ini の /3GB スイッチで行ったことです。

オプション 1 の長所と短所:

(短所)このオプションは、通常の 2 GB カーネル領域から 1 GB を消費するため、OS はページ プール割り当てとカーネル スタック割り当ての両方の要求を満たすのに苦労します。そのため、/3GB スイッチを使用すると役立つと考える人もいるかもしれませんが、実際には、このオプションは 32 ビット Windows OS をゆっくりと死に至らしめています。

（短所）しかし、これは私のアプリに3GBを与えます....間違っています（したがって、これは短所です）問題は、ベンダーから「/ 3GBスイッチ対応」になるように再コンパイルされたアプリケーションのみが、余分な1 GBを実際に使用できることです。 . したがって、/3GB スイッチの全体的な使用は、誰にとっても本当に悪い冗談です。

より良い記事については、このリンクを読んでください。

http://blogs.technet.com/askperf/archive/2007/03/23/memory-management-demystifying-3gb.aspx

オプション 2: Boot.ini で /PAE スイッチを使用します。

オプション 2 の長所と短所:

(長所) 4GB 以上の RAM がある場合、これは実際にはこの唯一のオプションです。完全なアプリケーション メモリ フットプリントを RAM に配置することで、アプリケーションを騙します。通常、アプリケーションの「ワーキング セット」メモリのみが RAM にあり、残りのアプリケーション メモリ要件は Windows ページファイルに入ります。アプリケーションの総メモリ要件とは?? - 「仮想サイズ」と呼ばれます。

私の世界では、私が扱っている巨大な Java ベースの IBM 製品があります。「アプリケーション」を実行しているサーバーには、16 GB の RAM があります。/PAE スイッチを追加するだけで、(sysinternals Processes Explorer のおかげで) アプリケーションのページング要求が 1 秒あたり 200 KB から最大 4 MB になるのを監視できます。

質問：「なぜ」？

回答:アプリケーション全体が RAM にあります。

質問:「アプリケーションは、完全に RAM で実行されていることを認識していますか?

回答:いいえ - それは常に実行されていたのと同じ古い方法で実行されています。RAM に存在する「ワーキング セット」メモリとしてそれ自体の一部を「考え」、残りのアプリケーション メモリ要件は Windows ページファイルに入ります。

はい、その弾きGOODです。

注意: Microsoft は、優れた Windows OS オプションについて誰にでも伝えるのに不十分な仕事をしています。当たり前

試してみて、stackoverflow に報告してください....

于 2009-05-06T06:23:28.917 に答える