CPU 内存检测

 在任务管理器中看到sql server 2000进程的内存占用，而在sql server 2005中，不能在任务管理器中查看sql server 2005进程的内存占用，要用

如下语句查看sql server 的实际内存占用：

select * from sysperfinfo where counter_name like '%Memory%'

其中, Total Server Memory 表示内存占用。

 

select locked_page_allocations_kb  from sys.dm_os_process_memory
Select sum(awe_allocated_kb)  as [AWE allocated, kb] From sys.dm_os_memory_clerks

 

要适当限制sql server 的内存占用，要给sql server设置最大值，不要把物理内存所有给sql server，要给windows系统保留适当大小的内存。

对于大物理内存，要在windows server 2003系统的boot.ini中增长 /PAE 参数，若是是AMD的CPU，还要加 /usepmtimere 参数，要在本地组策略里设置“锁定内存中的页”，在sql erver 2005 中选中AWE,并设置最小值和最大值， 重启服务器或sql server服务便可，详细请参考windows server 2003和sql server 2005中的“启用对4GB以上物理内存的支持”的帮助文档。

 

 

 

1、sql 数据库CPU瓶颈

对于SQL Server的一个工做进程的状态有不少，主要状态有运行中（RUNNING)、可运行（RUNNABLE)和挂起(SUSPENED)3种。

经过查看系统监视计数器Processor:% Processor Time，能够肯定CPU瓶颈。若是这个计数器的值很高。好比持续15-20分钟超80%，就意味着CPU出现了瓶颈。

 

当您怀疑计算机硬件是影响SQL Server运行性能的主要缘由时，能够经过SQL Server Performance Monitor监视相应硬件的负载，以证明您的猜想并找出系统瓶颈。下文将介绍一些经常使用的分析对象及其参数。

　　Memory: Page Faults / sec

　　若是该值偶尔走高，代表当时有线程竞争内存。若是持续很高，则内存多是瓶颈。

　　Process: Working Set

　　SQL Server的该参数应该很是接近分配给SQL Server的内存值。在SQL Server设定中，若是将"set working set size"置为0, 则Windows NT会决定SQL Server的工做集的大小。若是将"set working set size"置为1，则强制工做集大小为SQLServer的分配内存大小。通常状况下，最好不要改变"set working set size"的缺省值。

　　Process:%Processor Time

　　若是该参数值持续超过95%，代表瓶颈是CPU。能够考虑增长一个处理器或换一个更快的处理器。

　　Processor:%Privileged Time

　　若是该参数值和"Physical Disk"参数值一直很高，代表I/O有问题。可考虑更换更快的硬盘系统。另外设置Tempdb in RAM，减低"max async IO"，"max lazy writer IO"等措施都会下降该值。

　　Processor:%User Time

　　表示耗费CPU的数据库操做，如排序，执行aggregate functions等。若是该值很高，可考虑增长索引，尽可能使用简单的表联接，水平分割大表格等方法来下降该值。

　　Physical Disk:Avg.Disk Queue Length

　　该值应不超过磁盘数的1.5~2倍。要提升性能，可增长磁盘。

　　注意:一个Raid Disk实际有多个磁盘。

　　SQLServer:Cache Hit Ratio

　　该值越高越好。若是持续低于80%，应考虑增长内存。 注意该参数值是从SQL Server启动后，就一直累加记数，因此运行通过一段时间后，该值将不能反映系统当前值。

检测CPU压力的另外一个方法是计算可运行状态下的工做进程数量，经过执行以下的DMV查询能够获得这个信息：

SELECT COUNT(*) AS workers_waiting_for_cpu, t2.Scheduler_id

FROM sys.dm_os_workers AS t1, sys.dm_os_schedulers AS t2

WHERE t1.state = 'RUNNABLE' AND t1.scheduler_address=t2.scheduler_address

AND t2.scheduler_id < 255

GROUP BY t2.scheduler_id

也能够执行以下的查询获得工做进程在可运行状态下花费的时间：

SELECT SUM(signal_wait_time_ms) FROM sys.dm_os_wait_stats

下面查询是找出每次执行占用CPU最多的前100位查询：

SELECT TOP 100 total_worker_time/execution_count AS avg_cpu_cost, plan_handle, execution_count,

(SELECT SUBSTRING(text, statement_start_offset/2+1,

(CASE WHEN statement_end_offset = -1 THEN LEN(CONVERT(nvarchar(max), text)) * 2

ELSE statement_end_offset END - statement_end_offset)/2)

FROM sys.dm_exec_sql_text(sql_handle)) AS query_text

FROM sys.dm_exec_query_stats

ORDER BY avg_cpu_cost DESC

稍作修改，找出运行最频繁的查询：

SELECT TOP 100 total_worker_time/execution_countASavg_cpu_cost, plan_handle, execution_count,

(SELECT SUBSTRING(text,statement_start_offset/2+1,

(CASE WHEN statement_end_offset = -1 THEN LEN(CONVERT(nvarchar(max), text)) * 2

ELSE statement_end_offset END - statement_end_offset)/2)

FROM sys.dm_exec_sql_text(sql_handle)) AS query_text

