https://www.modb.pro/db/43710

几年前一个客户的Oracle数据库经常HANG,老白帮他分析了一下,结论是存储老化,性能不足以支撑现有业务了。正好用户手头有个华为S5600T正好从核心系统中换下来放着没用,就把这个存储换上去了。换了新存储后,系统总体确实有所改善。数据库不会动不动就HANG住,不会出现系统HANG的问题了,但是还是觉得比较慢。出问题时候的AWR报告的片段如下:

从负载上看,每秒的REDO SIZE 37M,还是很高的。逻辑读的数量不大,不过BLOCK CHANGES很高,物理写高达1万+,超过80M/秒,系统的写压力比较大。从这个系统上看,应该是存在大批量的数据写入操作。接下来看看命中率的情况:

命中率情况还是不错的,因为主要是写操作,因此DB CACHE的命中率也不高,从上面的LOAD PROFILE看,物理读实际上也不大,每秒不到20M。再来看看TOP EVENT:

可以看出,读写操作的平均延时超过50毫秒,肯定是存在性能问题的。从AWR数据上看,很明显,本系统是一个写IO很大的系统,每秒REDO的量达到了 36M/秒以上,每秒的物理写超过1万,这在普通的Oracle数据库系统中是比较少见的。从主要等待事件上看,也主要集中在IO上,从WAIT CLASS分类看,USER I/O也排在第一位,平均等待时间为59MS,SYSTEMI/O的平均等待也达到40MS,从这些指标上看IO是明显存在问题的。

既然IO存在明显的问题,那么我们就需要马上采集下操作系统IO的情况:

APE:/ # sar -d 3 2AIX APE 3 5 00CD36454C00

System configuration: lcpu=32 drives=111 mode=Capped

14:52:11 device %busy avque r+w/s Kbs/s avwait avserv

14:52:14

hdisk44    49 0.0     85   4096  10.0   6.0

hdisk43    65 0.1    138   7329  15.2   4.6

hdisk39    99 0.2    149   8589  40.6   6.7

hdisk38    30 0.8    303   3081  86.5  1.0

hdisk40    99 0.5    210  11196 60.9   4.7

hdisk42    99 0.9    346  13998  76.2    2.9

从上述指标上看,IOPS和吞吐量都不算太高,但是平均响应时间(avwait+avserv)确实很高,达到几十毫秒。这和AWR报告看到的数据是吻合的。于是找存储工程师参与分析。存储管理员认为存储没问题,负载很轻,从存储监控上看到的响应时间也很正常,在几个毫秒。这恐怕是DBA经常遇到的问题了,到底是存储工程师在推诿呢还是实际情况就是这样的,存储没问题,但是OS层面表现出慢呢?对于sar的数据,很多DBA总是先去看busy%这个指标,一看很多盘都已经是99% busy了,那可不得了了,存储出现瓶颈了。实际上对于现在的系统而言,busy%这个指标的可参考性并不大,后面的指标更能看出问题。Avque指的是平均队列的长度,有多少IO在队列中等待。再后面一列是IOPS,再后面是吞吐量,最后两列一列是平均等待时间,也就是在队列中等待IO的时间,和平均服务时间,也就是IO请求发出后,从后端返回的时间。我们通过这些指标实际上是可以区分IO等待是在前端系统端还是后端存储端的。AVSERV是存储到OS之间的端到端服务时间,从上面的指标上看,确实也不大,只有几个毫秒,所以说存储工程师的说法可能是对的,存储端并不慢。而avwait是IO在前端的等待时间,这个指标是相当高的,这说明很可能IO并没有下到存储上,而是在前端OS层面出现了等待。对于AIX系统而言,这个等待很大可能是和QUEUE_DEPTH参数设置不当有关的。为了进一步确认是否QUEUE_DEPTH不足引起了问题,在AIX系统上,可以用iostat–D去分析:

APE:/ # iostat -D

System configuration: lcpu=32 drives=111 paths=4 vdisks=0

hdisk44 xfer: %tm_act  bps   tps  bread bwrtn

21.9  4.1M 160.3   2.1M  2.0M

read:  rps  avgserv  minserv maxserv timeouts fails

28.8   5.6         0.1   1.2S       0    0

write: wps avgserv minserv maxserv timeouts fails

131.5   0.4     0.2    1.7S     0      0

queue: avgtime mintime maxtime avgwqsz avgsqsz sqfull

68.1    0.0    9.2S    12.0     0.0 160.3

