我的雇主在全国拥有一千多台服务器（运行 SQL Server 2005 x64 和其他几个应用程序）。在我看来，他们都没有能力完成他们需要做的事情。
具体来说，我觉得服务器根本没有足够的 RAM 来满足要求机器处理的容量。目前所有服务器都有 6GB 的 RAM。用户几乎总是抱怨性能（主要是因为，immo，服务器经常进入页面文件）。
我终于说服了至少在一个盒子上尝试内存升级并查看结果的权力。但是，他们需要前后指标，以便他们可以看到费用是合理的。
我的问题是我应该收集哪些指标来查看性能是否真正提高了盒子？我是一名开发人员，所以我不确定如何收集以及收集什么（我对 Perfmon 有一些了解）。
编辑：我想我正在寻找特定的计数器来测试。
我建议您在通过应用程序进行内存升级之前和之后对盒子进行负载测试。从用户的角度模拟负载导致性能下降的原因，然后显示内存升级后的改进（类似 jmeter 的东西可以在 webapp 上做到这一点）。如果您不能通过应用程序的负载测试来做到这一点，也许您可以模拟查询。
然后在执行此操作的同时，您还可以运行 Farseeker 推荐的计数器。我认为您应该通过前端进行操作的原因是这些是业务人员，他们可能不会获得整个页面文件的解释或查询时间等。但是，他们应该了解应用程序响应时间，因为这是每个人都在寻找的改善。
但是，如果测试成本高于内存本身（制定测试计划、设置服务器以生成负载等），也许你应该让他们相信你的判断，或者尽你所能做最好的测试。
检查是否需要内存升级通常非常简单。一些
perfmon计数器会告诉您操作系统浸入页面文件的次数，以及内存利用率、页面等。此外，由于它是 SQL Server，您还可以使用分析器查看正在执行的磁盘读取次数某些查询。如果内存利用率小于 90%，则 SQL Server 未进行最佳配置。不要为此使用任务管理器，因为它的“空闲”内存列包括分配给预取的数量。您需要能够通过这些指标说服他们（和您自己）这是必要的，然后您甚至可以在测试之前/之后进行测试。之前/之后的测试通常只是备份您的原始证明。而且，如果您的指标不建议您需要更多 RAM，那么这可以节省您的注意力。
但是，对于之前/之后的查询，我会采用一个常用的查询（不太简单，真实的东西），将其放入 SQL Management Studio，打开执行计划（这样您就可以确保每个查询都运行相同的计划时间，因此你得到了有效的结果），以及他们需要多长时间。
收集页面速率、磁盘队列等的一些性能统计数据可能也是值得的。
如果您确实继续升级，请记住并非所有 RAM 都是完美生产的。即使是 ECC ram 也可以生产出有缺陷的产品，尽管严重的缺陷很少见。如果可能，在将内存安装到服务器之前，使用 Memtest86+ 之类的东西对内存进行初步验证。如果您可以在安装后运行相同的测试，那就更好了，但这意味着更多的停机时间。
如果您的“升级”导致服务器不稳定，您的客户将不会高兴。
性能监视器计数器都很好，但它们并不总是能说明问题。我认为您还需要根据用户对应用程序性能的看法的变化来衡量这一点。
您是否有一个“SLA”来定义此应用在某些任务/场景中的可接受性能（如果没有，为什么不呢？）。
要么你会看到应用程序响应能力的“实际”改进导致性能投诉的可量化下降，和/或应用程序在满足其 SLA 要求方面做得更好，或者你不会。
是否为系统正确“调整”了服务？可能是 SQL 进程正在使用大量内存，因为它喜欢这样做，并且没有定义它可以使用的限制，这会影响应用程序的基于 SQL 的部分之外的其他组件的性能?
您是否确定这不是磁盘或网络瓶颈？