百独托管7500 紫田网络超高转化播放器收cps[推荐]速盾CDN 免实名免备防屏蔽阿里云 爆款特卖9.9元封顶提升alexa、IP流量7Q5团队
【腾讯云】中小企福利专场【腾讯云】多款产品1折起高防 随时退换 好耶数据小飞国外网赚带你月入万元炎黄网络4H4G10M 99每月
香港带宽CN2/美国站群优惠中客数据中心 服务器租用联盟系统移动广告平台 中易企业专场腾讯云服务器2.5折九九数据 工信部正规资质
腾讯云新用户大礼包代金券高价收cpa注册量高价展示【腾讯云】2核2G/9.93起租服务器找45互联 随时退换阿里云 短信服务 验证秒达

[Windows] 如何识别SQL Server中的IO瓶颈 [复制链接]
查看:955 | 回复:3

174

主题

380

帖子

224

积分

落伍者(一心一意)

Rank: 1

贡献
409
鲜花
0
注册时间
2012-7-14

落伍者QQ绑定落伍手机绑定

发表于 2013-1-5 22:31:09 | |阅读模式 来自 中国上海
  问题:

  我们可能经常会遇到SQLServer数据库频繁关闭的情况。在分析了内存和CPU使用情况后,我们需要继续调查根源是否在I/O.我们应该如何识别SQLServer是否有I/O相关的瓶颈?

  解决:

  当数据页经常从缓冲池中移进移出的时候,I/O子系统就会成为SQLServer性能问题的关键因素之一。事务日志和tempdb同样也会产生重大的I/O压力。因此,你必须确保你的I/O子系统能按照预期运行。否则你将会成为响应时间增长和频繁超时的受害者。在这篇文章中,将描述如何使用内置工具识别I/O相关瓶颈,并提供一些磁盘配置的方法:

  性能计数器(Performance Monitor):

  可以使用性能计数器来检查I/O子系统的负荷。下面的计数器可用于检查磁盘性能:

  PhysicalDisk Object:Avg.DiskQueue Length:计算从物理磁盘中的平均读和写的请求队列。过高的值代表磁盘操作处于等待状态。当这个值在SQLServer峰值时长期超过2,证明需要注意了。如果有多个硬盘,就需要把这些数值除以2.比如,有4个硬盘,且队列为10,那么平均值就是10/4=2.5,虽然也证明需要关注,但不能使用10这个值。

  Avg.Disk Sec/Read和Avg.Disk Sec/Write:显示从磁盘读或者写入磁盘的平均时间。10ms内是很好的表现,20以下还算能接受。高于此值证明存在问题。

  Physical Disk:%Disk Time:在磁盘忙于读或者写请求的时候持续时间的比率。根据拇指定律,此值应该小于50%.

  Disk Reads/Sec和Disk Writes/Sec计数器显示出在磁盘中读写操作的速率。这两个值应该小于磁盘能力的85%.当超过此值,磁盘的访问时间将以指数方式增长。

  可以通过以下方式来计算逐渐增长的负载的能力。一种方法是使用SQLIO.你应该找到吞吐量比较稳定,但缓慢增长。

  可以使用以下公式来计算RAID配置:

  Raid 0: I/O per disk = (reads + writes) / number ofdisks

  Raid 1: I/O per disk = [reads + (writes*2)] / 2

  Raid 5: I/O per disk = [reads + (writes*4)] / number of disks

  Raid 10: I/O per disk = [reads + (writes*2)] / number of disks

  比如:对于RAID 1,如果得到下面的计数器:

  Disk Reads/sec = 90

  Disk Writes/sec =75

  根据公式:[reads + (writes*2)] / 2 or [90 + (75*2)] / 2 = 120I/Os每个磁盘。

  动态管理视图(DMVs):

  有很多游泳的DMVs可以用于检查I/O瓶颈:

  当一个页面被用于读或者写访问且页面在缓冲池中不存在或不可用时,会引发一个I/O闩锁等待(I/O latch),它会在PAGEIOLATCH_EX/PAGEIOLATCH_SH(具体根据请求类型而定)。这些等待表明一个I/O瓶颈。可以使用sys.dm_os_wait_stats找到闩锁等待的信息。如果你保存了SQLServer正常运行下的waiting_task_counts和wait_time_ms值,并且于此次的值做对比,可以识别出I/O问题:

  select *

  fromsys.dm_os_wait_stats

  where wait_type like'PAGEIOLATCH%'

  order by wait_typeasc

  挂起的I/O请求可以在下面查询中查到,并且用于识别那个磁盘负责的这个瓶颈:

  select database_id,

  file_id,

  io_stall,

  io_pending_ms_ticks,

  scheduler_address

  from sys.dm_io_virtual_file_stats(NULL, NULL) iovfs,

  sys.dm_io_pending_io_requests as iopior

  where iovfs.file_handle = iopior.io_handle

  磁盘碎片(Disk Fragmentation):

  建议你检查磁盘碎片和配置用于SQLServer实例的磁盘。在NTFS文件系统中的碎片会产生严重的性能影响。磁盘需要经常整理碎片并且指定整理碎片计划。研究表明,一些情况下SAN在整理碎片后性能更差。因此,SAN必须根据实际情况对待。

  NTFS上的索引碎片同样能引起高I/O好用。但是这和在SANs中的效果是不一样的。

  磁盘配置/最佳实践:

  常规情况,你应该把日志文件和数据文件分开存放以获得更好的性能。对于重负载的数据文件(包括tempdb)的I/O特性是随机读取。对于日志文件,是顺序访问的,除非事务需要回滚。

  对于内置磁盘仅仅可以用于数据库日志文件,因为它们对顺序I/O有很好的性能,但是对随机I/O性能低下。

  数据库的数据和日志文件应该放在对应专用的磁盘中。确保良好的性能。建议日志文件放在两个内置磁盘,并配置为RAID 1.数据文件驻留在仅用于给SQLServer访问的SAN系统中,并只被查询和报表控制。特殊访问应该被禁止。

  写缓冲在可能的情况下应该被允许,并保证断电也能使用。

  为了尽可能保证对于OLTP系统的I/O瓶颈影响最小化,不应该把OLAP和OLTP环境混合。并且保证你的代码优化及有合适的索引来避免不必要的I/O.

