IO问题的一个定位思路

白鳝的洞穴 2020-06-15

1445

这是一个2013年的案例。当时客户的存储性能不足，Oracle数据库经常HANG，因此换了一个新存储，新更换的存储是华为S5600T，换上去后，不会出现系统HANG的问题了，但是还是觉得比较慢。老白首先拿到了他们的AWR报告，通过AWR报告进行分析。出问题时候的AWR报告的一些关键片段如下

Elapsed:60.73 (mins)

DBTime: 1,459.39 (mins) --DB TIME还是挺高的

Cache Sizes

--------------------

BufferCache:61,440M 61,440M Std Block Size: 8K

SharedPoolSize: 4,096M 4,096M Log Buffer: 96,128K

LoadProfile

PerSecond Per Transaction

---------- ----------- ---------

Redosize: 37,803,799.36 15,612,039.36

Logicalreads: 218,083.70 90,063.20

Blockchanges: 154,377.24 63,754.00

Physicalreads: 2,832.10 1,169.59

Physicalwrites: 10,388.01 4,289.99

Usercalls: 1,781.62 735.77

Parses: 26.39 10.90

Hard parses: 0.68 0.28

Sorts: 7.01 2.89

Logons: 0.50 0.21

Executes: 36.30 14.99

Transactions: 2.42

%Blocks changed per Read: 70.79 Recursive Call %: 15.74

Rollback per transaction %: 0.05 Rows per Sort: ########

Instance Efficiency Percentages (Target 100%)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Buffer Nowait %: 100.00 Redo NoWait %: 99.99

Buffer Hit %: 99.24 In-memory Sort %: 99.91

Library Hit %: 98.01 Soft Parse %: 97.41

Executeto Parse %: 27.30 Latch Hit %: 99.82

Parse CPU to Parse %: 1.69 %Non-Parse CPU: 99.98

Top 5 Timed Events

db file scattered read 364,722 31,340 86 35.8 User I/O

db file sequential read 250,654 15,419 62 17.6 User I/O

CPUtime 12,738 14.5

db file parallel write 158,850 9,728 61 11.1 System I/O

direct path read 161,876 8,024 50 9.2 User I/O

看了上面的TOP 5 EVENT，性子急的朋友可能一眼就看到了direct path read。确实这个等待事件很明显，不过看看所占比例只有9.2%，就说明这个可能不是最主要的问题了。稍微有点经验的DBA可能很快可以看出db file scattered read占了第一位，也就是说存在较多的全表扫描，于是可能迫不及待的药去找TOP SQL了。事实上，可能会让这些人失望，这套系统负载最大的应用就是后台批处理，前台业务并不繁忙。这些批处理大多数都是做全表或者全分区扫描，很多SQL是很难优化的。

实际上有点经验的DBA都看得出，这个系统的IO有问题，单块读，多块读的平均延时都很高。

从AWR数据上看，很明显，本系统是一个写IO很大的系统，每秒REDO的量达到了 36M/秒以上，每秒的物理写超过1万，这在普通的Oracle数据库系统中是比较少见的，只有在ETL比较多的系统中才常见，确实这是一套ODS系统，主要用于各种数据共享操作的。

从主要等待事件上看，也主要集中在IO上，从WAIT CLASS分类看，USER I/O也排在第一位，平均等待时间为59MS，SYSTEMI/O的平均等待也达到40MS，从这些指标上看IO是明显存在问题的。既然IO存在明显的问题，那么我们就需要马上采集下操作系统IO的情况

APE:/ # sar -d 3 2hdisk0 0 0.0 0 0 0.0 0.0hdisk2 3 0.0 13 1067 0.0 10.8hdisk3 2 0.0 11 1057 0.0 8.9hdisk44 79 0.0 107 10475 4.9 7.5hdisk43 98 0.1 188 14820 12.1 5.1hdisk39 99 0.2 150 5531 41.9 6.6hdisk38 23 0.4 288 2921 43.0 0.8hdisk40 99 0.6 336 11877 52.6 3.0hdisk42 99 0.2 201 13383 29.0 5.0hdisk41 60 0.2 222 8487 28.9 2.7hdisk47 0 0.0 9 202 1.6 0.5Average hdisk1 0 0.0 0 0 0.0 0.0hdisk0 0 0.0 0 0 0.0 0.0hdisk2 3 0.0 13 1235 0.0 11.2hdisk3 3 0.0 14 1234 0.0 9.2cd0 0 0.0 0 0 0.0 0.0hdisk44 64 0.0 96 7285 7.5 6.8hdisk43 81 0.1 163 11074 13.6 4.9hdisk39 99 0.2 149 7060 41.3 6.7hdisk38 26 0.6 295 3001 64.8 0.9hdisk40 99 0.5 273 11536 56.8 3.8hdisk42 99 0.5 273 13690 52.6 3.9hdisk41 60 0.3 234 9110 37.1 2.6hdisk47 0 0.0 10 175 1.2 0.5hdisk45 0 0.0 0 21 0.0 0.4

