我正在使用运行在Hyper-V虚拟机中的Windows Server 2008。 系统performance非常糟糕。 我们很确定这是由于内存不足。 我已经看了如何找出我的Windows Server 2003是否需要更多内存？ ，而且我很确定看到每秒input大于300页，那么内存就是问题所在。
不过，我正在问一个更广泛的问题。 我希望将pipe理层的注意力集中在等待这些页面错误时浪费的时间。 有没有办法确定等待分页或其他资源需要花费多less时间？ 我对交互式用户花费的时间特别感兴趣，但是包含非交互式用途的编号也是有帮助的。
澄清，所以这似乎不像呜呜声：
这个系统是如此之慢，以至于它花了几分钟 ，而一个notepad.exe窗口是活动的，以激活已打开并显示第二个notepad.exe窗口。 这只是激活 。 性能不是稍差。 我认为这一天浪费了几十个工时。
我正在寻找一种方法向pipe理层明确表示浪费了多less时间。 这是在我们实际上没有十个工时浪费的时候发生的。
对不起，我没有提供更多的细节。
此服务器正在用于SharePoint（WSS 3.0）开发。 它运行IIS 7，每个开发人员至lessconfiguration一个应用程序池。 每个开发人员都有一个或多个Web应用程序，每个Web应用程序都在AppPool中分配给该开发人员凭据。 我们正在运行Visual Studio 2008 SP1和SQL Server 2008. SQL Server数据位于与操作系统不同的虚拟磁盘上。
我已经在系统上看到了多达8个开发人员。 服务器configuration有2GB的RAM，由于主机的限制，此时更多的RAM不是微不足道的。 如果我能够提出足够的理由来纠正这个问题，我希望这个问题能够得到纠正：这是浪费了多less时间。
感谢您的答复和评论。 我同意这个解决scheme – 将SharePoint加载到一个4-8GB的服务器上，然后把SQL Server移动到另一个2-4GB。
但我的问题更像是：是否有任何性能计数器或工具，可以告诉我等待页面读取和写入的时间量？ 任何可以告诉我等待排队的磁盘I / O花费的时间？
有可能获得像“每秒input页数”这样的性能计数器，但很难说这个计数器的值是“太多”了。 如果有“计数器”可以说因为每秒input页面而花费了多less时间，那对我的目的会更好。
此服务器正在用于SharePoint（WSS 3.0）开发。 它运行IIS 7，每个开发人员至lessconfiguration一个应用程序池。 每个开发人员都有一个或多个Web应用程序，每个Web应用程序都在AppPool中分配给该开发人员凭据。 我们正在运行Visual Studio 2008 SP1和SQL Server 2008. SQL Server数据位于与操作系统不同的虚拟磁盘上。
我已经在系统上看到了多达8个开发人员。 服务器configuration有2GB的RAM，由于主机的限制，此时更多的RAM不是微不足道的。 如果我能够提出足够的理由来纠正这个问题，我希望这个问题能够得到纠正：这是浪费了多less时间。
甚至没有查看SharePoint 2007的硬件要求，最多有8个开发人员拥有自己的应用程序池。 我假设 SQL Server是另一个VM，但是如果它是一个相同的Win2k8机器，那么这个问题是没有问题的。
用于VisualStudio开发的AppPools（从2005-2008的版本）可以轻松地增长到每个AppPool 150MB-250MB，等待诸多因素。 使用250mb x 8devs = 2GB。 我们不要忘记操作系统本身和SQL Server可能需要的内存。 简而言之：你只是没有足够的内存。 加载在RAM上，尽可能多的，你可以得到。 如果它至less从背景angular度和可能的前景解决了服务器的“缓慢”的大部分，我不会感到惊讶。
仅供参考：Microsoftbuild议最低4 GB的SharePoint 2007应用程序服务器（ 链接 ），但实际上，微软尽可能多地占用资源。 现在，在同一个URL中，他们提到了独立SharePoint服务器最低为2GB，但是如果开发人员直接在该服务器上使用他们自己的AppPool工作 ，则显然IIS正在耗尽AppPools / Sites的所有可用内存。 不要使用build议的最小RAM。 如果可能的话，尽量使用双倍，三倍，四倍内存（预算允许）。
编辑：您提到SQL Server 数据位于单独的虚拟磁盘上，但SQL Server是否安装在同一台SharePoint服务器上？ SharePoint服务器上还有多less可用的存储空间？ 这些附加因素很容易消耗服务器资源，不应忽视。
再次编辑：由于您提到（而且我没有读到）， “由于主机的限制，RAM在这个时候不是微不足道的” ，只有一个真正的解决scheme：获得一台新的主机。 2GB是不足以运行SharePoint / SQL / IIS /任何时期。 很抱歉，但恕我直言，一台机器运行这应该有至less8GB内存。
在编辑之后编辑：
但我的问题更像是：是否有任何性能计数器或工具，可以告诉我等待页面读取和写入的时间量？ 任何可以告诉我等待排队的磁盘I / O花费的时间？
我没有遇到你确切的情况，但是有一篇来自Microsoft TechNet的关于监视器指标基础知识的文章（ 链接 ）。 我不确定是否花时间等待排队的磁盘I / O是获得你想要的最好的方式（我假设pipe理支持）。
有可能获得像“每秒input页数”这样的性能计数器，但很难说这个计数器的值是“太多”了。 如果有“计数器”可以说因为每秒input页面而花费了多less时间，那对我的目的会更好。
Server 2003上Windowsnetworking（ 链接 ）的文章比我更好地解释了这些计数器。 FTA：
Memory \ Pages / sec计数器表示在测量间隔期间对磁盘进行的寻呼操作次数，这是主计数器，用于指示可能没有足够的RAM来满足服务器的需要。 这里的一个好主意是configuration一个perfmon警报，当系统上的每个页面的每秒页数超过50时触发。 此处另一个关键的计数器是Memory \ Available Bytes ，如果这个计数器大于你机器中实际RAM的10％，那么你可能有足够多的RAM，不用担心。
您应该使用Memory \ Available Bytes计数器做两件事情：为此计数器创build一个性能日志，并定期监视它，看看是否有下降的趋势发展，并设置一个警告，如果它下降到安装的RAM的2％以下。 如果下降的趋势确实发展，您可以监视每个stream程实例的进程（实例）\工作集 ，以确定哪个进程消耗越来越多的RAM。 进程（实例）\工作集测量每个进程的工作集的大小，这表明进程可以解决分配的页面数量，而不会产生页面错误。 一个相关的计数器是内存\高速caching字节 ，它测量系统的工作集，即内核线程可以处理的分配页面的数量，而不会产生页面错误。
最后，RAM不足的另一个证实指示器是内存\转换故障/秒 ，它测量备用列表中最近修剪的页面被重新引用的频率。 如果这个计数器慢慢开始随着时间的推移而增加，那么它也可能表明你正在到达一个你没有足够的内存让你的服务器正常工作的地步。
所以我会说这个解释确实解决了你的指标和对指标实际上对你意味着什么的理解。 性能监视器有点棘手，特别是如果您不完全了解计数器在macros伟计划中的含义。 我经常发现自己在阅读柜台，因为很容易忘记他们的“真实世界”的含义。
这听起来像你需要开始使用perfmon。 你会想设置计数器的东西，如内存（可用的MBytes（我猜是接近或在0），％使用的字节数），也可能是一些磁盘监视器。 您的硬盘很可能会磨碎不间断的页面文件，使其达到最大尺寸。 不过，我只是提供这些build议，所以你可以自己查看performance。 回答这个问题的第一个答案是：记忆。 如果您的服务器的内存限制是2GB，那么您需要购买或拼凑一个额外的服务器。 我不确定是否有另一个许可证，但是2GB不足以运行SharePoint，更不用说其他正在运行的其他应用程序/环境。 话虽如此，没有什么是一个很好的挑战。 ：） 祝你好运！
服务器没有被优化用于前台任务，所以在其上的记事本窗口之间的切换将不是一个有效的性能指标。 你需要启动进程资源pipe理器或任务pipe理器，并开始在那里查看一些统计数据，然后可能做一些性能计数器，看看他们给你回来。 还要检查在服务器上运行的其他任务（不要说它的angular色是什么，所以不可能更具体）。