昨天终于看到了MSSQL接近真正优化的东西，总结一下：
工作负荷的监视：
1、系统负载突然很大程度的偏离基线有如下原因：
（1）统计信息更改和有用索引的删除；
（2）锁粒度的变化；
（3）“无赖”会话；
（4）工作负载变化；
（5）正常的业务和相关负荷的增长；
（6）mssql升级；
（7）硬件资源极限；
2、探测、隔离和解决常见性能问题：主要涉及cpu、memory、I/O、tempdb、blocking：
（1）cpu:工作者（worker）用来完成用户和系统内部任务，它一般处于三个状态：
running:正在CPU上；
runnable:在CPU队列上等待；
suspended:等待其他资源；
探测：
你可以通过系统性能监视器的计数器：Processor:% Processor Time(所有CPU平均值)来诊断CPU瓶颈，如果该计数器15-20分钟内持续高于80%，说明该系统CPU资源紧张；
你也可以通过性能监视器的计数器：System:Processor Queue Length(估计所有CPU平均值)来确定CPU瓶颈，如果该计数器持续高于2，那么说明该系统CPUT紧张，这里，需要说明一点，对多CPU或多核CPU来说，个人感觉应该该值/系统cpu数；
同时，你也可以通过性能监视器的计数器：Process:%Processor Time(进程所有线程处理时间总和)来确定MSSQL使用CPU的比例，前提是如果系统上只有MSSQL应用，除了进程花费CPU资源，我想还有系统的吧。如果系统上还有其他应用，那么就不能确定MSSQL到底用了系统的CPU资源的比例，那么只能通过自己设置的基线来进行对比了。
当然，你也可以通过DMVS来获取工作者数目（workers）来探测CPU的负载状况：
SELECT COUNT(*) AS workers_waiting_for_cpu, t2.Scheduler_idFROM sys.dm_os_workers AS t1, sys.dm_os_schedulers AS t2WHERE t1.state = 'RUNNABLE' AND t1.scheduler_address = t2.scheduler_address AND t2.scheduler_id < 255GROUP BY t2.scheduler_id
也可以通过获取workers处于runnale状态的时间来确定CPU负载：
SELECT SUM(signal_wait_time_ms)FROM sys.dm_os_wait_stats

ITPub博客

mssql优化学习笔记之三

最新文章