这与我自己的帖子有关
SQL服务器每天早上8:30启动,晚上9:30左右停止。(所以等待时间每天都会重置),大约60名用户将同时使用SQL服务器(直接用于修改数据,也用于我们办公室使用的后端数据库),服务器有8 GB内存。对于大多数数据库,每小时都会进行日志备份。(备份由我们自己的备份工具完成,该工具自动执行SQL备份)
正如在这个文章中所描述的,我使用了下面的查询。
select *
from sys.dm_os_wait_stats
WHERE [wait_type] NOT IN (
N'CLR_SEMAPHORE', N'LAZYWRITER_SLEEP',
N'RESOURCE_QUEUE', N'SQLTRACE_BUFFER_FLUSH',
N'SLEEP_TASK', N'SLEEP_SYSTEMTASK',
N'WAITFOR', N'HADR_FILESTREAM_IOMGR_IOCOMPLETION',
N'CHECKPOINT_QUEUE', N'REQUEST_FOR_DEADLOCK_SEARCH',
N'XE_TIMER_EVENT', N'XE_DISPATCHER_JOIN',
N'LOGMGR_QUEUE', N'FT_IFTS_SCHEDULER_IDLE_WAIT',
N'BROKER_TASK_STOP', N'CLR_MANUAL_EVENT',
N'CLR_AUTO_EVENT', N'DISPATCHER_QUEUE_SEMAPHORE',
N'TRACEWRITE', N'XE_DISPATCHER_WAIT',
N'BROKER_TO_FLUSH', N'BROKER_EVENTHANDLER',
N'FT_IFTSHC_MUTEX', N'SQLTRACE_INCREMENTAL_FLUSH_SLEEP',
N'DIRTY_PAGE_POLL', N'SP_SERVER_DIAGNOSTICS_SLEEP')
order by wait_time_ms desc; 结果如下所示(仅显示前25行)

现在,在得到这个结果之后,我很困惑这些值是真的很高还是正常的情况。(我还使用了与SQL相关的性能计数器值,但无法使用它排除故障,因为大多数文章只描述要使用的性能计数器,而不是正确地分析它,或者很难找到服务器的性能)那么这些性能计数器的理想值是什么?我的sql服务器中是否存在性能问题?怎么决定?
发布于 2014-06-28 22:43:00
您应该考虑的不仅仅是wait_time_ms或waiting_tasks_count的绝对值,您还应该查看平均等待时间。当您查看一个平均等待,您应该问自己:“这是一个合理的时间等待这个资源吗?”
例如(如果我做的是正确的),您的PAGEIOLATCH等待在4-5ms的范围内。这是“很好”-因为这是一个硬盘的响应时间,以获取一个I/O请求。但是,如果您在SSD上运行(预计此值将停留在1ms范围内),那么它是“坏的”。
另一个例子是,您的WRITELOG等待时间超过10 is。这是“不好的”,因为如果您执行顺序I/O正确,这个值(即使是旋转锈蚀)应该在1ms范围内。
然而,所有这一切都必须从你正在努力实现的目标的角度来看待。如果您希望“使事情变得更快”(并非罕见的请求),您需要首先查看最大的等待(通过wait_time_ms),因为它们最有可能对您造成伤害。如果您的调优更有针对性,请查看特定的等待类型,即使它们在列表中处于较低的位置。
例如,平均70毫秒有几个LCK_M_S等待。它们看起来并不重要,因为它们太少了。但也许它们会影响到一些重要的用户。如果这是一个OLTP系统,查询应该快速进入和输出--70 is是一个“坏”数字(因为短时间运行的事务中的锁应该只保留几毫秒,甚至微秒)。
另一个例子:如果您试图使DML查询速度更快,您将希望以WRITELOG和PAGEIOLATCH_EX等待为目标。如果您正在优化读取,您将更多地关注于减少PAGEIOLATCH_SH等待(例如使用SSD或RAM)或使数据库减少读取I/O (例如,通过优化索引)。
发布于 2014-07-06 19:04:30
我注意到在您的结果集中没有CXPACKET等待。您是否禁用了并行性,如果是的话,为什么?如果你看一下你的MAXDOP设置,我猜它会被设置为1。在某些情况下,这是可以的,但它们很少。我将在此框上启用并行性,并调整您的工作负载。我可能会在这里倒序。调优,然后启用并行。
此外,我看到BACKUPBUFFER和BACKUPIO,您是否使用第三方工具完成备份?您的备份是否被运行到网络共享?
一瞥我就和亚伦在一起了。你的IO子系统有严重问题。
https://dba.stackexchange.com/questions/68109
复制相似问题