FROM sys.dm_exec_query_stats

ORDER BY execution_count DESC

可使用下列系统监视性能计数器查看编译和重编译的速度：

1. SQLServer: SQL Statistics: BatchRequests/Sec（每秒批处理请求数）

2. SQLServer: SQL Statistics: SQLCompilations/Sec（每秒SQL编译次数）

3. SQLServer: SQL Statistics: SQLRecompilations/Sec（每秒SQL重编译次数）

还能够经过下面语句获得SQLServer在优化查询计划上花费的时间：

SELECT * FROM sys.dm_exec_query_optimizer_info

WHERE counter='optimizations' OR counter = 'elapsed time'

下面查询找到被编译得最多的前10位查询计划：

SELECT TOP 10 plan_generation_num, execution_count,

(SELECT SUBSTRING(text, statement_start_offset/2+1,

(CASE WHEN statement_end_offset = -1 THEN LEN(CONVERT(nvarchar(max), text)) * 2

ELSE statement_end_offsetEND-statement_end_offset)/2)

FROM sys.dm_exec_sql_text(sql_handle))ASquery_text

FROM sys.dm_exec_query_stats

WHERE plan_generation_num> 1

ORDER BY plan_generation_num DESC

 

2、sql 数据库内存瓶颈

内存有压力时，一个查询计划可能得移出内存。若是这个计划被再次提交执行，就必须再优化一次，而因为查询优化是CPU密集型运算，这就会给CPU带来压力。一样，内存有压力时，数据库页面可能须要被移出缓冲区池。若是这些页面很快就再次被选中，就会致使更多的物理IO。

一般所说的内存指的是服务器上的可用物理内存（既RAM）。还有另一种内存叫作虚拟地址空间（VAS）或虚拟内存。在Windows系统上，全部位应用程序都有一个GB的进程地址空间，用来获取最大GB的物理内存。在GB的可用内存以外，进程还能够在用户模式下获得GB的VAS，另外GB保留只能经过内核模式获取。要想更改这个配置，能够在boot.ini文件中使用/3GB switch。

常见的操做系统机制是页面调试，它使用一个交换文件来存储最近未使用的部分进程内存。当这一内存被再次引用时，它就直接从交换文件中读取（或调入）物理内存。

 

能够经过性能计数器，监测下面参数：

1. 内存：可用字节（Available Bytes）

2. SQL Server:缓冲管理器：缓存命中率（Buffer Cache Hit Ratio）指的是那些不用经过磁盘读取而直接在缓冲区池中找到的页的比例。对于大多数产品工做负荷而言，这个值应该是多。（应该是越大越好）

3. SQL Server:缓冲管理器：页平均寿命（Page Life Expectancy）指的是一个没有被引用的页在缓冲区池中保留的秒数。若是数值较低，则说明缓冲区池遇到了内存不足的状况。

4. SQL Server:缓冲管理器：检查点页/秒（Checkpoint Pages/Sec）指的是被检查点刷新的页数，或者要求全部脏页被刷新的其它操做的数目。它能显示工做负荷中增长的缓冲区池活动量。

5. SQL Server:缓冲管理器：延迟写入/秒（Lazywrites/Sec）指的是缓冲管理器的延迟写入器写入的缓冲数目，它的做用相似于前面提到的检查点页/秒。

 

怀疑内存不足时：

方法1：

【监控指标】：Memory Available MBytes ，Memory的Pages/sec， page read/sec， Page Faults/sec

【参考值】：

若是 Page Reads/Sec 比率持续保持为 5，表示可能内存不足。

Page/sec 推荐00-20（若是服务器没有足够的内存处理其工做负荷，此数值将一直很高。若是大于80，表示有问题）。

方法2：根据Physical Disk 值分析性能瓶颈

【监控指标】：Memory Available MBytes ，Pages read/sec，%Disk Time 和 Avg.Disk Queue Length

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

当内存不足时，有点进程会转移到硬盘上去运行，形成性能急剧降低，并且一个缺乏内存的系统经常表现出很高的CPU利用率，由于它须要不断的扫描内存，将内存中的页面移到硬盘上。

怀疑内存泄漏时

【监控指标】：Memory Available MBytes ，Process\Private Bytes和Process\Working Set，PhysicalDisk/%Disk Time

【说明】：

Windows资源监控中，若是Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高，同时Memory\Available bytes计数器的值持续下降，则极可能存在内存泄漏。内存泄漏应该经过一个长时间的，用来研究分析当全部内存都耗尽时，应用程序反应状况的测试来检验。

 

 

 

CPU瓶颈问题

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

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

二、排除内存因素，若是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

system\Processor Queue Length

Context Switches/sec 和%Privileged Time

【参考值】：

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

Processor %Processor Time小于75%

system\Processor 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的时候，作高并发测试时，都出现过没有把服务器压垮，这两个程序本身先倒下的状况。

若是遇到这个问题，能够经过远程调用多个客户端的服务，分散性能测试工具客户端的压力来解决。

说这个的目的是想说，作性能测试的时候，咱们必定要确保瓶颈不要发生在咱们本身的测试脚本和测试工具上