☰

2008 R2 终端服务器：“系统资源不足，无法完成请求的服务”

tag-icon • tag-icon windows-server-2008-r2 terminal-server rds resource-management
2008 R2 终端服务器：“系统资源不足，无法完成请求的服务”

我正在使用在 vSphere 环境中配置的不健康的 Windows 2008 R2 终端服务器。它目前有 4 个 vCPU 和 32GB RAM。沒有超過度承諾。

近几个月来，该服务器上的并发用户数急剧上升（约 70），可能已超过建议水平。由于用户在此系统上使用的应用程序，将其拆分为多个服务器将是一项超出本问题范围的挑战。

然而，在一周的某些时间点（现在几乎是每天），新用户登录会产生以下错误：事件 ID 1500

由于无法加载您的配置文件，Windows 无法让您登录。请检查您是否已连接到网络，以及您的网络是否正常运行。

详细信息 - 系统资源不足，无法完成请求的服务。

这种情况将一直持续，直到某些用户注销、会话被手动断开或系统完全重新启动。

我想知道：

  • 此错误消息指的是哪些资源？实际上哪些资源受到限制？
  • 是否有一个操作系统级别的可调参数或配置可以帮助解决这个问题？
  • 除了此错误消息出现的频率增加外，用户对性能感到满意。这里面还有其他原因吗？
  • 终端服务器可容纳的用户数是否有绝对限制？我看到某些终端服务器调整指南中描述了 150 个以上用户。

在此处输入图片描述

在此处输入图片描述

答案1

这个问题已经解决了。

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

我被指向微软的杜雷格工具来估计注册表的大小。通过 regedit 浏览时，我在打开 下的键时遇到问题HKEY_USERS\.Default\PRINTERS。使用dureg，我开始在该层次结构下进行探测。

问题出在打印机上。原因和解决方法详见：
基于 Windows Server 2008 R2 SP1 的服务器上“HKEY_USERS.DEFAULT”注册表配置单元的大小不断增加

修补程序：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，没有不良影响，也没有与配置文件相关的错误。我监控了打印机注册表配置单元，它保持稳定。

答案2

在 Windows Server 2003 中，该错误是由于内核内存耗尽而导致的。由于您使用的是 Windows Server 2008 R2，我不确定问题的原因与 W2K3 中的原因有多密切相关，但我敢打赌，这是由于用户和进程数量导致的内存问题。我认为非分页池内存耗尽可能是原因。此外，进程数量接近 800，这相当高。MS 可能会告诉您减少进程数量，这只能通过减少用户负载来实现。

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

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

答案3

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

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

当登录失败时，查看其中一个峰值是否出现。

另外：某些原因导致您的系统内核 CPU% 过高 - 您应该调查原因，看看是否会导致相关问题。

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

答案4

我的时间很少，所以我只能做一个粗略的回答，希望稍后能够充实它。

当我在 Citrix 团队工作时，我记得我们试图将每台服务器的用户数量提高到 15-20，但这些服务器上运行着一些繁重的应用程序。如今 x64 可以承载更多用户，但 70+ 听起来确实很多。

perfmon 计数器达到最大值并非罕见的上下文切换，它会导致服务器崩溃，而其他计数器（如 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.

你还可以在容量规划指南中找到一些有用的东西，你可以在这篇博文。

当我有时间回答这个问题时，我会这样做，我只是想在这里补充一点，对 vSphere 虚拟机中所有基于时间的测量提出警告。

由于 vCPU 是从物理 CPU 抽象出来的，因此 vCPU 根本不知道现在是什么时间（一个虚拟秒可能大于或小于一个真实秒（或至少是物理秒）。因此，所有基于时间的性能计数器（CPU 时间、上下文切换/秒等）都是不准确的（有时甚至非常不准确），即使它们可以作为非常粗粒度的指标。

为了验证这一点，请将虚拟机内任何基于本机时间的 CPU 计数器与该虚拟机在 vSphere 主机上的对应计数器进行比较。为此，VMware 通过 VMware 工具将一些 CPU 计数器（以及从客户机角度来看也不准确的内存计数器）发布到两个 VMguest perfmon 对象中。

因此，只有查看 VMware 发布的对象的计数器，才能从客户机性能监视器 (guest perfmon) 中获得正确的基于时间的值。

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

一有时间，我就会编辑白皮书等的链接，详细说明这一点，以及确切的计数器路径\名称。当然，这些都可以在 Google 上找到。

相关内容