未加星标

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

字体大小 | |
[系统(linux) 所属分类 系统(linux) | 发布者 店小二03 | 时间 2018 | 作者 红领巾 ] 0人收藏点击收藏
前言

之前在实习时,听了 OOM 的分享之后,就对 linux 内核内存管理充满兴趣,但是这块知识非常庞大,没有一定积累,不敢写下,担心误人子弟,所以经过一个一段时间的积累,对内核内存有一定了解之后,记录以及分享。


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

【OOM - Out of Memory】内存溢出

内存溢出的解决办法:

1、等比例缩小图片

2、对图片采用软引用,及时进行 recycle( ) 操作。

3、使用加载图片框架处理图片,如专业处理图片的 ImageLoader 图片加载框架,还有XUtils 的 BitMapUtils 来处理。

这篇文章主要是分析了单个进程空间的内存布局与分配,是从全局的视角分析下内核对内存的管理;

下面主要从以下方面介绍 Linux 内存管理:

进程的内存申请与分配; 内存耗尽之后 OOM; 申请的内存都在哪? 系统回收内存; 1、进程的内存申请与分配

之前有篇文章介绍 hello world 程序是如何载入内存以及是如何申请内存的,我在这,再次说明下:同样,还是先给出进程的地址空间,我觉得对于任何开发人员这张图是必须记住的,还有一张就是操作 disk ,memory 以及 cpu cache 的时间图。


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

当我们在终端启动一个程序时,终端进程调用 exec 函数将可执行文件载入内存,此时代码段,数据段,bbs 段,stack 段都通过 mmap 函数映射到内存空间,堆则要根据是否有在堆上申请内存来决定是否映射。

exec 执行之后,此时并未真正开始执行进程,而是将 cpu 控制权交给了动态链接库装载器,由它来将该进程需要的动态链接库装载进内存。之后才开始进程的执行,这个过程可以通过 strace 命令跟踪进程调用的系统函数来分析。


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

这是我上篇博客认识 pipe 中的程序,从这个输出过程,可以看出和我上述描述的一致。

当第一次调用 malloc 申请内存时,通过系统调用 brk 嵌入到内核,首先会进行一次判断,是否有关于堆的 vma,如果没有,则通过 mmap 匿名映射一块内存给堆,并建立 vma 结构,挂到 mm_struct 描述符上的红黑树和链表上。

然后回到用户态,通过内存分配器(ptmaloc,tcmalloc,jemalloc)算法将分配到的内存进行管理,返回给用户所需要的内存。

如果用户态申请大内存时,是直接调用 mmap 分配内存,此时返回给用户态的内存还是虚拟内存,直到第一次访问返回的内存时,才真正进行内存的分配。

其实通过 brk 返回的也是虚拟内存,但是经过内存分配器进行切割分配之后(切割就必须访问内存),全都分配到了物理内存

当进程在用户态通过调用 free 释放内存时,如果这块内存是通过 mmap 分配,则调用 munmap 直接返回给系统。

否则内存是先返回给内存分配器,然后由内存分配器统一返还给系统,这就是为什么当我们调用 free 回收内存之后,再次访问这块内存时,可能不会报错的原因。

当然,当整个进程退出之后,这个进程占用的内存都会归还给系统。

2、内存耗尽之后OOM

在实习期间,有一台测试机上的 mysql 实例经常被 oom 杀死,OOM(out of memory)即为系统在内存耗尽时的自我拯救措施,他会选择一个进程,将其杀死,释放出内存,很明显,哪个进程占用的内存最多,即最可能被杀死,但事实是这样的吗?

今天早上去上班,刚好碰到了一起 OOM,突然发现,OOM 一次,世界都安静下来了,哈哈,测试机上的 redis 被杀死了。


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

OOM 关键文件 oom_kill.c,里面介绍了当内存不够时,系统如何选择最应该被杀死的进程,选择因素有挺多的,除了进程占用的内存外,还有进程运行的时间,进程的优先级,是否为 root 用户进程,子进程个数和占用内存以及用户控制参数 oom_adj 都相关。