AIX系统的iostat -D是一个十分强大的IO性能分析工具。我们从read这行开始看,平均每秒28.8次读,平均存储上返回的服务时间是5.6毫秒,最小是0.1毫秒,最大1.2秒,没有超时和错误(如果这两列有值,就要十分关注了)。再来看write,平均每秒131.5,平均存储的服务响应时间是0.4毫秒,这个值为什么比读的平均值小这么多呢?大家印象里的写的成本要远大于读。实际上这是存储系统的特点,因为读数据的时候有可能命中在CACHE里,也有可能需要从物理磁盘上去读,所以根据命中率不同以及物理盘的性能不同,肯定都会比直接从CACHE中读要慢一些,而写入操作,只要写缓存没有满,那么些IO的延时基本上等同于CACHE的写IO延时,这是十分快的。大家可以关注最后一行的指标,是IO在队列里的延时情况,平均是68.1毫秒!!!最小是0毫秒,这个应该是不需要排队直接从后端存储获取数据或者写入数据了,最大高达9.2秒,平均队列的深度12。大家关注下最后一个指标:sqfull的指标值,这是设备的缓冲队列满的次数(累计值),如果这个指标大于0,说明QUEUE_DEPTH参数的设置是不足的,出现了大量IO队列满的情况。从上述数据我们可以比较肯定队列等待可能是问题的主要原因了。下面我们来看看实际上HDISK的设置是什么样的:

APE:/ # lsattr -El hdisk44

clr_q no Device CLEARS its Queue on error True

location Location Label True

lun_id 0x4000000000000 Logical Unit Number ID

False

max_transfer 0x40000 Maximum TRANSFER Size

True

node_name 0x2100f84abf591cca FC Node Name

False

pvid 00cd36456aecb23e0000000000000000 Physical volume identifier

False

q_err yes Use QERR bit

True

q_type simple Queuing TYPE

True

queue_depth 1 Queue DEPTH

True

reassign_to 120 REASSIGN time out value

True

rw_timeout 30 READ/WRITE time out value

True

scsi_id 0xe0 SCSI ID

False

start_timeout 60 START unit time out valueTrue

ww_name 0x2008f84abf591cca FC World Wide Name

False

什么?QUEUE_DEPTH居然是1?其实也没啥大惊小怪的,在AIX系统下,华为存储的缺省QUEUE_DEPTH就是1,HDS存储的缺省值是2,而IBM自己的存储的缺省值是8,也不知道是不是IBM在故意恶心友商。存储工程师并没有帮助用户设置合理的值。那么这个参数设置为多少合适呢?根据老白的经验,如果跑Oracle这个参数至少设置为8,高负载的系统可以设置为更大的值,甚至32或者更高(LINUX上缺省是128),不过也不是越高越好,要看你的存储的能力,如果这个参数很大,存储没那么强的能力,也是没用的,需要一个匹配。既然发现了问题,那么果断的将参数调整为24,我们来看看优化后的效果,将QUEUE_DEPTH加大到24,再看AWR数据:

 

看上去IO的性能是不是好了很多,REDO量也上去了,从每秒37M提高到57M左右。其实这时候IO还是有问题,现在压力下放到存储上,存储上看到明显的性能问题了。下面可以进一步优化,比如QUEUE DEPTH是不是还可以再加大。另外数据能否存放到更多的盘上。给客户的建议是再多分配2-3个RAID 组,把部分数据分散到多个RAID 组上。实际上队列深度以前一直是困扰小型机上IO性能的一个问题。这个参数设置太小会有排队问题,设置太大也并不一定好,如果你的后端存储能力不足,而设置的队列深度太大,最终整体IO性能也不见得好。LINUX上,队列深度缺省是128,通过LINUX的调度策略来智能化调度,因此这个问题在LINUX上不多见。不过如果后端存储是高端的全闪存阵列,那么128的队列深度还是不能发挥出后端存储的能力的,这时候我们还是需要调整队列深度的。

