我们已经注意到当服务器负载较高时，与服务器的远程桌面会话将冻结的问题。
环境：
- VMWare ESX 4.0u1。
- 客户操作系统是Windows Server 2008 R2（这是冻结的服务器）。
- 客户操作系统具有MS SQL Server 2008 R2（10.50.4000）和作为Windows服务运行的内部应用程序。
- 远程桌面客户端通常在Windows 7笔记本电脑上。
将RDP连接到服务器可以正常工作。 当服务器加载时，会发生这种情况：
- 现有的RDP会话无响应，似乎冻结 – 至less屏幕没有更新。 如果一个任务pipe理器正在运行，它将变成静态的，因为你不再看到它每隔几秒就更新统计信息。 你可以点击一个button或者某个东西，视觉响应会被延迟几分钟。
- 通过vmwarepipe理工具进行的控制台会话将以相同的方式冻结。 （所以基本上这似乎影响GUI /交互性）。
- 在这种状态下试图通过RDP进行连接将需要很长时间，而且通常只会显示一个永远不会parsing到实际GUI的黑屏。
- 其他服务继续响应！ 如果运行在服务器上的Web应用程序是通过另一台机器上的浏览器访问的，则它将会相当快地响应并且看起来几乎不受高负载的影响。 使用WMI访问“冻结”服务器的远程进程监视器也可以继续工作。
这种情况下的负载通常由进程A执行顺序（无线程）混合的计算和对进程B的调用组成。当接收到这样的调用时，进程B通常会进行数据库调用，然后进行一些计算，然后将结果返回给进程一个。
在远程进程pipe理器中，我们可以确认进程A，B和SQL Server一起占用100％的CPU，但是由于进程之间的顺序调用，在任何给定的点上应该不会有多于一个的进程准备运行及时。 这些进程是Windows服务，不以任何方式与GUI进行交互。
这就像Windows在其他进程导致负载时完全饿死了CPU周期的GUI组件。
我做了一些实验来检查 – 例如，如果我在我的笔记本电脑上运行一个繁忙循环的三个副本，它们每个将占用33％的CPU，总数将被报告为100％，但是一般来说，Windows GUI仍然会充分响应。
什么导致服务器GUI在负载下如此冻结，以及如何阻止这样做？
VM有6GB内存，SQL Server限制在2GB RAM，其他涉及的服务通常每个都小于200MB。 所以它似乎不是内存耗尽。
服务以正常优先级运行，但我也将它们降低到“低于正常”，而没有真正的行为改变。
更新1
为了缩小这个问题，我尝试了这个：
- 在服务器上，正常优先级，运行一个自定义的进程，这只是一个繁忙的循环。 按照预期，这可以使CPU达到100％。 在此期间，系统对于交互式用户来说仍然是完美的 。
- 向SQL Server发出一个CPU和数据密集型查询（
select * from dbo.Table where Name like '%flarp%'在同一命令批次中重复6次）。 该表有160万条logging。 没有其他进程正在占用大量的CPU资源。 当执行查询时，GUI完全冻结，直到查询批处理完成。 我将SQL Server优先级设置为LOW并重复。 仍冻结GUI。
- 同时尝试以上两种方法。 我首先启动了CPU循环（正常优先），并且需要100％。 不久之后，我启动SQL查询（在低优先级SQL Server中），GUI完全冻结。 远程进程pipe理器指出SQL Server尽pipe优先级较低，但在我的CPU循环（正常优先级）为0％时收到100％的CPU，直到查询完成。 所以尽pipesql server具有较低的优先级，但它完全扼杀了纯粹的CPU循环。