在 Windows Server 2008 上浪费了多少时间？

Question

我使用的是 Windows Server 2008，在 Hyper-V 虚拟机中运行。系统性能非常差。我们很确定这是由于内存不足造成的。我查看了如何确定我的 Windows Server 2003 是否需要更多内存？，而且我很确定每秒输入超过 300 页，这就是内存的问题。

但是，我要问一个更广泛的问题。我想将管理层的注意力集中在等待这些页面错误时浪费的时间上。有没有办法确定等待分页或其他资源所花费的时间？我对交互式用户花费的时间特别感兴趣，但包含非交互式使用的数字也会有所帮助。

---

澄清一下，这似乎不像抱怨：

这个系统太慢了，当一个 notepad.exe 窗口处于活动状态时，它需要几分钟才能激活已经打开并显示的第二个 notepad.exe 窗口。那只是激活。性能也不算差。我认为这相当于每天浪费数十个工时。

我正在寻找一种方法来向管理层说明浪费了多少时间。这发生在我们实际上没有十个工时可以浪费的时候。

---

抱歉我没有提供更多细节。

此服务器正用于 SharePoint (WSS 3.0) 开发。它运行 IIS 7，每个开发人员至少有一个应用程序池。每个开发人员都有一个或多个 Web 应用程序，每个应用程序都设置在分配给该开发人员凭据的 AppPool 中。我们正在运行 Visual Studio 2008 SP1 和 SQL Server 2008。SQL Server 数据位于与操作系统不同的虚拟磁盘上。

我一次在系统上看到了多达 8 个开发人员。服务器配置了 2GB 的 RAM，由于主机的限制，此时更多的 RAM 并非小事。如果我能提出足够的理由来纠正它，我希望这会得到纠正，形式是：这是浪费了多少时间。

---

编辑

感谢您的回答和评论。我同意该解决方案 - 将 SharePoint 负载加载到 4-8GB 服务器上，然后将 SQL Server 移动到具有 2-4GB 的第二个服务器上。

但我的问题更像是：是否有任何性能计数器或工具可以告诉我等待页面读取和写入所花费的时间？任何可以告诉我等待排队磁盘 I/O 所花费的时间？

可以获得诸如“每秒输入页数”之类的性能计数器，但很难说该计数器的值“太多”了。如果有“计数器”可以说明由于每秒输入的页面而花费了多少时间，那么对我的目的来说会更好。

Answer 1

此服务器正用于 SharePoint (WSS 3.0) 开发。它运行 IIS 7，每个开发人员至少有一个应用程序池。每个开发人员都有一个或多个 Web 应用程序，每个应用程序都设置在分配给该开发人员凭据的 AppPool 中。我们正在运行 Visual Studio 2008 SP1 和 SQL Server 2008。SQL Server 数据位于与操作系统不同的虚拟磁盘上。

我一次在系统上看到了多达 8 个开发人员。服务器配置了 2GB 的 RAM，由于主机的限制，此时更多的 RAM 并非小事。如果我能提出足够的理由来纠正它，我希望这会得到纠正，形式是：这是浪费了多少时间。

甚至不考虑 SharePoint 2007 的硬件要求，最多有 8 个开发人员拥有自己的应用程序池。我假设SQL Server 是另一台虚拟机，但如果它是同一台 Win2k8 机器，那么问题是什么就没有问题了。

用于 VisualStudio 开发的 AppPools（2005 年至 2008 年的版本）可以轻松增长到每个 AppPool 150MB-250MB，这取决于许多因素。250mb x 8devs = 2gb 使用。我们不要忘记操作系统本身以及可能的 SQL Server 需要的内存。简而言之：您根本没有足够的 RAM。尽可能多地加载 RAM。如果它至少从后台和前台的角度解决了服务器的大部分“缓慢”问题，我不会感到惊讶。

仅供参考：Microsoft 建议为 SharePoint 2007 应用程序服务器（链接）提供至少 4GB 的空间，但实际上，Microsoft 会尽可能多地占用资源。现在在同一个 URL 中，他们提到独立 SharePoint 服务器至少需要 2GB，但如果开发人员直接使用他们自己的 AppPool在该服务器上工作，很明显 IIS 正在耗尽 AppPools/Sites 的所有可用内存。不要使用推荐的最小 RAM。如果可能（预算允许），尝试将 RAM 要求提高一倍、三倍、四倍。

编辑：您提到 SQL Server数据位于单独的虚拟磁盘上，但 SQL Server 是否安装在同一台 SharePoint 服务器上？SharePoint 服务器上还有多少可用的免费存储空间？这些额外的因素很容易消耗服务器资源，不容忽视。

再次编辑：由于您提到（并且我没有阅读）“由于主机的限制，此时 RAM 并非微不足道”，因此只有一个真正的解决方案：获得一台新的主机。2GB 不足以运行 SharePoint/SQL/IIS/任何时期。抱歉，恕我直言，运行此程序的机器至少应具有 8GB RAM。

OP编辑后编辑：

但我的问题更像是：是否有任何性能计数器或工具可以告诉我等待页面读取和写入所花费的时间？任何可以告诉我等待排队磁盘 I/O 所花费的时间？

我还没有遇到您的确切情况，但是Microsoft TechNet 上有一篇关于监视器指标基础知识的好文章（链接）。我不确定花在等待排队磁盘 I/O 上的时间是否是获得所需内容的最佳方式（我假设有管理支持）。

可以获得诸如“每秒输入页数”之类的性能计数器，但很难说该计数器的值“太多”了。如果有“计数器”可以说明由于每秒输入的页面数而花费了多少时间，那么对我的目的来说会更好。

Server 2003 上Windows Networking 的一篇文章（链接）比我能更好地解释这些计数器。自贸协定：

该内存\页/秒计数器指示在测量间隔期间寻呼到磁盘操作的数量，而这是主要的计数器来监视可能的RAM不足指示，以满足服务器的需求。这里的一个好主意是配置一个 perfmon 警报，当每秒页面数超过系统上每个分页磁盘 50 时触发。此处要注意的另一个关键计数器是 Memory\Available Bytes，如果此计数器大于计算机中实际 RAM 的 10%，那么您可能有足够的 RAM，无需担心。

您应该对Memory\Available Bytes计数器做两件事 ：为此计数器创建性能日志并定期监视它以查看是否有任何下降趋势发展，并设置警报以在低于已安装 RAM 的 2% 时触发。如果确实出现下降趋势，您可以监控 每个进程实例的Process(instance)\Working Set，以确定哪个进程消耗的 RAM 量越来越大。 Process(instance)\Working Set测量每个进程的工作集的大小，它表示进程可以在不产生页面错误的情况下寻址的已分配页面的数量。一个相关的计数器是 Memory\Cache Bytes，它测量系统的工作集，即内核线程可以在不产生页面错误的情况下寻址的已分配页面的数量。

最后，另一个证实 RAM 不足的指标是 Memory\Transition Faults/sec，它测量重新引用备用列表中最近修剪过的页面的频率。如果这个计数器随着时间的推移慢慢开始上升，那么它也可能表明您已经达到了一个点，您不再有足够的 RAM 来让您的服务器正常运行。

所以我想说这个解释确实解决了你的指标，并理解了指标对你的实际意义。性能监视器有点棘手，特别是如果您不完全理解计数器在总体方案中的含义。我经常发现自己在阅读有关计数器的信息，因为很容易忘记它们“现实世界”的含义。