数据库操作是IO密集型的论证
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了数据库操作是IO密集型的论证相关的知识,希望对你有一定的参考价值。
一、iostat
背景是我们在进行大量的数据更新操作,以此来查看磁盘的状态情况。
我们查看磁盘IO,也主要是通过iostat 这个命令来进行查看。
iostat -d -k 1 5
-d 表示,显示设备(磁盘)使用状态,去掉可以和CPU状态一起显示;
-k某些使用block为单位的列强制使用Kilobytes为单位,改为-m(以MB为单位展示);
1 5表示,数据显示每隔1秒刷新一次,共显示10次。
[[email protected] ~]# iostat -d -k 1 5
Linux 3.10.0-514.el7.x86_64 06/09/2018 _x86_64_ (32 CPU)
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 10.53 319.13 488.33 8783422264 13440316927
dm-0 0.16 0.03 1.35 757398 37188411
dm-1 0.00 0.00 0.01 117580 301216
dm-2 10.41 319.10 486.97 8782517912 13402825288
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 1028.00 18624.00 71374.50 18624 71374
dm-0 0.00 0.00 0.00 0 0
dm-1 0.00 0.00 0.00 0 0
dm-2 1033.00 19392.00 71630.50 19392 71630
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 854.00 24464.00 70580.50 24464 70580
dm-0 0.00 0.00 0.00 0 0
dm-1 0.00 0.00 0.00 0 0
dm-2 855.00 23696.00 70674.00 23696 70674
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 849.00 13312.00 87219.50 13312 87219
dm-0 0.00 0.00 0.00 0 0
dm-1 0.00 0.00 0.00 0 0
dm-2 876.00 14336.00 87750.00 14336 87750
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 770.00 19456.00 70206.50 19456 70206
dm-0 0.00 0.00 0.00 0 0
dm-1 0.00 0.00 0.00 0 0
dm-2 745.00 19456.00 69771.00 19456 69771
kB_read/s:每秒从设备(drive expressed)读取的数据量;
kB_wrtn/s:每秒向设备(drive expressed)写入的数据量;
kB_read:读取的总数据量;
kB_wrtn:写入的总数量数据量;这些单位都为Kilobytes。
参数-k
[[email protected] ~]# iostat -d -x -k 1
Linux 3.10.0-514.el7.x86_64 06/09/2018 _x86_64_ (32 CPU)
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.04 6.07 4.47 319.23 488.61 153.32 0.01 1.12 1.05 1.23 0.33 0.35
dm-0 0.00 0.00 0.00 0.16 0.03 1.35 17.12 0.00 0.19 1.78 0.17 0.03 0.00
dm-1 0.00 0.00 0.00 0.00 0.00 0.01 8.01 0.00 0.43 0.42 0.43 0.03 0.00
dm-2 0.00 0.00 6.06 4.35 319.20 487.25 154.87 0.01 1.14 1.05 1.28 0.34 0.35
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 10.00 467.00 2080.00 10256.00 51.72 155.43 342.20 334.70 342.36 2.10 100.00
dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-2 0.00 0.00 7.00 489.00 1312.00 11232.00 50.58 160.96 339.23 614.29 335.29 2.02 100.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 6.00 343.00 1056.00 10408.00 65.70 146.90 374.37 300.83 375.65 2.87 100.00
dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-2 0.00 0.00 8.00 322.00 1808.00 6704.00 51.59 152.25 407.81 336.75 409.57 3.03 100.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 8.00 429.00 2048.00 4576.00 30.32 146.42 341.64 278.25 342.82 2.29 100.00
dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-2 0.00 0.00 5.00 448.00 1280.00 7992.00 40.94 150.86 340.85 623.60 337.69 2.21 100.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 4.00 447.00 1024.00 10622.00 51.65 146.52 336.33 506.50 334.81 2.22 100.00
dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-2 0.00 0.00 5.00 454.00 1040.00 11302.00 53.78 151.71 340.31 464.20 338.94 2.18 100.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 7.00 435.00 1072.00 13248.00 64.80 146.15 351.56 252.86 353.15 2.26 100.00
dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-2 0.00 0.00 11.00 416.00 1856.00 9192.00 51.75 152.02 378.61 290.09 380.95 2.34 100.00
可以看到磁盘的平均响应时间>300ms,磁盘使用率>100。磁盘响应不正常,IO已经满负载了。
rrqm/s: 每秒进行 merge 的读操作数目.即 delta(rmerge)/s
wrqm/s: 每秒进行 merge 的写操作数目.即 delta(wmerge)/s
r/s: 每秒完成的读 I/O 设备次数.即 delta(rio)/s
w/s: 每秒完成的写 I/O 设备次数.即 delta(wio)/s
rsec/s: 每秒读扇区数.即 delta(rsect)/s
wsec/s: 每秒写扇区数.即 delta(wsect)/s
rkB/s: 每秒读K字节数.是 rsect/s 的一半,因为每扇区大小为512字节.(需要计算)
wkB/s: 每秒写K字节数.是 wsect/s 的一半.(需要计算)
avgrq-sz: 平均每次设备I/O操作的数据大小 (扇区).delta(rsect+wsect)/delta(rio+wio)
avgqu-sz: 平均I/O队列长度.即 delta(aveq)/s/1000 (因为aveq的单位为毫秒).
await: 平均每次设备I/O操作的等待时间 (毫秒).即 delta(ruse+wuse)/delta(rio+wio)
svctm: 平均每次设备I/O操作的服务时间 (毫秒).即 delta(use)/delta(rio+wio)
%util: 一秒中有百分之多少的时间用于 I/O 操作,或者说一秒中有多少时间 I/O 队列是非空的.即 delta(use)/s/1000 (因为use的单位为毫秒)
如果 %util 接近 100%,说明产生的I/O请求太多,I/O系统已经满负荷,该磁盘可能存在瓶颈。
idle小于70% IO压力就较大了,一般读取速度有较多的wait.
CPU的负载很低,磁盘接近100%,所以说大量的数据库更新操作瓶颈在于磁盘IO。
如果svctm 比较接近await,说明I/O 几乎没有等待时间;
如果await 远大于svctm,说明I/O队列太长,应用得到的响应时间变慢
二、举例
举一个例子,我们在超市排队 checkout 时,怎么决定该去哪个交款台呢? 首当是看排的队人数,5个人总比20人要快吧?除了数人头,我们也常常看看前面人购买的东西多少,如果前面有个采购了一星期食品的大妈,那么可以考虑换个队排了。还有就是收银员的速度了,如果碰上了连钱都点不清楚的新手,那就有的等了。另外,时机也很重要,可能 5分钟前还人满为患的收款台,现在已是人去楼空,这时候交款可是很爽啊,当然,前提是那过去的 5 分钟里所做的事情比排队要有意义(不过我还没发现什么事情比排队还无聊的)。
I/O 系统也和超市排队有很多类似之处:
r/s+w/s 类似于交款人的总数
平均队列长度(avgqu-sz)类似于单位时间里平均排队人的个数
平均服务时间(svctm)类似于收银员的收款速度
平均等待时间(await)类似于平均每人的等待时间
平均I/O数据(avgrq-sz)类似于平均每人所买的东西多少
I/O 操作率 (%util)类似于收款台前有人排队的时间比例。
我们可以根据这些数据分析出 I/O 请求的模式,以及 I/O 的速度和响应时间。
下面是别人写的这个参数输出的分析:
[[email protected] ~]# iostat -x -m 1
Linux 3.10.0-514.el7.x86_64 06/09/2018 _x86_64_ (32 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
3.64 0.00 3.95 6.15 0.00 86.25
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 923.00 20.00 290.00 20.00 9.70 0.16 65.08 1.21 3.91 3.62 8.05 3.19 98.90
上面的 iostat 输出表明秒有 310 次设备 I/O 操作: 总IO(io)/s = r/s(读) +w/s(写) = 290+20 = 310 (次/秒) 其中写操作占了主体 (w:r = 29:2)。
平均每次设备 I/O 操作只需要 5ms 就可以完成,但每个I/O 请求却需要等上 78ms,为什么? 因为发出的 I/O 请求太多 (每秒钟约29 个),假设这些请求是同时发出的,那么平均等待时间可以这样计算:
平均等待时间 = 单个I/O 服务时间 ( 1 + 2 + ... + 请求总数-1) / 请求总数
应用到上面的例子: 平均等待时间 = 5ms (1+2+...+28)/29 = 70ms,和 iostat 给出的78ms 的平均等待时间很接近。这反过来表明 I/O 是同时发起的。
每秒发出的 I/O 请求很多 (约29 个),平均队列却不长 (只有2 个左右),这表明这 29 个请求的到来并不均匀,大部分时间 I/O是空闲的。
一秒中有 14.29% 的时间 I/O 队列中是有请求的,也就是说,85.71% 的时间里 I/O 系统无事可做,所有 29 个I/O 请求都在142毫秒之内处理掉了。
delta(ruse+wuse)/delta(io) = await = 78.21 => delta(ruse+wuse)/s=78.21 delta(io)/s = 78.2128.57 =2232.8,表明每秒内的I/O请求总共需要等待2232.8ms。所以平均队列长度应为 2232.8ms/1000ms = 2.23,而iostat 给出的平均队列长度(avgqu-sz) 却为22.35,为什么?因为iostat 中有bug,avgqu-sz值应为2.23,而不是22.35。
※附带说明下,我用iostat对服务器检测时,一般用iostat -d命令;而返回的结果,我关注的一般是tps、blk_read/s、blk_wrth/s这三项,我一般是拿三台不同型号的服务器在相同环境下作对比测试,这样性能上的差异,一下子就出来了。
以上是关于数据库操作是IO密集型的论证的主要内容,如果未能解决你的问题,请参考以下文章