web-dev-qa-db-ja.com

2008 R2ターミナルサーバー:「要求されたサービスを完了するためのシステムリソースが不足しています」

VSphere環境で構成された異常なWindows 2008 R2ターミナルサーバーを使用しています。現在、4つのvCPUと32GB RAMを備えています。 オーバーコミットメントなし

このサーバーの同時ユーザー数は、ここ数か月(〜70)で急激に増加し、おそらく推奨レベルを超えています。このシステムでユーザーが使用するアプリケーションのため、これを複数のサーバーに分割することは、この質問の範囲を超える課題になります。

ただし、週の特定の時点(現在はほぼ毎日)で、新しいユーザーログオンにより次のエラーが発生します。イベントID 1500

プロファイルを読み込めないため、ログオンできません。ネットワークに接続していること、およびネットワークが正しく機能していることを確認してください。

詳細-要求されたサービスを完了するためのシステムリソースが不足しています。

これは、一部のユーザーがログオフするか、セッションが手動で切断されるか、システムが完全に再起動するまで続きます。

知りたい:

  • このエラーメッセージはどのリソースを参照していますか?実際に何が制約されていますか?
  • これに役立つOSレベルの調整パラメータまたは構成はありますか?
  • このエラーメッセージの頻度の増加を除いて、ユーザーはパフォーマンスに満足しています。ここで何か他に遊び場はありますか?
  • ターミナルサーバーが対応できるユーザー数に絶対的な制限はありますか?ターミナルサーバーの特定のチューニングガイドに記載されている150人以上のユーザーがいます。

enter image description here

enter image description here

21
ewwhite

これは解決されました。

仮想マシンのCPUとRAMリソースを増やしても問題は解決しなかったため、レジストリの調査を開始しました。

Microsoftの dureg ツールを使用してレジストリのサイズを推定しました。 regeditを使用して閲覧しているときに、HKEY_USERS\.Default\PRINTERSでキーを開くときに問題が発生しました。 duregを使用して、その階層の下でプローブを開始しました。


プリンターが問題でした。原因と修正の詳細は次のとおりです。
「HKEY_USERS.DEFAULT」レジストリハイブのサイズは、Windows Server 2008 R2 SP1ベースのサーバーで継続的に増加します

ホットフィックス: http://support.Microsoft.com/kb/2871131

これは明らかに成長を停止しますが、スペースを再利用するためにキーとレジストリを圧縮する必要があります。

肥大化したレジストリの圧縮: http://support.Microsoft.com/kb/2498915

1)  Boot from a WinPE disk.
2)  Open regedit while booted in WinPe, load the bloated Hive under HLKM. (e.g. HKLM\Bloated)
3)  Once the bloated Hive has been loaded, export the loaded Hive as a "Registry Hive" file with a unique name.
4) Unload the bloated Hive from regedit.
5) Rename the hives so that you will boot with the compressed Hive.
e.g.
c:\windows\system32\config\ren software software.old
c:\windows\system32\config\ren compressedhive software

うーん、いくつかの手順...生産時間中にリモートで行うのはちょっとトリッキーです。私は 常駐のMicrosoftエキスパート に連絡しようとしましたが、彼は忙しいので、いくつかのSCCMまたはSCVMMの問題をどこかで追跡していました。いくつかのCitrix関連のフォーラムを読んで、より少ない手順で上記を実行できるツールに注意しました...

そこで、仮想マシンのスナップショットを撮り、ダウンロードして実行しました フリーウェアレジストリ圧縮ソフトウェア(Tweaking.com) ; Microsoftシステムエンジニアの集団のうめき声の圧倒的な音にもかかわらず...

1.4GBがデフォルトの構成に保存されていることに注意してください...tucows

再起動してください!

再起動後、すべてが順調でした。ユーザー数は86に達し、悪影響やプロファイル関連のエラーはありませんでした。プリンタレジストリHiveを監視しましたが、安定しています。

16
ewwhite

Windows Server 2003では、そのエラーはカーネルメモリの枯渇の結果でした。あなたはWindows Server 2008 R2を扱っているので、問題の原因がW2K3の原因とどれほど密接に関連しているかはわかりませんが、ユーザーとプロセスの数によるメモリの問題だと思います。考えられる原因として、非ページプールメモリの枯渇を見てみましょう。また、プロセス数は約800と非常に多くなっています。 MSはおそらくプロセス数を減らすように指示しますが、これはユーザーの負荷を減らすことによってのみ実行できます。

この記事には、Windowsのメモリ使用量に関するいくつかの優れた情報と、非ページプールの制限を表示して、それが問題の原因であるかどうかを確認する方法が記載されています。

https://blogs.technet.com/b/markrussinovich/archive/2009/03/26/3211216.aspx

3
joeqwerty

Windowsパフォーマンスモニターを起動して、さまざまなカウンターを監視します。

  • コンテキストスイッチ
  • ページテーブルエントリ
  • GDI要素
  • ハンドル
  • …(見つけられるものは何でも)