当产生 oom 之后,函数 select_bad_process 会遍历所有进程,通过之前提到的那些因素,每个进程都会得到一个 oom_score 分数,分数最高,则被选为杀死的进程。

我们可以通过设置 /proc/<pid>/oom_adj 分数来干预系统选择杀死的进程。


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

这是内核关于这个oom_adj调整值的定义,最大可以调整为15,最小为-16,如果为-17,则该进程就像买了vip会员一样,不会被系统驱逐杀死了,因此,如果在一台机器上有跑很多服务器,且你不希望自己的服务被杀死的话,就可以设置自己服务的 oom_adj 为-17。

当然,说到这,就必须提到另一个参数 /proc/sys/vm/overcommit_memory,man proc 说明如下:


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

意思就是当 overcommit_memory 为0时,则为启发式oom,即当申请的虚拟内存不是很夸张的大于物理内存,则系统允许申请,但是当进程申请的虚拟内存很夸张的大于物理内存,则就会产生 OOM。

例如只有8g的物理内存,然后 redis 虚拟内存占用了24G,物理内存占用3g,如果这时执行 bgsave,子进程和父进程共享物理内存,但是虚拟内存是自己的,即子进程会申请24g的虚拟内存,这很夸张大于物理内存,就会产生一次OOM。

当 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 共享文件映射

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


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

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


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

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

ddif=/dev/zeroof=fileblockbs=Mcount=1024

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


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

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

3.2 私有文件映射段

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


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

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

echo1>>/proc/sys/vm/drop_caches

接着执行程序,看下内存使用情况:


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

从使用前和使用后对比,可以发现 used 和 buff/cache 分别增长了1G,说明当进行私有文件映射时,首先是将文件映射到 cache 中,然后如果某个文件对这个文件进行修改,则会从其他内存中分配一块内存先将文件数据拷贝至新分配的内存,然后再在新分配的内存上进行修改,这也就是写时复制。

这也很好理解,因为如果同一个可执行文件开启多个实例,那么内核先将这个可执行的数据段映射到 cache,然后每个实例如果有修改数据段,则都将分配一个一块内存存储数据段,毕竟数据段也是一个进程私有的。

通过上述分析,可以得出结论,如果是文件映射,则都是将文件映射到 cache 中,然后根据共享还是私有进行不同的操作。

3.3 私有匿名映射

像 bbs 段,堆,栈这些都是匿名映射,因为可执行文件中没有相应的段,而且必须是私有映射,否则如果当前进程 fork 出一个子进程,那么父子进程将会共享这些段,一个修改都会影响到彼此,这是不合理的。

ok,现在我把上述测试程序改成私有匿名映射


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

这时再来看下内存的使用情况


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

我们可以看到,只有 used 增加了1G,而 buff/cache 并没有增长;说明,在进行匿名私有映射时,并没有占用 cache,其实这也是有道理,因为就只有当前进程在使用这块这块内存,没有必要占用宝贵的 cache。

3.4 共享匿名映射

当我们需要在父子进程共享内存时,就可以用到 mmap 共享匿名映射,那么共享匿名映射的内存是存放在哪了?我继续改写上述测试程序为共享匿名映射 。


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

这时来看下内存的使用情况:


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

从上述结果,我们可以看出,只有buff/cache增长了1G,即当进行共享匿名映射时,这时是从 cache 中申请内存,道理也很明显,因为父子进程共享这块内存,共享匿名映射存在于 cache,然后每个进程再映射到彼此的虚存空间,这样即可操作的是同一块内存。

4、系统回收内存

当系统内存不足时,有两种方式进行内存释放,一种是手动的方式,另一种是系统自己触发的内存回收,先来看下手动触发方式。

echo1>>/proc/sys/vm/drop_caches 4.1 手动回收内存

