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

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com