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

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

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

ただし、週の特定の時点（および現在、ほぼ毎日）で、新しいユーザーログオンは次のエラーを生成します。イベントID 1500

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

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

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

知りたい：

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

これは解決されました。

仮想マシンの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

うーん、数ステップ...生産時間中にリモートで行うのはちょっと難しい。私は常駐のマイクロソフトの専門家に連絡して完了を試みましたが、彼はどこかでSCCMまたはSCVMMの問題を追いかけるのに忙しかったです。Citrix関連のフォーラムをいくつか読んで、上記の手順をより少ない手順で実行できるツールに注目しました...

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

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

再起動してください！

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

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

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

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

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

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

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

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

ユーザープロファイルハイブクリーンアップそれは、「ユーザーがログオフ時にユーザーセッションが完全に終了していることを確認するのに役立ちます」のようなサービスはここに助けるかもしれません。

さて、Server 2008 R2のRDSキャパシティプランニングについて読んだことから、それを使用しているユーザー数に対して不十分なリソースで貧弱なターミナルサーバーを実行しているだけかもしれません。特に、4つのvCPUに80人のユーザーがいることに気付き、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:

• 2GBメモリ（RAM）は、CPUの各コアに最適な制限です。たとえば、4 GBのRAMがある場合、最適なパフォーマンスを得るにはデュアルコアCPUが必要です。
• 2デュアルコアCPUのパフォーマンスは、シングルクアッドコアプロセッサよりも優れています。
• 30ユーザーのLANと20ユーザーのWANの推奨帯域幅。帯域幅（b）= 100メガビット/秒（Mbps）、遅延（l）5ミリ秒未満。
• ターミナルサーバーでは、ユーザーごとに64 MBがGPのみの理想的なメモリ（RAM）要件です。OSの場合は+ 2 GB（100ユーザー* 64）+ 2000 = 8.4 GB、つまり8GB RAM。
• 使用するアプリケーション（Office、CADアプリなど）が増えると、ユーザーあたり64 MBのベースメモリを超えるこの計算に、ユーザーごとにメモリを追加する必要があります。
• CPUコアあたり15 TSセッションは、ターミナルサーバーの最適なパフォーマンス制限です。
• ネットワークのホップ数は5を超えてはならず、待ち時間は100ミリ秒未満である必要があります。
• 64 kbpsは、ユーザーセッションごとの理想的な帯域幅です。（256色、スイッチドネットワーク、ビットマップキャッシュのみ）
• コアあたりの％プロセッサ時間が常に65％を超えると、CPUのパフォーマンスが低下します。
• ターミナルサーバーのパフォーマンスは、X64 HWおよびOSで実行すると倍になります。

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

ここからダウンロードしてください

時間がないので、おおまかな答えを出して、後で具体化することを望みます。

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仮想マシン内からの時間ベースの測定に焦点を当てていたため、この基本情報は少し関連があると考えました。もちろん、この特定の（未完成の）回答とそのコメントのテーマにも直接関連しています。誰かに役立つかもしれません。

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

WSRM（Windows System Resource Manager）を実装することをお勧めします。1つのホストで実行されているアプリ、接続、サービスが大量にある場合、システムは全員が一緒にプレイする必要があることを知りません。Windows Serverは、認識されていない限り、すべてのリソースを使用してすべてを常に完了しようとします... WSRMを入力します。

WSRMを実装することにより、あらゆる種類のリソース制限を設定して、実行中のすべてまたは接続されているユーザーすべてに公平な競争条件を確保できます。あなたのノートから、これはESX / vSphereの問題のようには見えないが、むしろすべてのために絶えず競争している接続ユーザーが多すぎる。WSRMをテストして、すべてのリソースのバランスをとるだけでなく、誰もが慣れているパフォーマンスレベルに影響を与えない幸せな媒体を見つける必要があります。

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