手动回收内存,之前也有演示过,即

echo1>>/proc/sys/vm/drop_caches

我们可以在 man proc 下面看到关于这个的简介


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

从这个介绍可以看出,当 drop_caches 文件为1时,这时将释放 pagecache 中可释放的部分(有些 cache 是不能通过这个释放的),当 drop_caches 为2时,这时将释放 dentries 和 inodes 缓存,当 drop_caches 为3时,这同时释放上述两项。

关键还有最后一句,意思是说如果 pagecache 中有脏数据时,操作 drop_caches 是不能释放的,必须通过 sync 命令将脏数据刷新到磁盘,才能通过操作 drop_caches 释放 pagecache。

ok,之前有提到有些pagecache是不能通过drop_caches释放的,那么除了上述提文件映射和共享匿名映射外,还有有哪些东西是存在pagecache了?

4.2 tmpfs

我们先来看下 tmpfs ,tmpfs 和 procfs,sysfs 以及 ramfs 一样,都是基于内存的文件系统,tmpfs 和 ramfs 的区别就是 ramfs 的文件基于纯内存的,和 tmpfs 除了纯内存外,还会使用 swap 交换空间,以及 ramfs 可能会把内存耗尽,而 tmpfs 可以限定使用内存大小,可以用命令 df -T -h 查看系统一些文件系统,其中就有一些是 tmpfs,比较出名的是目录 /dev/shm

tmpfs 文件系统源文件在内核源码 mm/shmem.c,tmpfs实现很复杂,之前有介绍虚拟文件系统,基于 tmpfs 文件系统创建文件和其他基于磁盘的文件系统一样,也会有 inode,super_block,identry,file 等结构,区别主要是在读写上,因为读写才涉及到文件的载体是内存还是磁盘。

而 tmpfs 文件的读函数 shmem_file_read,过程主要为通过 inode 结构找到 address_space 地址空间,其实就是磁盘文件的 pagecache,然后通过读偏移定位cache 页以及页内偏移。

这时就可以直接从这个 pagecache 通过函数 __copy_to_user 将缓存页内数据拷贝到用户空间,当我们要读物的数据不pagecache中时,这时要判断是否在 swap 中,如果在则先将内存页 swap in,再读取。

tmpfs 文件的写函数 shmem_file_write,过程主要为先判断要写的页是否在内存中,如果在,则直接将用户态数据通过函数__copy_from_user拷贝至内核pagecache中覆盖老数据,并标为 dirty。

如果要写的数据不再内存中,则判断是否在swap 中,如果在,则先读取出来,用新数据覆盖老数据并标为脏,如果即不在内存也不在磁盘,则新生成一个 pagecache 存储用户数据。

由上面分析,我们知道基于 tmpfs 的文件也是使用 cache 的,我们可以在/dev/shm上创建一个文件来检测下:


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

看到了吧,cache 增长了1G,验证了 tmpfs 的确使用的 cache 内存。

其实 mmap 匿名映射原理也是用了 tmpfs,在 mm/mmap.c->do_mmap_pgoff 函数内部,有判断如果 file 结构为空以及为 SHARED 映射,则调用 shmem_zero_setup(vma) 函数在 tmpfs 上用新建一个文件


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

这里就解释了为什么共享匿名映射内存初始化为0了,但是我们知道用 mmap 分配的内存初始化为0,就是说 mmap 私有匿名映射也为0,那么体现在哪了?

这个在 do_mmap_pgoff 函数内部可没有体现出来,而是在缺页异常,然后分配一种特殊的初始化为0的页。

那么这个 tmpfs 占有的内存页可以回收吗?

本文系统(linux)相关术语:linux系统 鸟哥的linux私房菜 linux命令大全 linux操作系统

分页:12
转载请注明
本文标题:80%的 Linux 运维都不懂的内核问题
本站链接:https://www.codesec.net/view/620775.html


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 系统(linux) | 评论(0) | 阅读(10)