2008 R2terminal服务器：“没有足够的系统资源来完成请求的服务”

这已经解决了。

我开始检查registry，因为增加虚拟机上的CPU和RAM资源不能解决问题。

我被指向微软的杜鲁格工具来估计registry的大小。 通过registry浏览，我遇到了打开HKEY_USERS\.Default\PRINTERS下的键的问题。 用dureg ，我开始在这个层次下探索。

打印机是问题。 原因和解决方法详述如下：
基于Windows Server 2008 R2 SP1的服务器上“HKEY_USERS.DEFAULT”registryconfiguration单元的大小不断增加

修补程序： http : //support.microsoft.com/kb/2871131

这显然停止了增长，但密钥和registry需要压缩以回收空间。

压缩臃肿的registry： 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. (eg 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. eg c:\windows\system32\config\ren software software.old c:\windows\system32\config\ren compressedhive software 

嗯，几个步骤…有点棘手在生产时间远程做。 我试图联系我的常驻微软专家来完成，但他正在某处忙于追查SCCM或SCVMM问题 。 通过一些思杰相关的论坛阅读，我注意到一个工具，可以执行上述与更less的步骤…

于是我拿了一个虚拟机快照，然后下载并运行免费软件registry压缩软件（Tweaking.com） ; 尽pipe微软系统工程师在世界各地的集体呻吟的压倒性声音…

注意保存在默认configuration中的1.4GB …

请重新启动！

重启后，一切都很好。 用户数达到86，没有不良影响，没有configuration文件相关的错误。 我监视了打印机registryconfiguration单元，并保持稳定。

在Windows Server 2003中，错误是内核内存耗尽的结果。 因为你正在处理Windows Server 2008 R2，我不确定问题的原因与W2K3的原因有多密切相关，但我敢打赌，这是由于用户和进程的数量而引起的内存问题。 我会看看非分页池内存耗尽的可能原因。 另外，有近800个，相当高。 MS可能会告诉你减less进程的数量，这只能通过减less用户负载来完成。

本文有关于Windows中的内存使用情况的一些很好的信息，以及如何查看非分页池限制以查看是否是问题的原因：

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

启动Windows性能监视器来监视各个计数器：

• 上下文切换
• 页表条目
• GDI元素
• 手柄
• …（无论你能find什么）

当你login失败的时候，看看这些峰值之一。

另外：有些东西在你的系统上造成了很高的内核CPU％ – 你应该调查一下，看看是否会导致你的相关问题。

用户configuration文件configuration单元清理服务可能会在这里提供帮助，因为它“有助于确保用户会话在用户注销时完全终止”。

那么，从我读过的有关Server 2008 R2中RDS容量规划的内容中，您可能只是在没有足够资源的情况下运行您的穷人terminal服务器。 特别是，我注意到你在4个vCPUS上有80个用户，而MSbuild议每15个用户有1个核心。

来自Technet博客“ RDS规模和容量规划指导 ：

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的内存然后为了获得最佳的性能应该是双核心CPU。
• 2双核CPU性能比单核四核处理器要好。
• 推荐30个用户的LAN和20个用户的WAN的带宽。 带宽（b）=带有延迟（l）的每秒100兆比特（Mbps）less于5毫秒。
• 在terminal服务器上每用户64​​ MB是GP的理想内存（RAM）要求。例如（100个用户* 64）+ 2000 = 8.4 GB（即8 GB RAM），仅使用2 GB的操作系统。
• 使用更多的应用程序（例如，Office，CAD应用程序等）将需要每个用户更多的内存添加到每个用户64 MB基本内存的计算中。
• 每CPU内核15 TS会话是terminal服务器的最佳性能限制。
• networking不应该有超过5跳，延迟应该在100ms以下。
• 64 kbps是每个用户会话的理想带宽。 （256色，切换networking，只有位图caching）
• 如果每个内核的处理器时间百分比始终高于65％，CPU性能就会下降。
• 在X64硬件和操作系统上运行时，terminal服务器的性能会翻倍。

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

在这里下载

我只有很less的时间，所以我只是做一个粗略的答案，希望稍后可以充实。

当我在Citrix团队中进行拼写时，我记得我们试图将服务器级别设置为15-20个用户，但是那些运行着一些大型应用程序。 这些日子我们加载了更多的用户，但70+听起来很多。

perfmon计数器最大化并不是很less的上下文切换，它会放置一台服务器，而像RAM，CPU等其他计数器看起来不错。 可能这可能是一个原因（由于过度的上下文切换，服务器在超时之前不能分配资源）。 这里有两种方法来监视上下文切换 ：

 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. 

你也可以在容量规划指南中find一些有用的东西，你可以在这个博客文章中find它的链接。

当我可以把时间放在这个答案上的时候，我会这样做，我只是在这里添加一个关于vSphere虚拟机内所有基于时间的度量的警告。

由于vCPU是如何从物理CPU中抽象出来的，vCPU并不知道它是什么时间（一个虚拟的秒可能多于或less于一个真实的（或至less是物理的）秒），因此，所有的时间基于性能计数器（CPU时间，上下文切换/秒等）是不准确的（有时甚至是非常严重），即使它们可能作为非常粗糙的指标。

要validation此情况，请比较VM内的任何基于本机时间的CPU计数器与该VM的vSphere主机上的对应计数器。 由于这个原因，VMware通过VMware工具发布了一些用于CPU（和内存，这从客户angular度来看也是不准确的）的计数器，并将其存储到两个VMguest perfmon对象中。

因此，只有在查看VMware发布的对象计数器的情况下，才能在来宾perfmon中使用正确的基于时间的值。

我只是觉得这个基本信息有点相关，因为到目前为止，答案都是关注基于时间的vSphere虚拟机中的测量结果，在某些情况下这是一个正确分析的关键情况。 这当然也直接关系到这个特定（未完成）答案的主题及其评论。 这可能对某人有用。

只要我得到时间，我会编辑链接到白皮书等详细说明这一点，确切的计数器path\名称。 自然也是所有的googleable。

我会build议实施WSRM（Windows系统资源pipe理器）。 当一个主机上运行着大量的应用程序，连接和服务时，系统并不知道每个人都需要一起玩。 Windows Server自然会尝试使用它的所有资源来完成所有的事情，除非它意识到…进入WSRM。

通过实施WSRM，您可以通过各种变化来设置资源限制，以确保运行或用户连接的所有内容都具有均匀的运动场。 从你的笔记来看，这似乎不是一个ESX / vSphere问题，而是太多的连接用户不断争夺一切。 您将不得不testingWSRM，以find平衡各种资源的快乐媒介，但也不会影响每个人已经习惯的性能水平。

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