80%的 Linux 运维都不懂的内核问题

当 overcommit_memory 为1时，则永远都允许 overmemory 内存申请，即不管你多大的虚拟内存申请都允许，但是当系统内存耗尽时，这时就会产生oom，即上述的redis例子，在 overcommit_memory=1 时，是不会产生oom 的，因为物理内存足够。

当 overcommit_memory 为2时，永远都不能超出某个限定额的内存申请，这个限定额为 swap+RAM* 系数（/proc/sys/vm/overcmmit_ratio，默认50%，可以自己调整），如果这么多资源已经用光，那么后面任何尝试申请内存的行为都会返回错误，这通常意味着此时没法运行任何新程序

以上就是 OOM 的内容，了解原理，以及如何根据自己的应用，合理的设置OOM。

3、系统申请的内存都在哪？

我们了解了一个进程的地址空间之后，是否会好奇，申请到的物理内存都存在哪了？可能很多人觉得，不就是物理内存吗？

我这里说申请的内存在哪，是因为物理内存有分为cache和普通物理内存，可以通过 free 命令查看，而且物理内存还有分 DMA，NORMAL，HIGH 三个区，这里主要分析cache和普通内存。

通过第一部分，我们知道一个进程的地址空间几乎都是 mmap 函数申请，有文件映射和匿名映射两种。

3.1 共享文件映射

我们先来看下代码段和动态链接库映射段，这两个都是属于共享文件映射，也就是说由同一个可执行文件启动的两个进程是共享这两个段，都是映射到同一块物理内存，那么这块内存在哪了？我写了个程序测试如下：

我们先看下当前系统的内存使用情况:

当我在本地新建一个1G的文件：

dd if=/dev/zero of=fileblock bs=M count=1024 

然后调用上述程序，进行共享文件映射,此时内存使用情况为：

我们可以发现，buff/cache 增长了大概1G，因此我们可以得出结论，代码段和动态链接库段是映射到内核cache中，也就是说当执行共享文件映射时，文件是先被读取到 cache 中，然后再映射到用户进程空间中。

3.2 私有文件映射段

对于进程空间中的数据段，其必须是私有文件映射，因为如果是共享文件映射，那么同一个可执行文件启动的两个进程，任何一个进程修改数据段，都将影响另一个进程了，我将上述测试程序改写成匿名文件映射：

在执行程序执行，需要先将之前的 cache 释放掉，否则会影响结果

echo 1 >> /proc/sys/vm/drop_caches 

（编辑：衢州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!