溫馨提示×

溫馨提示×

您好，登錄后才能下訂單哦！

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務(wù)條款》

【Mysql】Mysql負(fù)載過大，app訪問延遲

發(fā)布時間：2020-08-09 01:42:05 來源：ITPUB博客 閱讀：312 作者：小亮520cl 欄目：MySQL數(shù)據(jù)庫
收到線上某業(yè)務(wù)后端的MySQL實例負(fù)載比較高的告警信息，于是登入服務(wù)器檢查確認(rèn)

1. 首先我們進(jìn)行OS層面的檢查確認(rèn)

此處)折疊或打開

  1. top命令
  2. [yejr@imysql.com:~ ]# top top - 11:53:04 up 702 days, 56 min, 1 user, load average: 7.18, 6.70, 6.47 Tasks: 576 total, 1 running, 575 sleeping, 0 stopped, 0 zombie Cpu(s): 7.7%us, 3.4%sy, 0.0%ni, 77.6%id, 11.0%wa, 0.0%hi, 0.3%si, 0.0%st ----%us 和 %wa 的值較高，表示當(dāng)前比較大的瓶頸可能是在用戶進(jìn)程消耗的CPU以及磁盤I/O等待上。
  3. Mem: 49374024k total, 32018844k used, 17355180k free, 115416k buffers Swap: 16777208k total, 117612k used, 16659596k free, 5689020k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 14165 mysql 20 0 8822m 3.1g 4672 S 162.3 6.6 89839:59 mysqld 40610 mysql 20 0 25.6g 14g 8336 S 121.7 31.5 282809:08 mysqld 49023 mysql 20 0 16.9g 5.1g 4772 S 4.6 10.8 34940:09 mysqld

如果%us過高
  1. 1：有大量的排序工作
  2. 2：sql索引不合理
  3. 查看慢日志，分析優(yōu)化SQL

如果%sy過高
  1. [root@HaoDai_App_DB01 ~]# iostat -x -m 2
    Linux 2.6.32-504.16.2.el6.x86_64 (HaoDai_App_DB01)      03/18/2016      _x86_64_        (40 CPU)


    avg-cpu:  %user   %nice %system %iowait  %steal   %idle
               4.29    0.00    0.20    0.05    0.00   95.46


    Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
    sda               0.00     2.97    0.04    0.48     0.00     0.01    72.81     0.00    0.49   0.28   0.01
    sdb               0.00   143.43    0.00  131.67     0.00     1.04    16.10     0.01    0.10   0.07   0.91


    avg-cpu:  %user   %nice %system %iowait  %steal   %idle
              12.54    0.00    0.38    0.03    0.00   87.06


    Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
    sda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
    sdb               0.00   174.00    0.00  137.50     0.00     1.17    17.40     0.03    0.19   0.14   1.95

  2. 如果，吞吐量（rMB/s+wMB/s)過低，但是util過高表示：隨機(jī)io特別的嚴(yán)重（可用pt-ioprofile去定位導(dǎo)致問題出現(xiàn)的表）
  3. IOPS=R/s+W/s