41

主题

1225

帖子

284

积分

落伍者(一心一意)

Rank: 1

贡献
850
鲜花
2
注册时间
2006-6-22

落伍者

发表于 2013-1-6 19:34:28 | 来自 中国湖北十堰
数据库的数据和日志文件应该放在对应专用的磁盘中。确保良好的性能。建议日志文件放在两个内置磁盘,并配置为RAID 1.数据文件驻留在仅用于给SQLServer访问的SAN系统中,并只被查询和报表控制。特殊访问应该被禁止。

153

主题

904

帖子

156

积分

落伍者(一心一意)

Rank: 1

贡献
0
鲜花
0
注册时间
2010-6-4

QQ绑定

发表于 2013-1-8 16:35:34 | 来自 中国北京
顶帖是好事,千万莫灌水!
论坛客服/商务合作/投诉举报:2171544 (QQ)
落伍者创建于2001/03/14,本站内容均为会员发表,并不代表落伍立场!
拒绝任何人以任何形式在本论坛发表与中华人民共和国法律相抵触的言论!
落伍官方微信:2030286 邮箱:(djfsys@gmail.com|tech@im286.com)
© 2001-2014

浙公网安备 33060302000191号

浙ICP备11034705号 BBS专项电子公告通信管[2010]226号

  落伍法律顾问: ITlaw-庄毅雄

手机版|找回帐号|不能发帖?|Archiver|落伍者

GMT+8, 2024-6-1 11:47 , Processed in 0.111713 second(s), 37 queries , Gzip On.

返回顶部