我们有大约 200 台服务器、Hyper V、文件群集和 IIS，它们都遇到了相同的问题，在正常使用过程中，服务器上发生的事件使服务器上的 RAM 达到或接近最大值。一旦发生这种情况，SVCHOST/Workstation 服务（具体来说，通过将 Workstation 服务隔离到其自己的 SVCHOST 来清除）将停止释放句柄/线程，并且该服务使用的内存永远不会被释放。在某些极端情况下，Workstation 服务在 255GB 的服务器上使用了多达 40GB 的 RAM。在某些情况下还会发现多达 4000 万个句柄。
重新启动后，问题当然会消失，直到所有内存都被使用（例如由 W3 进程或 HyperV VM 使用）后才会再次出现，之后 Workstation 服务开始占用所有 RAM。该过程非常缓慢，可能需要数周/数月，具体取决于服务器上的 RAM 数量。
我们的 Hyper V 服务器和 IIS 服务器都访问共享文件，这些共享位于 SSD 存储中，因此性能非常出色。我们已安装所有当前补丁，但尚未迁移到 R2，因为我们已部署了大量工具，这将使这一步变得非常重要，并且找不到任何明确迹象表明此问题将在 R2 中得到修复。
我们运行了 ProcMon 和其他工具，但在问题最严重的服务器上，这些工具甚至无法运行。在其他服务器上，它们提供的结果只是表明该进程中确实存在内存泄漏。
有没有办法释放此进程的内存或完全避免该错误？我们不想重新启动，而且一旦进程处于错误状态，我们就无法重新启动它。该进程将冻结。
我们正在尝试避免通过定期重启来“修复”此问题，因此如能得到任何答复我们将不胜感激。
答案1
我遇到了非常相似的问题，svchost 正在破坏服务器性能。
解决方案：原来我的事件日志已经满了。我把它清空了，然后一切都恢复正常，就像什么事都没发生过一样。
（我还建议更改事件日志的默认大小，见下文）
使用 Windows 界面设置最大日志大小
- 启动事件查看器。
- 在控制台树中，导航到并选择要管理的事件日志。
- 在操作菜单上，单击属性。
- 在最大日志大小（KB）中，使用微调控件设置所需的值，然后单击确定。
这听起来就像这里发生的事情，但最终却是一个非常简单的修复。重新启动可以暂时解决这个问题，但只要有任何东西试图写入日志，一切都会失控，并不断消耗资源。
希望这可以帮助！
答案2
>Is there a way we can free up the memory from this process ?
您无法从外部（正确地）释放分配的内存或处理资源，除非终止有问题的应用程序。
>or avoid the bug all together?
您遇到了内存和资源泄漏。解决问题的唯一方法是找到泄漏并避免触发泄漏（如果可能）或在源代码级别修复泄漏；在后一种情况下，您需要 Microsoft 的帮助来制作补丁，但他们似乎希望您告诉他们问题到底在哪里。
您可以尝试通过使用 MS 来查明内存/资源泄漏，从而找到罪魁祸首应用程序验证器
答案3
创建 RAM 很容易，但没有解决方案。
我建议使用 Sysinternals RAMMAP 或 VMMAP 进行更深入的调查。借助这些工具，您可以更好地了解发生了什么。通常是元文件问题。
自 Server 2008 以来，我们就遇到了这个问题，当从共享启动应用程序时，所有终端服务器都会内存不足，并且随着时间的推移内存消耗会令人难以置信。
我们的解决方法是在单独的终端服务器上托管该应用程序并频繁清除内存消耗。
我们通过自行设计的 c++ 命令行应用程序
在所有进程上使用带有 SeDebugPrivilege 的 SetProcessWorkingSetSize()来实现此目的。
强烈建议不要做这样的事情；）