再利用 iotop 確認(rèn)到底哪些進(jìn)程消耗的磁盤I/O資源最多：
  • 一次請求讀寫的數(shù)據(jù)量太大，導(dǎo)致磁盤I/O讀寫值較大，例如一個SQL里要讀取或更新幾萬行數(shù)據(jù)甚至更多，這種最好是想辦法減少一次讀寫的數(shù)據(jù)量；
  • SQL查詢中沒有適當(dāng)?shù)乃饕梢杂脕硗瓿蓷l件過濾、排序（ORDER BY）、分組（GROUP BY）、數(shù)據(jù)聚合（MIN/MAX/COUNT/AVG等），添加索引或者進(jìn)行SQL改寫吧；
  • 瞬間突發(fā)有大量請求，這種一般只要能扛過峰值就好，保險起見還是要適當(dāng)提高服務(wù)器的配置，萬一峰值抗不過去就可能發(fā)生雪崩效應(yīng)；
  • 因為某些定時任務(wù)引起的負(fù)載升高，比如做數(shù)據(jù)統(tǒng)計分析和備份，這種對CPU、內(nèi)存、磁盤I/O消耗都很大，最好放在獨立的slave服務(wù)器上執(zhí)行；
  • 服務(wù)器自身的節(jié)能策略發(fā)現(xiàn)負(fù)載較低時會讓CPU降頻，當(dāng)發(fā)現(xiàn)負(fù)載升高時再自動升頻，但通常不是那么及時，結(jié)果導(dǎo)致CPU性能不足，抗不過突發(fā)的請求；
  • 使用raid卡的時候，通常配備BBU（cache模塊的備用電池），早期一般采用鋰電池技術(shù)，需要定期充放電（DELL服務(wù)器90天一次，IBM是30天），我們可以通過監(jiān)控在下一次充放電的時間前在業(yè)務(wù)低谷時提前對其進(jìn)行放電，不過新一代服務(wù)器大多采用電容式電池，也就不存在這個問題了。
  • 文件系統(tǒng)采用ext4甚至ext3，而不是xfs，在高I/O壓力時，很可能導(dǎo)致%util已經(jīng)跑到100%了，但iops卻無法再提升，換成xfs一般可獲得大幅提升；
  • 內(nèi)核的io scheduler策略采用cfq而非deadline或noop，可以在線直接調(diào)整，也可獲得大幅提升。
  • 基本如果%us使用過高 或者 %us和%iowait都高，一般都是并發(fā)時的sql寫的不好導(dǎo)致的



    • 用這個思路來分析一下我們生產(chǎn)上157負(fù)載高的原因（19:00持續(xù)到19:05）
    SELECT COUNT_STAR, SUM_TIMER_WAIT, AVG_TIMER_WAIT, EVENT_NAME FROM performance_schema.events_waits_summary_global_by_event_name where COUNT_STAR > 0 and EVENT_NAME like 'wait/synch/%' order by SUM_TIMER_WAIT desc limit 10; +------------+------------------+----------------+--------------------------------------------+ | COUNT_STAR | SUM_TIMER_WAIT | AVG_TIMER_WAIT | EVENT_NAME | +------------+------------------+----------------+--------------------------------------------+ | 36847781 | 1052968694795446 | 28575867 | wait/synch/mutex/innodb/lock_mutex | | 8096 | 81663413514785 | 10086883818 | wait/synch/cond/threadpool/timer_cond | | 19 | 3219754571347 | 169460766775 | wait/synch/cond/threadpool/worker_cond | | 12318491 | 1928008466219 | 156446 | wait/synch/mutex/innodb/trx_sys_mutex | | 36481800 | 1294486175099 | 35397 | wait/synch/mutex/innodb/trx_mutex | | 14792965 | 459532479943 | 31027 | wait/synch/mutex/innodb/os_mutex | | 2457971 | 62564589052 | 25346 | wait/synch/mutex/innodb/mutex_list_mutex | | 2457939 | 62188866940 | 24909 | wait/synch/mutex/innodb/rw_lock_list_mutex | | 201370 | 32882813144 | 163001 | wait/synch/rwlock/innodb/hash_table_locks | | 1555 | 15321632528 | 9853039 | wait/synch/mutex/innodb/dict_sys_mutex | +------------+------------------+----------------+--------------------------------------------+ 10 rows in set (0.01 sec)

    從上面的表可以確認(rèn)，lock_mutex（在MySQL源碼里對應(yīng)的是lock_sys->mutex）的鎖等待累積時間最長（SUM_TIMER_WAIT）。lock_sys表示全局的InnoDB鎖系統(tǒng)，在源碼里看到InnoDB加/解某個記錄鎖的時候（這個case里是X鎖），同時需要維護(hù)lock_sys，這時會請求lock_sys->mutex。

    在這個case里，因為在Searching rows for update的階段頻繁地加/解X鎖，就會頻繁請求lock_sys->mutex，導(dǎo)致lock_sys->mutex鎖總等待時間過長，同時在等待的時候消耗了大量CPU。


    向AI問一下細(xì)節(jié)

    免責(zé)聲明：本站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉(zhuǎn)載和分享為主，文章觀點不代表本網(wǎng)站立場，如果涉及侵權(quán)請聯(lián)系站長郵箱：is@yisu.com進(jìn)行舉報，并提供相關(guān)證據(jù)，一經(jīng)查實，將立刻刪除涉嫌侵權(quán)內(nèi)容。

    AI
    助
    手