1. 首页
  2. IT资讯

mssql优化学习笔记之三

昨天终于看到了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博客 ” ,链接:http://blog.itpub.net/8484829/viewspace-605587/,如需转载,请注明出处,否则将追究法律责任。

主题测试文章,只做测试使用。发布者:深沉的少年,转转请注明出处:http://www.cxybcw.com/184804.html

联系我们

13687733322

在线咨询:点击这里给我发消息

邮件:1877088071@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息

QR code