此處)折疊或打開

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 的值較高，表示當前比較大的瓶頸可能是在用戶進程消耗的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. 查看慢日志，分析優化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過高表示：隨機io特別的嚴重（可用pt-ioprofile去定位導致問題出現的表）
3. IOPS=R/s+W/s

再利用 iotop 確認到底哪些進程消耗的磁盤I/O資源最多：

一次請求讀寫的數據量太大，導致磁盤I/O讀寫值較大，例如一個SQL里要讀取或更新幾萬行數據甚至更多，這種最好是想辦法減少一次讀寫的數據量；

SQL查詢中沒有適當的索引可以用來完成條件過濾、排序（ORDER BY）、分組（GROUP BY）、數據聚合（MIN/MAX/COUNT/AVG等），添加索引或者進行SQL改寫吧；

瞬間突發有大量請求，這種一般只要能扛過峰值就好，保險起見還是要適當提高服務器的配置，萬一峰值抗不過去就可能發生雪崩效應；

因為某些定時任務引起的負載升高，比如做數據統計分析和備份，這種對CPU、內存、磁盤I/O消耗都很大，最好放在獨立的slave服務器上執行；

服務器自身的節能策略發現負載較低時會讓CPU降頻，當發現負載升高時再自動升頻，但通常不是那么及時，結果導致CPU性能不足，抗不過突發的請求；

使用raid卡的時候，通常配備BBU（cache模塊的備用電池），早期一般采用鋰電池技術，需要定期充放電（DELL服務器90天一次，IBM是30天），我們可以通過監控在下一次充放電的時間前在業務低谷時提前對其進行放電，不過新一代服務器大多采用電容式電池，也就不存在這個問題了。

文件系統采用ext4甚至ext3，而不是xfs，在高I/O壓力時，很可能導致%util已經跑到100%了，但iops卻無法再提升，換成xfs一般可獲得大幅提升；

內核的io scheduler策略采用cfq而非deadline或noop，可以在線直接調整，也可獲得大幅提升。

基本如果%us使用過高 或者 %us和%iowait都高，一般都是并發時的sql寫的不好導致的

用這個思路來分析一下我們生產上157負載高的原因（19:00持續到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)

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

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

向AI問一下細節

推薦閱讀：

1. MySQL 5.7 延遲復制
2. mysql主從延遲設置

免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。

mysql app 延遲

• 上一篇新聞：
  Eclipse插件使用links目錄
• 下一篇新聞：
  server2003 sp1預覽與演示

猜你喜歡

• 企業網站采用虛擬主機有什么好處
• 虛擬主機管理面板是什么
• 虛擬主機空間不足怎么辦
• 虛擬主機被攻擊怎么辦
• 虛擬主機怎么加防御
• mongodb如何刪除數據
• mongodb如何修改字段類型
• mongodb如何查表的數據
• linux如何查看mongodb是否啟動
• mongodb和NoSql的區別

最新資訊

• pycharm在ubuntu怎樣啟用代碼導航工具
• ubuntu中pycharm如何禁用代碼導航工具
• 在ubuntu用pycharm怎樣啟用代碼重構工具
• ubuntu下pycharm如何禁用代碼重構工具
• pycharm ubuntu版怎樣啟用代碼優化工具
• ubuntu上pycharm如何禁用代碼優化工具
• 在ubuntu pycharm怎樣啟用代碼審查工具
• ubuntu下pycharm如何禁用代碼審查工具
• pycharm在ubuntu怎樣啟用代碼覆蓋率工具
• ubuntu中pycharm如何禁用代碼覆蓋率工具

相關推薦

• 網站訪問慢-MySQL負載高（實戰）
• MySQL - 主從同步延遲
• Mysql如何實現主從延遲監控
• MySQL中如何優化Slave延遲
• mysql占用資源過大如何解決
• MySQL同步延遲如何解決
• MySQL中CPU消耗過大如何解決
• 怎么用mysql減少主從延遲
• mysql的.ibd文件過大如何處理
• MySQL占用內存過大如何解決

相關標簽

mysql-python mysql主從 -mysqld mysql hotbackp mysql備份 mysql. mysql數據庫安裝 mysql面試 mysql分頁 mysql 數據庫 連接mysql mysql主從數據庫 mysql函數 mysql參數 mysql-server mysql5.7.23 mysql8.0.15 mysql5.7.16 mysql5. mysqli_query()函數