DW业务在MySQL上dump数据缓慢问题解决_MySQL

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了DW业务在MySQL上dump数据缓慢问题解决_MySQL，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含3983字，纯文字阅读大概需要6分钟。

内容图文

bitsCN.com

问题背景：

　　北京的DBA同学反馈，最近DW从MySQL拉数据，发现拉数据缓慢，当时进行了切换处理。后来经过DBA与业务方的分析，定位在某一台备库的拉数据速度明显比其主库要慢。

　　和DBA板桥进行详细沟通后背景后，看了板桥抓取的系统层面的信息后，发现iostat对比非常明显，大致怀疑是IO调度算法导致。用pt-summary看，发现内核版本和硬盘的调度不一样：

　　主备硬件环境差异对比：

Kernel | 2.6.32-220.17.1.tb619.el6.x86_64 2.6.18-164.el5
sda | [deadline] 128 [cfq] 128

　　在板桥的组织下，我们拉上DW的同学重新测试了一把。

　　原始的sda硬盘IO调度策略为cfq：

$ cat /sys/block/sda/queue/scheduler
noop anticipatory deadline [cfq]

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sda 4.95 21017.82 1697.03 144.55 53600.00 83889.11 74.66 39.44 16.24 0.54 99.11
sda 4.00 7135.00 196.00 470.00 6112.00 153664.00 239.90 71.69 122.19 1.50 100.10
sda 5.00 173.00 1567.00 276.00 49544.00 14152.00 34.56 19.00 9.87 0.54 100.10
sda 6.00 240.00 1317.00 206.00 41704.00 6600.00 31.72 21.21 14.13 0.66 100.10
sda 5.00 123.00 1956.00 54.00 61872.00 1288.00 31.42 18.25 9.14 0.50 100.10
sda 6.00 3368.00 1515.00 85.00 47880.00 27544.00 47.14 22.12 13.61 0.63 100.10
sda 6.00 190.00 1664.00 66.00 52720.00 2288.00 31.80 19.19 11.24 0.58 100.10
sda 9.00 533.00 999.00 1329.00 30960.00 54736.00 36.81 18.79 7.68 0.43 100.10
sda 18.00 466.00 1771.00 864.00 54032.00 36336.00 34.30 13.07 5.38 0.38 100.10
sda 4.95 95.05 1401.98 15.84 44435.64 641.58 31.79 21.46 14.08 0.70 99.11
sda 13.00 291.00 1639.00 67.00 50296.00 3128.00 31.32 16.82 10.70 0.59 100.10
sda 4.00 191.00 1512.00 17.00 47792.00 1136.00 32.00 23.93 15.50 0.65 100.10
sda 8.00 108.00 1699.00 52.00 53792.00 1280.00 31.45 25.18 13.85 0.57 100.10
sda 7.00 143.00 1429.00 27.00 45344.00 1824.00 32.40 18.71 13.19 0.69 100.10
sda 13.00 186.00 990.00 19.00 30888.00 1176.00 31.78 18.06 18.11 0.99 100.10
sda 3.00 102.00 763.00 12.00 24184.00 1232.00 32.79 16.64 20.77 1.29 100.10

　　将硬盘sda 的IO调度策略更改为deadline进行对比：

$ sudo su -c “echo deadline | sudo tee /sys/block/sda/queue/scheduler”
deadline
或者
$ echo deadline | sudo tee /sys/block/sda/queue/scheduler
deadline



Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sda 31.00 208.00 4088.00 372.00 128432.00 11120.00 31.29 10.40 2.33 0.22 100.10
sda 28.00 193.00 4173.00 360.00 132024.00 11016.00 31.56 9.12 2.01 0.22 100.10
sda 37.00 125.00 4503.00 317.00 142472.00 10048.00 31.64 9.13 1.89 0.21 100.10
sda 30.00 266.00 4452.00 414.00 141072.00 12040.00 31.47 8.68 1.78 0.21 100.10
sda 44.00 171.00 4629.00 450.00 146568.00 18064.00 32.41 8.74 1.72 0.20 100.10
sda 32.00 239.00 4660.00 560.00 147328.00 18456.00 31.76 9.84 1.89 0.19 100.10
sda 30.00 330.00 4004.00 463.00 125808.00 13072.00 31.09 9.63 2.16 0.22 100.10
sda 38.00 122.00 4730.00 358.00 149680.00 10392.00 31.46 8.71 1.72 0.20 100.10
sda 29.00 408.00 3897.00 813.00 122632.00 22760.00 30.87 9.48 2.01 0.21 100.10
sda 27.72 115.84 3687.13 282.18 116586.14 9655.45 31.80 9.19 2.32 0.25 99.11
sda 30.00 259.00 3629.00 739.00 114144.00 26616.00 32.23 10.55 2.40 0.23 100.10
sda 34.00 206.00 4608.00 190.00 145232.00 3272.00 30.95 9.47 1.98 0.21 100.10
sda 34.00 190.00 4327.00 449.00 136304.00 11696.00 30.99 9.40 1.96 0.21 100.10
sda 41.00 229.00 4559.00 389.00 144408.00 11464.00 31.50 8.93 1.81 0.20 100.10

　　对比数据非常直观了反映了CFQ和DEADLINE的特性：

　　1. CFQ通过对IO地址排序来减少磁盘寻道时间，尽可能的磁盘转数来满足尽可能多的IO请求。从rrqm/s和wrqm/s的数据看非常明显。

　　2. CFQ先来的IO请求并不一定能被满足，可能会出现饿死的情况。 这里看到的倒不是饿死，而是await明显的偏长。

　　3. DEADLINE比CFQ更适合DB。 rsec/s和wsec/s比CFQ中量更大，即IO吞吐量更高。

　　通过DW同学的反馈，应用端速度明显快了，说明确实有效。这台机器属于老机器，新装的机器已经被OPS同学统一设置为DEADLINE。

bitsCN.com

内容总结

以上是互联网集市为您收集整理的DW业务在MySQL上dump数据缓慢问题解决_MySQL全部内容，希望文章能够帮你解决DW业务在MySQL上dump数据缓慢问题解决_MySQL所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

---