如何理解case的排查過(guò)程

這篇文章主要介紹“如何理解case的排查過(guò)程”，在日常操作中，相信很多人在如何理解case的排查過(guò)程問(wèn)題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”如何理解case的排查過(guò)程”的疑惑有所幫助！接下來(lái)，請(qǐng)跟著小編一起來(lái)學(xué)習(xí)吧！

具體過(guò)程

如上圖所示，記錄顯示為申請(qǐng) 4G 內(nèi)存失?。?code>4294967296 B / 1024 / 1024 = 4096 M）。

是否是 min_free_kbytes & nr_hugepage 配置錯(cuò)誤？

1. 第一反應(yīng)是想起來(lái)之前的  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ì)的是可以拿來(lái)給程序用的內(nèi)存，而客戶設(shè)置了 vm.min_free_kbytes（2.5G），這個(gè)內(nèi)存在 free 統(tǒng)計(jì)，但是不在 memavailable 統(tǒng)計(jì)，nr_hugepage 也會(huì)有這個(gè)問(wèn)題。

二者的統(tǒng)計(jì)方式不一樣， 具體參考 Documentation/filesystems/proc.txt

• MemFree: The sum of LowFree+HighFree
• MemAvailable: An estimate of how much memory is available for starting new applications, without swapping. Calculated from MemFree, SReclaimable, the size of the file LRU lists, and the low watermarks in each zone. The estimate takes into account that the system needs some page cache to function well, and that not all reclaimable slab will be reclaimable, due to items being in use. The impact of those factors will vary from system to system.

2. 跟客戶要  free -m && sysctl -p && /proc/meminfo 等信息分析問(wèn)題。

• HugePages_Total 為0，說(shuō)明沒(méi)有設(shè)置  nr_hugepage。
• MemAvailable: 7418172 kB， 說(shuō)明這么多內(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

嘗試重現(xiàn)

3. 嘗試自行測(cè)試使用 java命令，去申請(qǐng)超出我的測(cè)試機(jī)物理內(nèi)存，拿到報(bào)錯(cuò)。

實(shí)際上面的meminfo已經(jīng)說(shuō)明了問(wèn)題，但是由于經(jīng)驗(yàn)不足，一時(shí)沒(méi)有看明白怎么回事。

下面測(cè)試證明正常申請(qǐng)內(nèi)存不會(huì)有問(wèn)題，超額的內(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)

重現(xiàn)失敗，繼續(xù)分析

4. Java 測(cè)試證明正常申請(qǐng)內(nèi)存不會(huì)有問(wèn)題，超額的內(nèi)存才會(huì) OOM，那么為什么超額呢，視線回歸到  sysctl -p 有所發(fā)現(xiàn)。

vm.overcommit_memory=2

關(guān)于 overcommit_memory 設(shè)置項(xiàng)：

overcommit_memory=0

默認(rèn)設(shè)置，當(dāng)應(yīng)用進(jìn)程嘗試申請(qǐng)內(nèi)存時(shí)，內(nèi)核會(huì)做一個(gè)檢測(cè)。內(nèi)核將檢查是否有足夠的可用內(nèi)存供應(yīng)用進(jìn)程使用；

如果有足夠的可用內(nèi)存，內(nèi)存申請(qǐng)?jiān)试S；否則，內(nèi)存申請(qǐng)失敗，并把錯(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ì)提示失敗。

overcommit_memory=1

對(duì)于內(nèi)存的申請(qǐng)請(qǐng)求，內(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)程(有策略的殺)。

overcommit_memory=2

當(dāng)請(qǐng)求申請(qǐng)的內(nèi)存 >= SWAP內(nèi)存大小 + 物理內(nèi)存 * N，則拒絕此次內(nèi)存申請(qǐng)。解釋下這個(gè)N：N是一個(gè)百分比，根據(jù)overcommit_ratio/100來(lái)確定，比如overcommit_ratio=50（我的測(cè)試機(jī)默認(rèn)50%），那么N就是50%。 vm.overcommit_ratio 只有當(dāng) vm.overcommit_memory = 2 的時(shí)候才會(huì)生效，內(nèi)存可申請(qǐng)內(nèi)存為 SWAP內(nèi)存大小 + 物理內(nèi)存 * overcommit_ratio/100。

看看上面日志的 overcommit 信息：

• CommitLimit: 4004708 kB （小于客戶申請(qǐng)的4096M）
• Committed_AS: 2061568 kB

具體而言：

• CommitLimit：最大能分配的內(nèi)存（測(cè)試下來(lái)在 vm.overcommit_memory=2時(shí)候生效），具體的值是：SWAP內(nèi)存大小（ecs均未開(kāi)啟） + 物理內(nèi)存 * overcommit_ratio / 100；
• Committed_AS：當(dāng)前已經(jīng)分配的內(nèi)存大?。?/section>

5，兩相對(duì)照，說(shuō)明客戶設(shè)置的 vm.overcommit_memory在生效，建議改回 0 再試試。

• 用  vm.overcommit_memory = 2 測(cè)試，分配內(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

• 用如下配置，即可恢復(fù)：  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的排查過(guò)程”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注億速云網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)?lái)更多實(shí)用的文章！