這篇文章主要介紹“如何理解case的排查過程”，在日常操作中，相信很多人在如何理解case的排查過程問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”如何理解case的排查過程”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！
創(chuàng)新互聯(lián)主要從事網(wǎng)站設(shè)計(jì)、成都做網(wǎng)站、網(wǎng)頁設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)二七,10多年網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):028-86922220
如上圖所示，記錄顯示為申請 4G 內(nèi)存失?。?code>4294967296 B / 1024 / 1024 = 4096 M）。
重慶分公司
重慶分公司
min_free_kbytes & nr_hugepage 配置錯(cuò)誤？vm.min_free_kbytes & nr_hugepage 導(dǎo)致的free大于available案例有關(guān)memfree 統(tǒng)計(jì)的是所有內(nèi)存的 free 內(nèi)存，而 memavailable 統(tǒng)計(jì)的是可以拿來給程序用的內(nèi)存，而客戶設(shè)置了 vm.min_free_kbytes（2.5G），這個(gè)內(nèi)存在 free 統(tǒng)計(jì)，但是不在 memavailable 統(tǒng)計(jì)，nr_hugepage 也會(huì)有這個(gè)問題。
二者的統(tǒng)計(jì)方式不一樣， 具體參考 Documentation/filesystems/proc.txt
free -m && sysctl -p && /proc/meminfo 等信息分析問題。HugePages_Total 為0，說明沒有設(shè)置 nr_hugepage。MemAvailable: 7418172 kB， 說明這么多內(nèi)存可用。# sysctl -p
net.ipv4.ip_forward = 0
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 1
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
...
net.ipv4.tcp_tw_recycle=1
net.ipv4.tcp_max_syn_backlog=4096
net.core.netdev_max_backlog=10000
vm.overcommit_memory=2
...
#cat /proc/meminfo
MemTotal: 8009416 kB
MemFree: 7347684 kB
MemAvailable: 7418172 kB
Buffers: 18924 kB
Cached: 262836 kB
SwapCached: 0 kB
Active: 315188 kB
Inactive: 222364 kB
Active(anon): 256120 kB
Inactive(anon): 552 kB
Active(file): 59068 kB
Inactive(file): 221812 kB
....
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 114560 kB
DirectMap2M: 4079616 kB
DirectMap1G: 6291456 kB
java命令，去申請超出我的測試機(jī)物理內(nèi)存，拿到報(bào)錯(cuò)。實(shí)際上面的meminfo已經(jīng)說明了問題，但是由于經(jīng)驗(yàn)不足，一時(shí)沒有看明白怎么回事。
下面測試證明正常申請內(nèi)存不會(huì)有問題，超額的內(nèi)存才會(huì) OOM。
[root@test ~]# java -Xms4096M -version
openjdk version "1.8.0_242"
OpenJDK Runtime Environment (build 1.8.0_242-b08)
OpenJDK 64-Bit Server VM (build 25.242-b08, mixed mode)
[root@test ~]# java -Xms5000M -version
OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x0000000687800000, 3495428096, 0) failed; error='Cannot allocate memory' (errno=12)
......
系統(tǒng)信息如下：
--------------- S Y S T E M ---------------
OS:CentOS Linux release 7.4.1708 (Core)
uname:Linux 3.10.0-693.2.2.el7.x86_64 #1 SMP Tue Sep 12 22:26:13 UTC 2017 x86_64
libc:glibc 2.17 NPTL 2.17
rlimit: STACK 8192k, CORE 0k, NPROC 15088, NOFILE 65535, AS infinity
load average:0.05 0.05 0.05
/proc/meminfo:
MemTotal: 3881692 kB
MemFree: 2567724 kB
MemAvailable: 2968640 kB
Buffers: 69016 kB
Cached: 536116 kB
SwapCached: 0 kB
Active: 355280 kB
Inactive: 326020 kB
...
VmallocTotal: 34359738367 kB
VmallocUsed: 14280 kB
VmallocChunk: 34359715580 kB
HardwareCorrupted: 0 kB
AnonHugePages: 30720 kB
HugePages_Total: 256
HugePages_Free: 256
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 57216 kB
DirectMap2M: 3088384 kB
DirectMap1G: 3145728 kB
....
Memory: 4k page, physical 3881692k(2567600k free), swap 0k(0k free)
vm_info: OpenJDK 64-Bit Server VM (25.242-b08) for linux-amd64 JRE (1.8.0_242-b08), built on Jan 28 2020 14:28:22 by "mockbuild" with gcc 4.8.5 20150623 (Red Hat 4.8.5-39)
time: Thu Feb 20 15:13:30 2020
timezone: CST
elapsed time: 0 seconds (0d 0h 0m 0s)
Java 測試證明正常申請內(nèi)存不會(huì)有問題，超額的內(nèi)存才會(huì) OOM，那么為什么超額呢，視線回歸到 sysctl -p 有所發(fā)現(xiàn)。vm.overcommit_memory=2
關(guān)于 overcommit_memory 設(shè)置項(xiàng)：
默認(rèn)設(shè)置，當(dāng)應(yīng)用進(jìn)程嘗試申請內(nèi)存時(shí)，內(nèi)核會(huì)做一個(gè)檢測。內(nèi)核將檢查是否有足夠的可用內(nèi)存供應(yīng)用進(jìn)程使用；
如果有足夠的可用內(nèi)存，內(nèi)存申請?jiān)试S；否則，內(nèi)存申請失敗，并把錯(cuò)誤返回給應(yīng)用進(jìn)程。
舉個(gè)例子，比如1G的機(jī)器，A進(jìn)程已經(jīng)使用了500M，當(dāng)有另外進(jìn)程嘗試malloc 500M的內(nèi)存時(shí)，內(nèi)核就會(huì)進(jìn)行check，發(fā)現(xiàn)超出剩余可用內(nèi)存，就會(huì)提示失敗。
對于內(nèi)存的申請請求，內(nèi)核不會(huì)做任何check，直到物理內(nèi)存用完，觸發(fā) OOM 殺用戶態(tài)進(jìn)程。
同樣是上面的例子，1G 的機(jī)器，A進(jìn)程500M，B進(jìn)程嘗試 malloc 500M，會(huì)成功，但是一旦kernel發(fā)現(xiàn)內(nèi)存使用率接近1個(gè)G(內(nèi)核有策略)，就觸發(fā)OOM，殺掉一些用戶態(tài)的進(jìn)程(有策略的殺)。
當(dāng)請求申請的內(nèi)存 >= SWAP內(nèi)存大小 + 物理內(nèi)存 * N，則拒絕此次內(nèi)存申請。解釋下這個(gè)N：N是一個(gè)百分比，根據(jù)overcommit_ratio/100來確定，比如overcommit_ratio=50（我的測試機(jī)默認(rèn)50%），那么N就是50%。 vm.overcommit_ratio 只有當(dāng) vm.overcommit_memory = 2 的時(shí)候才會(huì)生效，內(nèi)存可申請內(nèi)存為 SWAP內(nèi)存大小 + 物理內(nèi)存 * overcommit_ratio/100。
看看上面日志的 overcommit 信息：
具體而言：
vm.overcommit_memory=2時(shí)候生效），具體的值是：SWAP內(nèi)存大?。╡cs均未開啟） + 物理內(nèi)存 * overcommit_ratio / 100；5，兩相對照，說明客戶設(shè)置的 vm.overcommit_memory在生效，建議改回 0 再試試。
vm.overcommit_memory = 2 測試，分配內(nèi)存失??；[root@test ~]# grep -i commit /proc/meminfo
CommitLimit: 1940844 kB
Committed_AS: 480352 kB
# java -Xms2048M -version 失敗了
OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x0000000080000000, 1431830528, 0) failed; error='Cannot allocate memory' (errno=12)
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 1431830528 bytes for committing reserved memory.
# An error report file with more information is saved as:
# /root/hs_err_pid1267.log
vm.overcommit_memory = 0, vm.overcommit_ratio = 50#vm.overcommit_memory = 0
#vm.overcommit_ratio = 50
[root@test ~]# java -Xms2048M -version
openjdk version "1.8.0_242"
OpenJDK Runtime Environment (build 1.8.0_242-b08)
OpenJDK 64-Bit Server VM (build 25.242-b08, mixed mode)到此，關(guān)于“如何理解case的排查過程”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！