[转帖]队列深度对IO性能的影响的更多相关文章

  1. IO队列深度max_queue_depth对系统性能的影响

    前段时间,发生了一个问题引起了我对IO队列深度的研究. 存储服务器中linux kernel的mpt2sas驱动模块,将max_queue_depth设置为1024时,引起系统加载驱动时卡死,而调整为 ...

  2. Performance Monitor4:监控SQL Server的IO性能

    SQL Server的IO性能受到物理Disk的IO延迟和SQL Server内部执行的IO操作的影响.在监控Disk性能时,最主要的度量值(metric)是IO延迟,IO延迟是指从Applicati ...

  3. 条带深度 队列深度 NCQ IOPS

    http://blog.csdn.net/striping/article/details/17449653 IOPS 即I/O per second,即每秒进行读写(I/O)操作的次数,多用于数据库 ...

  4. iometer测试磁盘IO性能

    of Outstanding I/Os per target – 被选中worker的每个磁盘一次所允许的未处理的异步I/O的数量.模拟测试多个应用向 IO 请求读写,默认是 1.通常不用这个参数,除 ...

  5. Linux的IO性能监控工具iostat详解

    Linux系统出现了性能问题,一般我们可以通过top.iostat.free.vmstat等命令来查看初步定位问题.其中iostat可以提供更丰富的IO性能状态数据. . 基本使用 $iostat - ...

  6. Centos硬盘IO性能检测命令iostat[转]

    Centos硬盘IO性能检测命令iostat[转] 在Linux下频繁存取文件后,物理内存会很快被用光,当程序结束后,内存不会被正常释放,而是一直作为caching.这个问题,貌似有不少人在问,不过都 ...

  7. Linux如何查看与测试磁盘IO性能

    1. 查看磁盘 IO 性能 1.1 top 命令 top 命令通过查看 CPU 的 wa% 值来判断当前磁盘 IO 性能,如果这个数值过大,很可能是磁盘 IO 太高了,当然也可能是其他原因,例如网络 ...

  8. Linux IO性能分析blktrace/blk跟踪器

    关键词:blktrace.blk tracer.blkparse.block traceevents.BIO. 本章只做一个记录,关于优化Block层IO性能方法工具. 对Block层没有详细分析,对 ...

  9. 通过iostat来查看linux硬盘IO性能|实例分析

    iostat查看linux硬盘IO性能 rrqm/s: 每秒进行 merge 的读操作数目.即 delta(rmerge)/s wrqm/s: 每秒进行 merge 的写操作数目.即 delta(wm ...

  10. usdt节点启动慢和队列深度超出了范围问题

    usdt节点启动慢和队列深度超出了范围问题 usdt的连接节点报错Work queue depth exceeded(队列深度超出了范围)大概是什么问题?重启了几次节点都不行队列深度超出了范围,估计是 ...

随机推荐

  1. 【Pandas】groupby连用的count()和size()的区别

    groupby连用的count()和size()的区别 count() 计算的是 value(数值): size() 计算的是 size(个数) 我们有以下表: size() age = df.gro ...

  2. 最终,我决定将代码迁出x86架构!

    如今,我们几乎所有软件都建立在 x86 架构之上 ,在互联网漫长的演进过程中,各大公司拼尽全力在迭代上层架构.优化整体性能,开发者们该用的.能用的招儿想必都用上了,接下来呢?如果底层架构不出现大的革新 ...

  3. Proxy下的Prepare透传,让GaussDB(for MySQL)更稳固,性能更卓越

    本文分享自华为云社区<Proxy下的Prepare透传,让GaussDB(for MySQL)更稳固,性能更卓越>,作者: GaussDB 数据库 . 1.引言 在很多业务场景下,数据库应 ...

  4. 干货分享丨从MPG 线程模型,探讨Go语言的并发程序

    摘要:Go 语言的并发特性是其一大亮点,今天我们来带着大家一起看看如何使用 Go 更好地开发并发程序. 我们都知道计算机的核心为 CPU,它是计算机的运算和控制核心,承载了所有的计算任务.最近半个世纪 ...

  5. CANN 5.0黑科技解密 | 算力虚拟化,让AI算力“物尽其用”

    摘要:算力虚拟化技术对消费者而言,可有效降低算力的使用成本,对于设备商或运营商而言,则可极大提升算力资源的利用率,降低设备运营成本. 为什么要做算力虚拟化 近年来,人工智能领域呈井喷式发展,算力就是生 ...

  6. html5鼠标拖动排序及resize实现方案分析及实践

    对列表进行拖动排序,尺寸改变.之前一般会使用jQuery-UI.其通过mousedown.mousemove.mouseup这三个事件来实现页面元素被鼠标拖拽的效果.vue-drag-resize v ...

  7. 【HZERO】分支管理

    分支管理 分支类型 feature-[任务编号]-简单描述: 任务开发分支,针对迭代子任务建立的开发分支 bugfix :修复分支,用于缺陷修复. develop:开发分支,所有开发人员都可以提交代码 ...

  8. 数字U家,即刻出发!2022联合利华黑客马拉松启动!

    2022联合利华黑客马拉松火热报名倒计时! 欢迎各领域的个人及组织团队参与 人工智能.数据挖掘.市场规模预测.原材料与包装风险控制.AR/VR.低碳.消费者偏好研究等超多创新赛题,任选其一. 作为快消 ...

  9. 强烈建议收藏,python库大全

    Python常用库大全及简要说明 本文为大家罗列了Python开发的常用库和各个库的简要说明以及Python开发工具,包管理,环境管理等其它常用资源和Python学习资料.本文只罗列了一部分,完整内容 ...

  10. B3637-DP【橙】

    这题我用sort的时候大意了,从1开始使用的下标但是用sort时没加1导致排序错误,排了半天错才发现. 另外,这道题我似乎用了一种与网络上搜到了做法截然不同的自己的瞎想出来的做法,我的这个做法需要n^ ...