欧美一区二区三区老妇人-欧美做爰猛烈大尺度电-99久久夜色精品国产亚洲a-亚洲福利视频一区二区

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

收到線上某業(yè)務(wù)后端的MySQL實(shí)例負(fù)載比較高的告警信息，于是登入服務(wù)器檢查確認(rèn)

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

此處)折疊或打開

創(chuàng)新互聯(lián)建站專注于滑縣企業(yè)網(wǎng)站建設(shè),響應(yīng)式網(wǎng)站,商城網(wǎng)站制作。滑縣網(wǎng)站建設(shè)公司,為滑縣等地區(qū)提供建站服務(wù)。全流程按需網(wǎng)站開發(fā)，專業(yè)設(shè)計(jì)，全程項(xiàng)目跟蹤，創(chuàng)新互聯(lián)建站專業(yè)和態(tài)度為您提供的服務(wù)

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



    • 用這個(gè)思路來分析一下我們生產(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源碼里對(duì)應(yīng)的是lock_sys->mutex）的鎖等待累積時(shí)間最長(zhǎng)（SUM_TIMER_WAIT）。lock_sys表示全局的InnoDB鎖系統(tǒng)，在源碼里看到InnoDB加/解某個(gè)記錄鎖的時(shí)候（這個(gè)case里是X鎖），同時(shí)需要維護(hù)lock_sys，這時(shí)會(huì)請(qǐng)求lock_sys->mutex。

    在這個(gè)case里，因?yàn)樵赟earching rows for update的階段頻繁地加/解X鎖，就會(huì)頻繁請(qǐng)求lock_sys->mutex，導(dǎo)致lock_sys->mutex鎖總等待時(shí)間過長(zhǎng)，同時(shí)在等待的時(shí)候消耗了大量CPU。


    網(wǎng)站欄目：【Mysql】Mysql負(fù)載過大，app訪問延遲
    轉(zhuǎn)載源于：http://www.chinadenli.net/article18/joisgp.html

    成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供微信小程序、企業(yè)建站、關(guān)鍵詞優(yōu)化、App設(shè)計(jì)、、搜索引擎優(yōu)化

    廣告

    聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)