關於MySQL latch爭用深刻分析與判斷

一、latch鎖是什麼鎖？

二、latch鎖是如何保護list？

三、latch爭用的現象和過程？

四、latch何時會產生嚴重的爭用？

五、如何監控latch爭用狀況？

六、如何確認latch爭用類型？

七、如何下降latch爭用？

1、latch鎖是什麼鎖

一、定義

　　latch鎖是內存鎖，是一個小型的在內存中保護list的內存鎖結構。

二、特色

　　一、不排隊

　　二、spin，一個線程想得到一個鎖，可是該鎖已被另外一線程持有，進行spin(空轉隨機時間)佔用cpu間接性的等待鎖的釋放，而後獲取去進行相關操做。

　　三、os waits：sleep，spin屢次仍然spin

　　四、cpu繁忙，latch爭用

 Q：什麼是鎖？

A：

　　一、用來保護共享資源，支持併發

　　二、鎖會影響併發

　　三、latch鎖、lock鎖

 

二、latch鎖是如何保護list

一、「保護」過程分析

　　一、訪問頁先須要訪問鏈

　　二、修改list不等於修改頁

　　三、何時修改list

　　　　一、物理讀，將數據頁掛到list上

　　　　二、內存讀、修改數據頁，修改鏈

　　四、鎖，其實就是一個內存空間，有結構有數據的內存數據塊

　　　　s：R共享鎖

　　　　x：W排它鎖

　　五、鎖的兼容性

　　　　一、但凡是有x鎖，排它，就不兼容。

　　　　二、latch鎖排它就會形成latch爭用。

注：mutex互斥鎖：針對併發量不是很大的資源。

二、原理圖分析

 

 

3、latch爭用的現象和過程

一、latch爭用現象

　　一、latch爭用會表現爲cpu繁忙

　　二、latch爭用沒有排隊，等一段隨機的時間再回來看一看

二、latch爭用過程

　　一、鏈上有一個鏈的保護機制latch，小內存結構；

　　二、這時候有讀的線程A上來要讀取鏈，這個時候這個管理就變成r(讀鎖)，當在鏈上找到數據頁的時候(讀)，一找到就釋放讀鎖；

　　三、B上來也要讀取，這個時候一看是r，讀鎖是能夠共享的，它也對鏈進行訪問讀取；

　　四、C上來要修改鏈中的兩個塊的內容，一看是r，r和w是互斥的，不能同時進行，要麼

　　　　一、主動要求退出cpu；

　　　　二、空佔着cpu資源(執行一段空代碼，loop，隔一段時間看看A和B有沒有使用完(spin)，可是在這個過程當中由於C沒有排隊等待，因此可能在等待的過程當中又有其餘的線程上來霸佔鏈(不排隊的壞處)，若是執行屢次仍這樣，可能就sleep，退出cpu了，sleep，產生os waits)。

　　五、爲何空佔(懼怕os看它閒着把它強行拖出去)

　　六、等(由於它知道A和B佔用資源時間比較短，就是遍歷一條鏈的時間很是短)

 

四、latch何時會產生嚴重的爭用

一、異常SQL：每每意味着latch爭用

　　大量的物理讀：修改鏈

　　大量的內存讀：遇到修改鏈的衝突

二、內存訪問頻繁（不停找），其實也是異常SQL形成的。

三、list太長

　　鏈上掛10000個塊，被持有的概率太大……

mysql> show variables like 'i%instances'; +------------------------------+-------+
| Variable_name                | Value |
+------------------------------+-------+
| innodb_buffer_pool_instances | 1     |
+------------------------------+-------+
1 row in set (0.00 sec)

　　因此，有時候會增長instance的數量，把大pool切成小的pool，讓list鏈變的短一些。

 

五、如何監控latch爭用狀況

一、對於MySQL 5.7

mysql> show engine innodb status\G …… SEMAPHORES ---------- OS WAIT ARRAY INFO: reservation count 23 OS WAIT ARRAY INFO: signal count 14 RW-shared spins 0, rounds 73, OS waits 5 RW-excl spins 0, rounds 1114, OS waits 5 RW-sx spins 0, rounds 0, OS waits 0 Spin rounds per wait: 73.00 RW-shared, 1114.00 RW-excl, 0.00 RW-sx

　　rounds：表示spin一次空轉多少圈，也就是返回來詢問的次數

　　OS waits：表示sleep，當忽然增加比較快時，說明latch爭用比較嚴重

　　一、若是OS waits值比較高，說明出現latch爭用，異常SQL

　　二、獲取latch的代價：73.00 RW-shared, 1114.00 RW-excl

二、對於MySQL 5.6

mysql> show engine innodb status\G …… SEMAPHORES ---------- OS WAIT ARRAY INFO: reservation count 29758 OS WAIT ARRAY INFO: signal count 29148 Mutex spin waits 1054508, rounds 427812, OS waits 2104 RW-shared spins 26703, rounds 800527, OS waits 26673 RW-excl spins 68, rounds 27115, OS waits 888 Spin rounds per wait: 0.41 mutex, 29.98 RW-shared, 398.75 RW-excl

　　Mutex spin waits：能夠理解成misses，空轉cpu

　　Mutex是互斥鎖、RW-shared是共享鎖、RW-excl是排它鎖

 

六、確認latch爭用類型

mysql> show engine innodb mutex; +--------+-----------------------------+----------+
| Type   | Name                        | Status   |
+--------+-----------------------------+----------+
| InnoDB | rwlock: dict0dict.cc:2687   | waits=1  |
| InnoDB | rwlock: dict0dict.cc:1184   | waits=13 |
| InnoDB | rwlock: log0log.cc:844      | waits=35 |
| InnoDB | sum rwlock: buf0buf.cc:1457 | waits=4  |
+--------+-----------------------------+----------+
4 rows in set (0.16 sec)

　　利用show engine innodb mutex;來解決latch和mutex問題。

[root@localhost ~]# find / -name dict0dict.cc
/usr/src/debug/percona-xtrabackup-2.4.4/storage/innobase/dict/dict0dict.cc
/usr/local/src/mysql-5.7.14/storage/innobase/dict/dict0dict.cc [root@localhost ~]# cat /usr/local/src/mysql-5.7.14/storage/innobase/dict/dict0dict.cc　　　　#查看源碼信息，看其latch爭用類型具體描述

 

七、如何下降latch爭用

一、優化SQL，下降對內存讀的數量，效果比較明顯。

二、增長innodb_buffer_pool_instances的數量。對於具備大內存的64位系統，能夠將緩衝池拆分紅多個實例（默認8個），把須要緩衝的數據hash到不一樣的緩衝池中，這樣能夠並行的內存讀寫，以最大限度地減小併發操做中內存結構的爭用。