[转]检测SQLSERVER数据库CPU瓶颈及内存瓶颈

资源监控中，如果ProcessPrivate Bytes计数器和ProcessWorking Set计数器的值在长时间内持续升高，同时MemoryAvailable bytes计数器的值持续降低，则很可能存在内存泄漏。内存泄漏应该通过一个长时间的，用来研究分析当所有内存都耗尽时，应用程序反应情况的测试来检验。

 

 

 

CPU瓶颈问题

1、System\%Total processor time如果该值持续超过90%，且伴随处理器阻塞，则说明整个系统面临着处理器方面的瓶颈.

注：在某些多CPU系统中，该数据虽然本身并不大，但CPU之间的负载状况极不均衡，此时也应该视作系统产生了处理器方面的瓶颈.

2、排除内存因素，如果Processor %Processor Time计数器的值比较大，而同时网卡和硬盘的值比较低，那么可以确定CPU 瓶颈。（内存不足时，有点进程会转移到硬盘上去运行，造成性能急剧下降，而且一个缺少内存的系统常常表现出很高的CPU利用率，因为它需要不断的扫描内存，将内存中的页面移到硬盘上。）

造成高CPU使用率的原因：

频繁执行程序，复杂运算操作，消耗CPU严重

数据库查询语句复杂，大量的 where 子句，order by， group by 排序等，CPU容易出现瓶颈

内存不足，IO磁盘问题使得CPU的开销增加

 

CPU分析

【监控指标】：

System %Processor Time CPU，Processor %Processor Time CPU

Processor%user time 和Processor%Privileged Time

systemProcessor Queue Length

Context Switches/sec 和%Privileged Time

【参考值】：

System\%Total processor time不持续超过90%，如果服务器专用于SQL Server，可接受的最大上限是80-85% ，合理使用的范围在60%至70%。

Processor %Processor Time小于75%

systemProcessor Queue Length值，小于CPU数量的总数+1

磁盘I/O分析

【监控指标】：PhysicalDisk/%Disk time，PhysicalDisk/%Idle Time，Physical Disk Avg.Disk Queue Length， Disk sec/Transfer

【参考值】：%Disk Time建议阈值90%

Windows资源监控中，如果% Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。

Processor%Privileged Time该参数值一直很高，且如果在 Physical Disk 计数器中，只有%Disk time 比较大，其他值都比较适中，硬盘可能会是瓶颈。若几个值都比较大，那么硬盘不是瓶颈。若数值持续超过80%，则可能是内存泄露。如果 Physical Disk 计数器的值很高时该计数器的值（Processor%Privileged Time）也一直很高，则考虑使用速度更快或效率更高的磁盘子系统。

Disk sec/Transfer 一般来说，该数值小于15ms为最好，介于15-30ms之间为良好，30-60ms之间为可以接受，超过60ms则需要考虑更换硬盘或是硬盘的RAID方式了.

Average Transaciton Response Time（事务平均响应时间）随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势

Transactions per Second（每秒通过事务数/TPS）当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈

Hits per Second（每秒点击次数）通过对查看“每秒点击次数”，可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。

Throughput（吞吐率）可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。

Connections（连接数）当连接数到达稳定状态而事务响应时间迅速增大时，添加连接可以使性能得到极大提高（事务响应时间将降低）

Time to First Buffer Breakdown（Over Time）（第一次缓冲时间细分（随时间变化））可以使用该图确定场景或会话步骤运行期间服务器或网络出现问题的时间。

碰到过的性能问题：

• 1. 在高并发的情况下，产生的处理失败（比如：数据库连接池过低，服务器连接数超过上限，数据库锁控制考虑不足等）
• 2. 内存泄露（比如：在长时间运行下，内存没有正常释放，发生宕机等）
• 3. CPU使用偏离（比如：高并发导致CPU使用率过高）
• 4. 日志打印过多，服务器无硬盘空间

如何定位这些性能问题：

1. 查看系统日志，日志是定位问题的不二法宝，如果日志记录的全面，很容易通过日志发现问题。

比如，系统宕机时，系统日志打印了某方法执行时抛出out of memory的错误，我们就可以顺藤摸瓜，很快定位到导致内存溢出的问题在哪里。

2. 利用性能监控工具，比如：JAVA开发B/S结构的项目，可以通过JDK自带的Jconsole，或者JProfiler，来监控服务器性能，Jconsole可以远程监控服务器的CPU，内存，线程等状态，并绘制变化曲线图。

利用Spotlight可以监控数据库使用情况。

我们需要关注的性能点有：CPU负载，内存使用率，网络I/O等

3. 工具和日志只是手段，除此之外，还需要设计合理的性能测试场景

具体场景有：性能测试，负载测试，压力测试，稳定性测试，浪涌测试等

好的测试场景，能更加快速的发现瓶颈，定位瓶颈

4. 了解系统参数配置，可以进行后期的性能调优

除此以外，还想说个题外话，就是关于性能测试工具的使用问题

在刚开始用Loadrunner和JMeter的时候，做高并发测试时，都出现过没有把服务器压垮，这两个程序自己先倒下的情况。

如果遇到这个问题，可以通过远程调用多个客户端的服务，分散性能测试工具客户端的压力来解决。

说这个的目的是想说，做性能测试的时候，我们一定要确保瓶颈不要发生在我们自己的测试脚本和测试工具上

[转]检测SQLSERVER数据库CPU瓶颈及内存瓶颈

标签：jmeter   window   under   break   switch   strong   网卡   cut   启用