从上述指标上看，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 -DSystem configuration: lcpu=32 drives=111 paths=4vdisks=0hdisk44 xfer: %tm_act bps tps bread bwrtn21.9 4.1M 160.3 2.1M 2.0Mread: rps avgserv minserv maxserv timeouts fails28.8 5.6 0.1 1.2S 0 0write: wps avgserv minserv maxserv timeoutsfails131.5 0.4 0.2 1.7S 0 0queue: avgtime mintime maxtime avgwqsz avgsqszsqfull68.1 0.0 9.2S 12.0 0.0 160.3hdisk43 xfer: %tm_act bps tps bread bwrtn24.0 4.6M 198.9 1.9M 2.7Mread: rps avgserv minserv maxserv timeouts fails29.4 5.6 0.1 748.9 0 0write: wps avgserv minserv maxserv timeoutsfails169.4 0.4 0.2 1.2S 0 0queue: avgtime mintime maxtime avgwqsz avgsqszsqfull107.4 0.0 11.6S 25.0 0.0 198.9hdisk39 xfer: %tm_act bps tps bread bwrtn27.5 5.3M 192.9 2.6M 2.6Mread: rps avgserv minserv maxserv timeouts fails38.8 5.3 0.1 791.8 0 0write: wps avgserv minserv maxserv timeoutsfails154.0 0.4 0.2 1.4S 0 0queue: avgtime mintime maxtime avgwqsz avgsqszsqfull100.2 0.0 11.0S 21.0 0.0 192.9hdisk38 xfer: %tm_act bps tps bread bwrtn17.1 3.5M 145.8 1.4M 2.1Mread: rps avgserv minserv maxserv timeouts fails19.9 5.7 0.1 967.4 0 0write: wps avgserv minserv maxserv timeoutsfails125.9 0.4 0.2 2.3S 0 0queue: avgtime mintime maxtime avgwqsz avgsqszsqfull282.0 0.0 11.4S 44.0 0.0 145.8hdisk40 xfer: %tm_act bps tps bread bwrtn25.0 5.3M 178.7 2.7M 2.6Mread: rps avgserv minserv maxserv timeouts fails36.5 5.1 0.1 793.6 0 0write: wps avgserv minserv maxserv timeoutsfails142.2 0.4 0.3 845.6 0 0queue: avgtime mintime maxtime avgwqsz avgsqsz sqfull89.7 0.0 10.3S 17.0 0.0 178.7hdisk42 xfer: %tm_act bps tps bread bwrtn30.0 6.3M 299.6 2.9M 3.4Mread: rps avgserv minserv maxserv timeouts fails40.2 4.8 0.1 691.9 0 0write: wps avgserv minserv maxserv timeoutsfails259.4 0.4 0.2 1.1S 0 0queue: avgtime mintime maxtime avgwqsz avgsqszsqfull3.2S 0.0 11.1S 957.0 0.0 299.6hdisk41 xfer: %tm_act bps tps bread bwrtn18.6 4.3M 174.9 1.8M 2.5Mread: rps avgserv minserv maxserv timeouts fails23.9 5.0 0.1 747.2 0 0write: wps avgserv minserv maxserv timeoutsfails151.0 0.4 0.2 1.0S 0 0queue: avgtime mintime maxtime avgwqsz avgsqszsqfull82.2 0.0 6.6S 16.0 0.0 174.9

大家可以关注最后一个指标sqfull的指标值，如果这个指标大于0，说明QUEUE_DEPTH参数的设置是不足的，出现了大量IO队列满的情况。从上述数据我们可以比较肯定队列等待可能是问题的主要原因了。下面我们来看看实际上HDISK的设置是什么样的：

APE:/ # lsattr -El hdisk42clr_q no Device CLEARS its Queue on error Truelocation Location Label True

lun_id 0x4000000000000

Logical Unit Number ID

Falsemax_transfer 0x40000 Maximum TRANSFER SizeTruenode_name 0x2100f84abf591cca FC Node NameFalsepvid 00cd36456aecb23e0000000000000000 Physicalvolume identifierFalseq_err yes Use QERR bitTrueq_type simple Queuing TYPETruequeue_depth 1 Queue DEPTH

什么？QUEUE_DEPTH居然是1？其实也没啥大惊小怪的，在AIX系统下，华为存储的缺省QUEUE_DEPTH就是1，也就是说存储工程师并没有帮助用户设置合理的值。其实HDS存储在AIX上的QUEUE_DEPTH缺省值是2，类似的情况还有很多。那么这个参数设置为多少合适呢?根据老白的经验，如果跑Oracle这个参数至少设置为8，高负载的系统可以设置为更大的值，甚至32或者更高（LINUX上缺省是128）,不过也不是越高越好，要看你的存储的能力，如果这个参数很大，存储没那么强的能力，也是没用的，需要一个匹配。

既然发现了问题，那么果断的将参数调整为24，我们来看看优化后的效果：将QUEUE_DEPTH加大到24,再看AWR数据：

Load Profile~~~~~~~~~~~~

Per Second Per Transaction ------------ ---------------Redo size: 58,379,378.01 11,838,984.49Logical reads: 297,113.02 60,252.72Block changes: 206,017.48 41,779.10Physical reads: 2,117.52 429.42Physical writes: 27,976.85 5,673.54

User calls: 51.61 10.47

Parses: 26.49 5.37Hard parses: 1.00 0.20Sorts: 2.88 0.58Logons: 0.80 0.16Executes: 30.86 6.26Transactions: 4.93Top 5 Timed Events

Avg %Total~~~~~~~~~~~~~~~~~~

wait CallEvent Waits Time (s) (ms) Time Wait Class------------------------------ ------------ ----------- ------ ----------------CPU time 18,629 29.7db file scattered read 463,322 17,063 37 27.2 User I/Odb file sequential read 336,204 10,451 31 16.7 User I/Odb file parallel write 300,543 7,727 26 12.3 System I/OSQL*Net more data from dblink 8,196,651 5,149 1 8.2 Network-------------------------------------------------------------

是不是好了很多。其实这时候IO还是有问题，现在压力下放到存储上，存储上看到明显的性能问题了，avserv的等待明显比avwait要高多了。下面可以进一步优化，比如QUEUE DEPTH是不是还可以再加大。另外数据能否存放到更多的盘上。给客户的建议是再多分配2-3个RAID 组，把部分数据分散到多个RAID组上。

最后修改时间：2020-06-15 09:22:23

文章转载自白鳝的洞穴，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

IO问题的一个定位思路

评论