对于如何通过perfmon.exe对windows系统与SQL SERVER 2008数据库服务性能监控分析-------性能监控大部分人都会，但是对于少部分性能测试初学者他们对系统资源、中间件、数据库等性能监控分析都是各自分析各自的性能指标没有很好的把系统性能指标和数据库应对于得性能指标结合一起监控分析等方式造成收集到各项性能指标数据无法完全对映出来组建性能问题最终无法及时准确定位问题。因此对于从操作系统、数据库的角度出发分别对其各项性能指标参数进行了分析，梳理它们之间性能参数之间的关系，进而才能充分发挥性能测试监控诊断分析的优势才能更好的为性能优化提供有价值的参考依据。

1.操作系统监控CPU与SQL SERVER

CPU性能指标：Privileged Time：(CPU内核时间)是指处理线程执行代码所花时间的百分比。如果该参数值和“ Physical Disk ”参数值一直很高，表明I/O有问题。SQL compilations/sec，每秒的SQL编译数，表示编译SQL路径被引入的次数，包括需要重新编译的。SQL SERVER用户活动稳定后，该值也达到某一稳定状态值。recompilations/sec(每秒SQL重编译数)每秒的SQL重新编译数。计算重新编译被触发的次数。一般来说，重新编译计数器最好保持较低值。 假如SQL SERVER数据库服务器的CPU值很高，而没有抓取到相应影响CPU使用率的的SQL语句时可以尝试把该性能指标值加入监控范围内，查看该指标是否很高，如果很高则说明系统在不断的编译，进而影响服务器CPU资源的使用开销。

2.内存与SQL SERVER：

内存 sql server可使用的内存量是sql server性能最关键因素之一。而内存同I/O子系统的关系也是一个非常重要的因素。例如，在I/O操作频繁的系统中，sql server用来缓存数据的可用内存越多，必须执行的物理I/O也就越少。这是因为数据将从数据缓存中读取而不是从磁盘读取。同样，内存量的不足会引起明显的磁盘读写瓶颈，因为系统缓存能力不足会引起更多的物理磁盘I/O。这时可以利用system monitor检查sql server的buffer cache hit ratio计数器，如果命中率经常低于90%，就应该添加更多的内存。以及IO 与CPU内存之间的互相影响关系等等。

3.内存与IO性能指标结合分析问题：

Page Reads/sec：这个值如果很高往往意味着内存存在瓶颈，如果这个值比较低，而%Disk Time 和Avg. Disk Queue Length比较高的话，则意味着瓶颈在磁盘 磁盘、CPU、内存如何结合分析因为有时问题不是单一性而是连锁反应的，可能由于过多的页交换要使用大量的硬盘空间，因此有可能将导致将页交换内存不足与导致页交换的磁盘瓶颈混淆。

建议在测试过程中不是每项指标都要去监控收集还有采集时间也要根据被测对象当时测试场景设计情况去划分(结合软件性能测试生命周期各阶段实施过程介绍中第一章节介绍的场景去设计监控场景)，而且还要结合系统与应用软件的特性进行结合监控分析，才能更好的定位问题，如SQL Server与操作系统相关性，操作系统性能的好坏直接影响数据库的使用性能，如果操作系统存在问题，如cpu过载、过度内存交换、磁盘i/o瓶颈等，在这种情况下，单纯进行数据库内部性能调整是不会改善系统性能的。通过Windows NT的系统监视器(system monitor)来监控各种设备，发现性能瓶颈。如：数据库设计的好坏也直接影响系统资源的使用，如大量全表扫描检索数据最终导致CPU、I/O、内存、网络的使用。

以上只是简要介绍，如果有心研究的朋友可以多多结合学习数据库工作的机制原理，与操作系统之间的工作原理结合，就能更好的分析性能问题，当然离不开业务的分析和支持。当我们所测试的业务系统因为随着时间的流逝，数据量的增加而且业务数据最终是落地到磁盘中，最简单的某种业务的数据查询也是从磁盘中获取，因此磁盘是会被大量使用，然而磁盘的存取速度与内存和处理器相比要慢很多，如果在出现磁盘的争用可能显著的降低SQL SERVER的性能，因此对磁盘资源的使用瓶颈分析和解决能够显著地增进SQL SERVER性能，当然这是也要考虑数据库设计以及SQL写法等等--这些就是第三节介绍的《SQL SERVER 2008数据库服务性能监控分析优化方法》。

总之不是表示每次监控都是收集所有的各项指标来分析表示最好的。因为监控分析以及收集本身也是一个很大的性能开销，所以做为性能测试人员，我们要设计合理的性能监控数据收集，以最小化监控工具对系统的影响。