
我有一個在 Linux 伺服器上運行的 java 應用程序,物理記憶體(RAM)分配為 12GB,我會看到一段時間內的正常利用率,如下所示。
sys> free -h
total used free shared buff/cache available
Mem: 11G 7.8G 1.6G 9.0M 2.2G 3.5G
Swap: 0B 0B 0B
最近,在增加應用程式的負載時,我可以看到 RAM 利用率幾乎已滿,可用空間非常少,我可能會遇到一些緩慢的情況,但應用程式仍然可以正常工作。
sys> free -h
total used free shared buff/cache available
Mem: 11G 11G 134M 17M 411M 240M
Swap: 0B 0B 0B
sys> free -h
total used free shared buff/cache available
Mem: 11G 11G 145M 25M 373M 204M
Swap: 0B 0B 0B
我提到https://www.linuxatemyram.com/其中建議了以下幾點。
警告標誌您可能需要調查的真正內存不足的情況:
- 可用記憶體(或“空閒+緩衝區/快取”)接近零
- 使用的掉期增加或波動。
- dmesg | grep oom-killer 顯示 OutOfMemory-killer 的工作狀況
從以上幾點來看,我在應用程式層級沒有看到任何 OOM 問題,交換也被停用。所以忽略了這兩點。困擾我的一點是可用記憶體小於零,我需要澄清一下
問題:
- 如果available接近0,會導致系統崩潰嗎?
- 這是否意味著當可用記憶體變少時我需要升級 RAM?
- 應在什麼基礎上分配/增加 RAM 記憶體?
- 對於 RAM 記憶體分配,我們有需要遵循的官方建議/指南嗎?
答案1
能夠得到我的問題的答案
如果available接近0,會導致系統崩潰嗎?
在我的一台伺服器上進行測試時,我載入的記憶體幾乎已滿,如下所示
sys> free -h
total used free shared buff/cache available
Mem: 11G 11G 135M 25M 187M 45M
Swap: 0B 0B 0B
能夠單獨看到我的應用程式(消耗更多記憶體)被記憶體不足殺手殺死,可以在內核日誌中引用
dmesg -e
[355623.918401] [21805] 553000 21805 69 21 2 0 0 rm
[355623.921381] Out of memory: Kill process 11465 (java) score 205 or sacrifice child
[355623.925379] Killed process 11465 (java), UID 553000, total-vm:6372028kB, anon-rss:2485580kB, file-rss:0kB, shmem-rss:0kB
https://www.kernel.org/doc/gorman/html/understand/understand016.html
Out Of Memory Killer 或 OOM Killer 是 Linux 核心在系統記憶體嚴重不足時所使用的進程。出現這種情況是因為 Linux 核心為其進程分配了過多的記憶體。 ……這意味著正在運行的進程需要比物理可用記憶體更多的記憶體。