2021-05-12 14:32:11
Linux Swap使用分析
Linux作業系統效能分析主要包含磁碟IO、CPU、記憶體以及網路流量,而這裡主要針對系統記憶體的使用進程情況做個分析。
一、如何檢視系統記憶體使用情況
1、根據常用命令檢視系統記憶體使用概況
free -g
total used free shared buffers cached
Mem: 31 31 0 0 0 3
-/+ buffers/cache: 28 3
Swap: 15 7 7
(根據free命令可以看到,系統使用了28G的實體記憶體,3G的剩餘記憶體,其中swap總15G,已使用7G)
top (f p M)
top - 14:18:50 up 1280 days, 7:15, 1 user, load average: 1.05, 1.25, 1.12
Tasks: 229 total, 1 running, 227 sleeping, 0 stopped, 1 zombie
Cpu(s): 0.2%us, 0.1%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 32949816k total, 32848840k used, 100976k free, 169308k buffers
Swap: 16771776k total, 8384616k used, 8387160k free, 3276360k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ SWAP DATA COMMAND
12428 mysql 15 0 22.2g 20g 3964 S 3.3 66.5 91946:06 1.3g 22g mysqld
22840 cyldj 15 0 9059m 6.7g 9012 S 0.0 21.5 22:05.42 2.1g 8.7g DBAgent
28689 root 15 0 358m 30m 3036 S 0.0 0.1 187:37.41 328m 137m salt-minion
30768 cyldj 21 0 462m 10m 1908 S 0.0 0.0 10:44.60 451m 373m java
22567 root 15 0 86004 3292 2576 S 0.0 0.0 0:00.01 80m 688 sshd
28690 root 20 0 267m 2188 704 S 0.0 0.0 0:00.00 264m 47m salt-minion
661 root 18 0 16340 1836 1632 S 0.0 0.0 0:47.42 14m 308 zabbix_agentd
22569 root 15 0 68156 1520 1188 S 0.0 0.0 0:00.02 65m 408 bash
2901 root 18 0 197m 1336 884 S 0.0 0.0 4:04.57 196m 174m AxisAgent
11236 root 15 0 60672 1324 760 S 0.0 0.0 2:01.21 57m 608 sshd
665 root 15 0 18432 1260 992 S 0.0 0.0 11:39.82 16m 308 zabbix_agentd
662 root 15 0 18432 1256 992 S 0.0 0.0 11:43.36 16m 308 zabbix_agentd
(根據top命令可以看到使用記憶體最大的進程是mysql進程,其次是dbagent,其中dbagent使用的交換分割區較多)
nmon (m)
nmon下載地址:
https://sourceforge.net/projects/nmon/files/nmon_x86_64_rhel5/download (RHEL5)
https://sourceforge.net/projects/nmon/files/nmon_linux_14i_newer_Linux_versions.tar.gz/download (RHEL6)
(通過nmon可以看到記憶體的詳細分配情況,其中總記憶體為32177.6 MB,總swap 16378.7 MB ,空閒93.4 MB,可回收3188.2+166.5 MB,已使用交換分割區7273.6MB,已使用的活動資料大小為30099.9MB,可以被交換出記憶體的資料大小為1590.7 MB)
2、根據系統監控檢視系統記憶體使用情況
(近7天的記憶體使用情況)
3、檢視指定進程的系統記憶體使用資訊
cat /proc/22840/statm
#virt res shr text lib data dt
2319113 1768037 2253 3836 0 2292997 0
(上述是檢視dbagent的記憶體使用資訊,其中單位是頁數,所以要看系統頁大小4K,第一列是虛擬記憶體2319113頁,第二列是駐留記憶體1768037頁,第三列是共用記憶體2253頁,進程獨佔記憶體大小為res-shr)
getconf PAGESIZE
4096
awk '/^Swap:/ {SWAP+=$2}END{print SWAP" KB"}' /proc/${pid}/smap
for i in `cd /proc;ls |grep "^[0-9]"|awk ' $0 >100'` ;do awk '/Swap:/{a=a+$2}END{print '"$i"',a/1024"M"}' /proc/$i/smaps ;done |sort -k2nr
(上述命令可以檢視進程虛擬記憶體使用情況)
cat /proc/22840/status |grep Vm
VmPeak: 9341632 kB
VmSize: 9276452 kB
VmLck: 0 kB
VmHWM: 7074296 kB
VmRSS: 7073540 kB
VmData: 9171904 kB
VmStk: 84 kB
VmExe: 15344 kB
VmLib: 4728 kB
VmPTE: 15596 kB
(上述命令可以檢視指定進程的記憶體使用情況VmSize表示虛擬記憶體大小,VmRSS表示駐留記憶體大小)
二、綜合分析MYSQL資料庫記憶體使用情況
sh show_mem_usage.sh
全域性記憶體大小:18592.00 MB
單執行緒最大記憶體:25.18 MB
最大執行緒佔用記憶體: 8815.62 MB
歷史最大執行緒佔用記憶體: 5213.81 MB
Innodb Buffer Pool使用率: 99.00%
從mysql的記憶體使用和總的實體記憶體使用來看,伺服器的記憶體使用已經基本達到上限(mysql駐留記憶體大約是21G,dbagent大約為7G,物理總記憶體為31G,快取了3G,大約有2G左右的非活動區記憶體),當mysql進程、dbagent使用超過5G記憶體,實體記憶體不夠,就會使用到了swap分割區。
三、什麼情況下會使用swap分割區
1、實體記憶體確實不夠用的情況下,會使用到swap分割區。
2、實體記憶體還有足夠的記憶體使用,比如cache,buffer的剩餘較多的情況下使用了swap分割區
四、使用swap分割區擴充套件
如果有足夠的實體記憶體,依舊使用了swap分割區,可以從以下幾方面檢視為什麼使用了swap分割區
1、swap分割區比例調整
cat /etc/sysctl.conf |grep swap
vm.swappiness=0
設定為0表示優先最大限度的使用實體記憶體快取資料,而不是磁碟作為分割區,值越大越不利於實體記憶體的充分利用
2、numa陷阱
為了提高cpu和記憶體的資料存取速度、並行度,設計了numa架構,但如果numa的記憶體分配策略不合理,那麼將會嚴重影響到記憶體的使用,尤其是對大記憶體塊使用的資料庫伺服器。
#numactl --hardware
available: 2 nodes (0-1)
node 0 size: 16160 MB
node 0 free: 15 MB
node 1 size: 16131 MB
node 1 free: 78 MB
node distances:
node 0 1
0: 10 20
1: 20 10
(上述命令可以檢視各個node節點的實體記憶體分配情況,可以看到兩節點的記憶體分配比例基本平均,如果node0節點free和和node1的free值相差較大,說明分配策略存在問題,很大可能會帶來swap使用,而實體記憶體空閒的狀態)
也可以通過檢視numastat檢視numa的miss和hit比例來進一步確認
#numastat
node0 node1
numa_hit 39150779957 38736256884
numa_miss 2658848763 8851827358
numa_foreign 8851827296 2658848763
interleave_hit 122652306 137287417
local_node 39096884744 38598664497
other_node 2712743976 8989419745
3、解決方案
(1)啟用大頁管理
(2)關閉numa
***BIOS關閉NUMA
***啟動核心關閉:
vi /boot/grub/grub.conf
kernel /boot/vmlinuz-2.6.18-128.1.16.0.1.el5 root=LABEL=DBSYS ro bootarea=dbsys rhgb quiet console=ttyS0,115200n8 console=tty1 crashkernel=128M@16M numa=off
重新啟動作業系統,通過cat /proc/cmdline和numactl --hardware檢視是否關閉
(3)調整核心引數
核心引數:zone_reclaim_mode,如果為0的話,那麼系統會傾向於從其他節點分配記憶體,如果是1表示系統會傾向於從本地節點回收Cache記憶體多數時候
vm.swappiness=0
echo 0 > /proc/sys/vm/zone_reclaim_mode ; echo "vm.zone_reclaim_mode = 0" >> /etc/sysctl.conf
(4)調整核心引數
Mysql可以調整相關引數、交叉啟動方式來改善numa,例如numactl --interleave=all /etc/init.d/mysql start
localalloc規定進程從當前node上請求分配記憶體;
preferred比較寬鬆地指定了一個推薦的node來獲取記憶體,如果被推薦的node上沒有足夠記憶體,進程可以嘗試別的node。
membind可以指定若干個node,進程只能從這些指定的node上請求分配記憶體。
interleave規定進程從指定的若干個node上以RR(Round Robin 輪詢排程)演算法交織地請求分配記憶體。
#NUMA support
numa_interleave = 1 innodb_buffer_pool_populate = 1 flush_caches=1
https://www.percona.com/doc/percona-server/5.5/performance/innodb_numa_support.html
本文永久更新連結地址:http://www.linuxidc.com/Linux/2017-11/148513.htm
相關文章