惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

月光博客
月光博客
罗磊的独立博客
The GitHub Blog
The GitHub Blog
V
V2EX
Last Week in AI
Last Week in AI
博客园 - 聂微东
MyScale Blog
MyScale Blog
美团技术团队
L
LangChain Blog
博客园 - Franky
腾讯CDC
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
博客园_首页
S
SegmentFault 最新的问题
爱范儿
爱范儿
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
Stack Overflow Blog
Stack Overflow Blog
量子位
小众软件
小众软件
宝玉的分享
宝玉的分享
J
Java Code Geeks
Google DeepMind News
Google DeepMind News
D
Docker
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报

博客园 - ideas

从 datetime2 数据类型到 datetime 数据类型的转换产生一个超出范围的值。 移除google搜索结果中烦人的URL跟踪跳转 关于分页存储过程的优化【让数据库按我们的意思执行查询计划】 DiscuzNT首页版块提取优化 中国娱乐网招聘asp.net软件工程师 几个有用的DMV查询 【转】Iframe高度自适应(兼容IE/Firefox、同域/跨域) 【转】MAQETTA: 基于HTML5的开源可视化界面设计工具 高效能人士的七个习惯 有《基于行块分布函数的通用网页正文抽取》想到的 MongoDB 学习笔记—MapReduce MongoDB系列文章推荐 【转】linux screen 命令详解 - [linux] 关于添加索引视图后的数据存储区别 索引视图 添加计算列,并创建索引 浏览器的加载与页面性能优化【转】 内存瓶颈 Windows Live Writer 插件 Source Code Plug-in
IO瓶颈
ideas · 2011-02-11 · via 博客园 - ideas

下列系统监视计数器来检测物理磁盘级IO瓶颈:

  1. 物理磁盘对象:磁盘队列平均长度(Avg.Disk Queue Length) 指的是抽样间隔内所选中的物理磁盘上排除等待的物理读/写请求的平均数据。如果IO系统超负荷了,更多的读/写操作就会陷入等待。如果每个物理磁盘的磁盘队列长度总是超过SQL Server巅峰使用期时的数值2,那么很可能就出现了IO瓶颈。
  2. 物理磁盘对象:磁盘每次读/写平均用时(Avg.Disk Sec/Read(write)) 指的是每次从磁盘中读取或写入数据时的平均用时(以秒计)。通用指标如下:
    1. 小10ms,非常好;
    2. 10ms-20ms之间,还过得去;
    3. 20ms-50ms之间,很慢需要多加注意;
    4. 大于50ms则被认为是严重的IO瓶颈。
  3. 物理磁盘对象:磁盘每秒读/写数(Disk Reads(Writes)/Sec) 指的是磁盘上读/写操作的速度。一定要确保该数字小于磁盘容量的85%。当超过磁盘容量的85%时,磁盘访问时间将呈指数级增长。

下面DMV查询可以用来确认文件级的IO性能信息:

SELECT database_id, DB_NAME(database_id), file_id, io_stall_read_ms, io_stall_write_ms
FROM sys.dm_io_virtual_file_stats(NULL, NULL)

io_stall_read_ms 和 io_stall_write_ms这两列表示的是SQL Server启动后等待向文件发出读和写指令的时间。为了获取有意义的数据,需要在短时间内对这些数据进行快照。然后将它们同基线数据相比较。

还可以通过检查等待锁来确认全部的IO瓶颈。最重要的等待锁是PAGEIOLATCH 和 PAGEIOLATCH_EX。当一个任务在锁存器上等待一个IO请求中的缓冲区时,这两种等待锁就会启动。

SELECT wait_type, waiting_tasks_count, wait_time_ms, signal_wait_time_ms
FROM sys.dm_os_wait_stats
WHERE wait_type LIKE 'PAGEIOLATCH%'
ORDER BY wait_type

wait_time_ms 列包括一个工作进程在悬挂状态下花费的时间和在可运行状态下花费的时间,而 singnal_wait_time_ms 表示的只是一个工作进程在可运行状态下花费的时间。因此,这两者(wait_time_ms – signal_wait_time_ms)的差别实际上代表了等待IO完成所花的时间。上面查询返回的是SQL Server启动后的等待。要想获得有意义的数据,同样需要在短时间内对这些数据进行快照,然后对比。

IO瓶颈的隔离和排查,下面DMV查询返回引发IO最多的前10位查询或批处理。

SELECT TOP 10
      (total_logical_reads/execution_count) AS avg_logical_reads,
      (total_logical_writes/execution_count) AS avg_logical_writes,
      (total_physical_reads/execution_count) AS avg_physical_reads,
      execution_count,
      (SELECT SUBSTRING(text, statement_start_offset/2+1,
            (CASE WHEN statement_end_offset = -1 THENLEN(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 (total_logical_reads + total_logical_writes) DESC

在许多可以通过减少基IO数目以改进查询性能的方法中,首先应该检查有用的索引有没有丢失。下面DMV查询就可以用来确认丢失的索引及它们的有用性:

SELECT t1.object_id,t2.user_seeks, 52.user_scans, t1.equality_columns,t1.inequality_columns
FROM sys.dm_db_missing_index_details AS t1,sys.dm_db_missing_index_group_stats AS t2, sys.dm_db_missing_index_groupsAS t3
WHERE database_id = DB_ID() AND object_id = OBJECT_ID('tablename') ANDt1.index_handle = t3.index_handle AND t2.group_handle =t3.index_group_handle