記憶體檔案系統的再學習
背景
言出法隨了.
昨天剛吐槽了 Linux會因為特殊的記憶體需求擠壓導致Java程序當機.
今天早上七點半一個 devops 驗證節點就出現了當機.
分析當機問題很簡單.
但是根據問題學習和整理更重要和更難一些.
想著能夠趁著這次自己手底下的當機出現. 將問題再整理歸納一下.
當機原因
七點半時, 系統壓力大, 導致被OOMkiller
檢視方式:
sar -r
00時00分01秒 kbmemfree kbavail kbmemused %memused kbbuffers kbcached kbcommit
06時50分02秒 403952 305152 49047800 99.18 176 2885544 54022920
07時00分01秒 349652 272956 49102100 99.29 176 2908056 53999316
07時10分03秒 409548 223676 49042204 99.17 176 2785008 54038912
07時20分03秒 321328 183412 49130424 99.35 176 2846744 54060264
07時30分02秒 31794708 32056468 17657044 35.71 172 3257904 23459236
07時40分01秒 31821648 32113984 17630104 35.65 172 3289108 23468024
可以看到 0720 時 基本上到了 99.35% 的最高值.
然後可以看到 buffer 是3G左右.
然後
dmesg -T |grep -i oom-killer -A 100
http-nio-5200-P invoked oom-killer: gfp_mask=0x6200ca(GFP_HIGHUSER_MOVABLE), nodemask=(null), order=0, oom_score_adj=0
[六 5月 11 07:27:22 2024] [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name
[六 5月 11 07:27:22 2024] [ 715] 0 715 110443 69459 917504 0 0 systemd-journal
[六 5月 11 07:27:22 2024] [ 751] 0 751 29767 1295 237568 0 -1000 systemd-udevd
檢視記憶體分佈-1
top 然後輸入大寫的M
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2726 gdm 20 0 9828400 5.1g 23504 S 0.0 10.9 3208:53 gnome-shell
7133 root 20 0 17.8g 4.0g 2720 S 0.0 8.5 5:45.59 java
2840 root 20 0 2086996 1.6g 2876 S 0.0 3.4 2064:10 redis-server
10195 root 20 0 2364352 418004 2992 S 0.0 0.8 6:48.30 gnome-software
發現 圖形化介面使用率較高.
還是的幹掉.
方式方法為:
systemctl stop gdm.service
systemctl disable gdm.service
systemctl status gdm.service
systemctl set-default multi-user.target
檢視記憶體分佈-2
df -Th 吸取 某專案的當機原因
發現這個裡面 /run 目錄下面的使用量較高
然後使用 pgcacher 檢視
發現有很多 journalctl 的日誌記錄資訊
解決方法為:
journalctl --vacuum-time=1d
journalctl --vacuum-size=1G
需要注意 應該也算是 CentOS的bug.
不過我不知道為啥我那麼多 systemd 的日誌記
需要排查一下.
pgcacher 圖片
記憶體檔案系統的再學習
df -Th |grep -v xfs |grep -v ext4
檔案系統 型別 容量 已用 可用 已用% 掛載點
devtmpfs devtmpfs 24G 0 24G 0% /dev
tmpfs tmpfs 24G 1.2M 24G 1% /dev/shm
tmpfs tmpfs 24G 82M 24G 1% /run
tmpfs tmpfs 24G 0 24G 0% /sys/fs/cgroup
tmpfs tmpfs 4.8G 5.7M 4.8G 1% /run/user/0
然後 free -g 為
total used free shared buff/cache available
Mem: 47 20 23 0 3 26
Swap: 0 0 0
發現記憶體檔案系統 不僅僅是 /tmp 目錄. 比如我這個系統 /tmp 竟然不是記憶體檔案系統
但是其他的目錄 比如
/dev 目錄 是 記憶體檔案系統, 更常用的是 /dev/null
系統一般適用來處理部分驅動裝置等.
/run 的話一般是很多程式存放 socket 檔案用的.
放到記憶體檔案裡面速度快.
/tmp 像是tomcat 也會將 執行緒資訊放進去. 這樣處理也是速度較快.
/sys 的話 就是系統管理的內容
/proc 其實一般也是記憶體檔案系統.
裡面的東西都存在於記憶體. 也是速度快
free top 等統計工具都是從 /proc 裡面後去資訊進行展示的
記憶體檔案系統是 linux 快速出具分析結果的方式方法.
但是不能過分使用. 尤其是如果有垃圾資料進入了記憶體檔案系統
其實會大量的佔用可用記憶體. 導致影響正常的生產工作
需要注意.