我的雇主在全国拥有一千多台服务器（运行 SQL Server 2005 x64 和一些其他应用程序）。在我看来，这些服务器的性能远远不足以满足其需要。
具体来说，我觉得服务器根本没有足够的 RAM 来处理机器需要处理的大量数据。所有服务器目前都有 6GB RAM。用户几乎总是抱怨性能（主要是因为，在我看来，服务器经常使用分页文件）。
我最终说服了那些有权势的人，至少在一台机器上尝试一下内存升级，看看结果。但是，他们想要前后指标，这样他们才能知道这笔开支是否合理。
我的问题是，我应该收集哪些指标才能了解设备的性能是否真的有所提高？我是一名开发人员，因此我不确定如何收集以及收集哪些数据（我对 Perfmon 了解不多）。
编辑：我想我正在寻找要测试的特定计数器。
答案1
我建议您在内存升级之前和之后通过应用程序对机器进行负载测试。从用户的角度模拟导致性能下降的负载，然后显示内存升级后的改进（jmeter 之类的工具可以在 webapp 上执行此操作）。如果您无法通过应用程序的负载测试来做到这一点，也许您可以模拟查询。
然后，在执行此操作的同时，您还可以运行 Farseeker 推荐的计数器。我认为您应该通过前端执行此操作的原因是，他们是商务人士，他们可能不会获得整个页面文件的解释或查询时间等。但他们应该了解应用程序响应时间，因为这是每个人都希望改进的。
但是，如果测试的成本超过了内存本身（制定测试计划、设置服务器来生成负载等），也许你应该要求他们相信你的判断，或者尽你所能做最好的测试。
答案2
检查是否需要升级内存通常非常简单。一些perfmon计数器会告诉您操作系统访问页面文件的次数，以及内存利用率、页面等。此外，由于它是 SQL Server，您还可以使用分析器查看某些查询执行了多少次磁盘读取。如果内存利用率低于 90%，则 SQL Server 的配置不是最佳的。不要为此使用任务管理器，因为它的“可用”内存列包括分配给预取的量。
您需要能够通过这些指标说服他们（和您自己）这是必要的，然后才开始进行前后测试。前后测试通常只是支持您最初的证明。如果您的指标没有表明您需要更多 RAM，那么这可以避免您的尴尬。
但是，对于前/后查询，我会采用一个常用的查询（不是太简单，而是一些现实生活中的东西），将其放入 SQL 管理工作室，打开执行计划（这样您就可以确保它每次都运行相同的计划，从而获得有效的结果），并计时它们花费的时间。
答案3
收集一些有关页面速率、磁盘队列等的性能统计数据也可能是值得的。
答案4
性能监视器计数器虽然很好，但它们并不总是能说明全部情况。我认为您还需要根据用户对应用程序性能的感知变化来衡量这一点。
您是否有“SLA”来定义此应用程序在某些任务/场景中可接受的性能（如果没有，为什么？）。
您要么会看到应用程序响应能力的“实际”改善，从而导致性能投诉明显下降，和/或应用程序更好地满足其 SLA 要求，要么就不会。
服务是否已针对系统进行了正确的“调整”？ 会不会是 SQL 进程占用了大量内存（这是它喜欢做的事情），并且没有定义其可使用内存的限制，而这会影响除基于 SQL 的应用程序部分之外的其他组件的性能？
您是否确定这不是磁盘或网络瓶颈？