そして、ログインに失敗したときにこれらのピークの1つがピークになるかどうかを確認します。

また、何かがシステムのカーネルCPU%を高めている-それを調査して、関連する問題につながるかどうかを確認する必要があります。


ser Profile Hive Cleanup サービスは、「ユーザーがログオフしたときにユーザーセッションが完全に終了するようにするのに役立つ」ため、ここで役立ちます。

2
MikeyB

まあ、私がServer 2008 R2でのRDS容量計画について読んだことから、それを使用しているユーザーの数に対して不十分なリソースで貧弱なターミナルサーバーを実行しているだけかもしれません。特に、4つのvCPUで80人のユーザーがいることに気づきました。MSでは、15人のユーザーごとに1コアを推奨しています。

RDSサイジングおよびキャパシティプランニングガイダンス)というタイトルのtechnetブログから==:

We always felt the need of Hardware capacity guidance and sizing information for Terminal Services or Remote Desktop services for Server 2008 R2, Whenever I am engaged in any architectural guidance discussion for RDS deployment i always get a question what needs to be taken into consideration while deciding the hardware configuration and to do capacity planning.

Here are some bullet points which I recommend to my partners and customers to consider:

In addition to that, Microsoft has just released a whitepaper on Capacity Planning in Windows Server 2008 R2.

ここからダウンロード

1
HopelessN00b

私には時間がほとんどないので、大まかな答えを出し、うまくいけば後でそれを具体化します。

私がCitrixチームで呪文をやっていたとき、サーバーあたり15〜20人のユーザーにレベルを上げようとしたことを思い出しましたが、それらには重いアプリがいくつか実行されていました。最近のx64にはより多くのユーザーが読み込まれますが、70歳以上は大したことのように聞こえます。

Perfmonカウンターが最大になることはめったにコンテキストの切り替えではなく、RAM、CPUなどの他のカウンターが良さそうである間、サーバーをフロアします。おそらくそれが理由である可能性があります(過剰なコンテキストの切り替えが原因で、サーバーはタイムアウトする前にリソースを割り当てることができません)。ここに コンテキストの切り替えを監視する2つの方法

The System\Context Switches/sec counter in 
System Monitor reports systemwide context 
switches.

The Thread(_Total)\Context Switches/sec  
counter reports the total number of context 
switches generated per second by all threads.

また、キャパシティプランニングガイドで役立つ情報が見つかるかもしれません。リンクは このブログ投稿 にあります。

この回答に時間を費やすことができる場合は、そうする場合は、vSphere仮想マシン内のすべての時間ベースの測定に注意を向けてここに追加します。

VCPUが物理CPUからどのように抽象化されているかにより、vCPUには現在の時刻がわかりません(1仮想秒は1実秒(または少なくとも物理秒)よりも長いまたは短い場合があります。その結果、すべての時間ベースperfmonカウンター(CPU時間、コンテキストスイッチ/秒など)は、非常に粗いインジケーターとして機能する場合でも、不正確(場合によっては非常に乱暴な場合もあります)です。

これを確認するには、VM内のネイティブの時間ベースのCPUカウンターを、そのVMのvSphereホストの対応するカウンターと比較します。このため、VMwareはCPU(および不正確なメモリ)のカウンターをいくつか公開していますゲストの観点から)VMwareツールを介して2つのVMguest perfmonオブジェクトに。

したがって、正しい時間ベースの値がゲストのperfmon内から利用可能になりますが、これは、VMwareが公開したオブジェクトのカウンターを見る場合に限られます。

これまでの答えは、vSphere仮想マシン内からの時間ベースの測定に焦点を当てているため、この基本情報を少し関連性があると思っただけです。もちろん、この特定の(未完成の)回答のテーマとそのコメントにも直接関係しています。それは誰かに役立つかもしれません。

時間があるとすぐに、これについて詳しく説明したホワイトペーパーなどへのリンクと、正確なカウンターパス\名前を編集します。当然、それもすべてグーグルです。

1
ErikE

WSRM(Windowsシステムリソースマネージャー)の実装をお勧めします。 1つのホストで多数のアプリ、接続、サービスが実行されている場合、システムは誰もが一緒にNiceをプレイする必要があることを認識していません。 Windows Serverは当然、そのリソースのすべてを使用して、認識されない限り、常にすべてを完了しようとします... WSRMに入ります。

WSRMを実装することにより、あらゆる種類のバリエーションごとにリソース制限を設定して、実行中または接続しているすべてのユーザーに公平な競争条件を確保できます。あなたのメモから、これはESX/vSphereの問題のようではなく、常にすべてを競っている接続しているユーザーが多すぎるようです。 WSRMをテストして、すべてのリソースをバランスよく調整するためのメディアを見つける必要がありますが、誰もが慣れてきているパフォーマンスレベルには影響しません。

WSRMの概要: http://technet.Microsoft.com/en-us/library/cc732553.aspx

0
MethoteK