MySQL的內存和相關問題排查是怎樣的

MySQL的內存和相關問題排查是怎樣的，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

我們都知道數據庫是IO密集型一類應用，為了提高其性能大量使用內存代替文件（交換分區）的IO操作是保證數據庫穩定、高效的基本原則。那么數據庫是如何使用內存的，我們如何查看數據庫內存的占用，如何通過通過數據庫內存配置設置提高其性能？以Mysql數據庫（InnoDB引擎）為例和大家一起了解下Linux數據庫和內存相關的主題。讀取內存數據非常快，為了提高性能我們要盡可能把數據集都放到內存中以保證高效。但是Swap交換分區作為一個救命的稻草，我們還必須要給mysql設置，防止突發情況下內存不夠，mysql服務直接被OOM殺掉的情況。同時mysql交換分區占用也是我們衡量一個數據是否健康與否的手段，如果一個數據庫頻繁的使用了swap則說明，我們需要人工干預優化數據庫了。

內存占用

在Linux下，我們可以通過使用一些shell命令來了解MySQL的內存使用情況。

首先使用ps命令來查看mysqld進程的內存使用情況：

ps -eo size,pid,user,command --sort -size|grep mysqld |awk '{hr=$1/1024;printf("%13.2f MB",hr)} {for (x=4;x<=NF;x++){printf("%s",$x)}print ""}' |cut -d "" -f2|cut -d "-" -f1

1990.88 MB/usr/local/mariadb/bin/mysqld 0.49 MB/bin/sh/usr/local/mariadb/bin/mysqld_safe

top命令也可以查看對應上面的結果也可以用top來得到：

top -b -o %MEM -n1 -p $(pidof mysqld) | grep PID -A

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2239 mysql 20 0 2108536 316836 7548 S 0.0 4.0 48:47.37 mysqld

其中，VIRT（virtual memory usage）表示mysql使用的虛擬內存總量。它包括所有代碼，數據和共享庫以及最終要被置換出的頁面。

RES(resident memory usage) 常駐內存,包括當前進程使用的內存，不包括置換出的內存。

SHR（shared memory） 共享內存，進程使用的的共享內存，也包括其他進程的共享內存。

交換分區

我們再來檢查檢查mysqld是否正在使用交換分區，首先用free -m檢查是否有用到交換分區。

free -m

total used free shared buff/cache available Mem: 7822 5091 178 83 2552 2290 Swap: 3999 2 3997

上面結果了，系統使用少量的交換分區（2M），那怎么判斷是不是MySQL用的呢？我們來驗證：

cat /proc/$(pidof gitlab)/status | grep Swap

VmSwap：0 kB

可見mysqld不沒用用到交換區，說明我的mysqld在高效運行中。

這兒我們提供一個腳本，遍歷每一個進程，找出那些進程使用了交換分區：

for i in $(ls -d /proc/[0-9]*) do out=$(grep Swap $i/status 2>/dev/null) if [ "x$(echo $out | awk '{print $2}')" != "x0" ] && [ "x$(echo $out | awk '{print $2}')" != "x" ] then echo "$(ps -p $(echo $i | cut -d'/' -f3) | tail -n 1 | awk '{print $4'}): $(echo $out | awk '{print $2 $3}')" fi done

當然，交換中的頁面可能已經存在很長時間了，自從使用一次后，后面就沒有在用過。為了獲取實時交換分區情況，我們可以用vmstat：

vmstat 1 10

在這個服務器上，我們可以看到mysqld沒有使用交換，如果系統內存充足，但是mysqld還占用了部分交換分區，是怎么回事？怎么排查呢？

如果遇到這種情況，可能的直接原因有swappiness和Numa。

Swappiness

swappiness參數控制內核將進程移出物理內存并將其放入交換磁盤分區的趨勢。我們之前也說過了磁盤IO操作要比RAM慢很多很多，因此如果進程過于頻繁地從內存中置換出，這會導致系統和應用程序的響應時間變慢。高swappiness值意味著內核更容易取消內存頁面。低swappiness相反，內核將不太容易取消內存頁面。swappiness值越高，系統內存置換的越多。

linux下系統（CentOS、Red Hat、ubuntu）默認的swappiness值為60。如果內存較小則應適當調高這個值。對于內存足夠的MySQL服務器，這個默認設置就有點太高了，應該減少。一般情況下，業界建議這個值可以設置到5.或者更小。設置swappiness方法是使用sysctl命令直接改變內核參數。

sysctl -w vn.swappinness = 1

NUMA設置

還有一個方面就是NUMA設置。對于具有多個NUMA核心的服務器，建議將NUMA模式設置為交錯，以平衡所有節點的內存分配。 在***的MySQL 8.0中支持為InnoDB設置NUMA。可以在配置通過啟動：innodb_numa_interleave = 1

要檢查是否有多個NUMA節點，可以使用numactl -H

這是兩種不同的輸出：

我們可以看到，當有多個NUMA節點（下）時，默認情況下，內存不會在所有節點之間平均分配。這可以導致更多內存置換。

文件系統緩存

默認情況下，Linux將使用文件系統會對所有的I/O操作進行緩存（這是不建議使用MyISAM的原因之一，MyISAM存儲引擎依賴于FS緩存，并且可能導致丟失數據）。Mysql InnoDB引擎中使用O_DIRECT作為innodb_flush_method，MySQL將繞過文件系統緩存，不會將任何FS Cache Memory用于數據文件（* .ibd）。

當然在MySQL中使用的其他非數據文件仍會使用FS Cache。我們來看個例子：

dbsake fincore binlog.000017 binlog.000017: total_pages=120841 cached=50556 percent=41.84 ls -lh binlog.000017 -rw-r----- 1 mysql mysql 473M Sep 18 07:17 binlog.000017 free -m total used free shared buffers cached Mem: 5965 4608 1356 128 435 2456 -/+ buffers/cache: 1716 4249 Swap: 2045 30 2015 dbsake uncache binlog.000017 Uncached binlog.000017 # free -m total used free shared buffers cached Mem: 5965 4413 1552 128 435 2259 -/+ buffers/cache: 1718 4247 Swap: 2045 30 2015

開始檢查文件系統緩存中存在多少二進制日志（使用dbsake fincore），我們可以看到473M中有42%使用RAM作為FS緩存。然后我強制取消在緩存中使用這些頁面（使用fincore uncache），結果，我們釋放了+/- 195MB的RAM。

關于MySQL的內存和相關問題排查是怎樣的問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。