Linux内存变低会发生什么问题

技术最新也最全 2024-09-10 02:26:25

作者:cynrikluo

内存不是无限的,总有不够用的时候,linux内核用三个机制来处理这种情况:内存回收、内存规整、oom-kill。

当发现内存不足时,内核会先尝试内存回收,从一些进程手里拿回一些页;如果这样还是不能满足申请需求,则触发内存规整;再不行,则触发oom主动kill掉一个不太重要的进程,释放内存。

低内存情况下,内核的处理逻辑

内存申请的核心函数是__alloc_pages_nodemask:

/* * This is the 'heart' of the zoned buddy allocator. */struct page *__alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order, int preferred_nid, nodemask_t *nodemask){ struct page *page; unsigned int alloc_flags = ALLOC_WMARK_LOW; gfp_t alloc_mask; /* The gfp_t that was actually used for allocation */ struct alloc_context ac = { };

__alloc_pages_nodemask会先尝试调用get_page_from_freelist从伙伴系统的freelist里拿空闲页,如果能拿到就直接返回:

如果拿不到,则进入慢速路径:

__alloc_pages_slowpath,慢速路径,顾名思义,就是拿得慢一点,需要做一些操作以后再拿。

首先, __alloc_pages_slowpath会唤醒kswapd:

kswapd是一个守护进程,专门进行内存回收操作,执行路径:

它被唤醒后,会立1刻开始进行回收,效率高的话,freelist上会立刻多出很多空闲页。

所以 __alloc_pages_slowpath会马上再次尝试从freelist获取页面,获取成功则直接返回了。

若还是失败, __alloc_pages_slowpath则会进入direct_reclaim阶段:

direct_reclaim,顾名思义,就是直接内存回收,回收到的页不用放回freelist再get_page_from_freelist这么麻烦了,也不用唤醒某个进程帮忙回收,而是由当前进程(current)亲自下场去回收,执行路径:

如果direct_reclaim也回收不上来, __alloc_pages_slowpath还会垂死挣扎下,做一下内存规整,尝试把零散的页辗转腾挪,拼成为大order页(仅在申请order>0的页时有用)。

如果还是无法满足要求,则进入oom-kill了:

总结上面的逻辑:内存申请时,首先尝试直接从freelist里拿;失败了则先唤醒kswapd帮忙回收内存;若内存低到让kswapd也爱莫能助,则进入direct reclaim直接回收内存;若direct reclaim也无能为力,则oom:

三条水线

实际上,从freelist上拿页不是简单地直接拿,而是先检查下该zone是否满足水线要求,不满足那就直接失败。

内核给内存管理划了三条水线:MIN、LOW、HIGH。

三者大小关系从字面即可推断,MIN < LOW < HIGH。

在首次尝试从freelist拿页时,门槛水线是LOW;唤醒kswapd后再次尝试拿页,门槛水线是MIN。

所以实际逻辑如下:

所以,可以简单地认为,可用内存低于LOW水线时,唤醒kswapd;低于MIN水线时,进行direct reclaim;而HIGH水线,是kswapd的回收终止线:

为什么内存回收时,磁盘IO会被打满?

可以看到,kswapd和direct_reclaim最终都是走到了shrink_node:

shrink_node是内存回收的核心函数,顾名思义,让整个node进行一次“收缩”,把不要的数据清掉,空出空闲页。

get_scan_count决定本次扫描多少个anon page和file page。

anon page就是Anonymous Page,匿名页,是进程的堆栈、数据段等。内核回收匿名页时,将这些数据进行压缩(压缩比大概为3),然后移动到内存中的一个小角落中(swap空间),这个过程并没有与磁盘发生交互,因此不会产生IO,但需要压缩数据,所以耗CPU。

file page就是文件页,是进程的代码段、映射的文件。内核回收文件页时,先将“脏”数据回写到磁盘,然后释放掉这些缓存数据,干净的数据则直接释放掉。这个过程涉及到写磁盘,因此会产生IO。

简单总结一下get_scan_count的逻辑:

所以说,不论开没开swap,内存回收都是倾向于回收file page。

如果file page中有脏页,那内存回收大概率就会产生一些IO,无非是IO量多少罢了。

以下情况IO可能会打满或者暴增当前内存不是特别紧张,但low、min水线设置得太低,之前一直没怎么触发过内存回收,以致于脏页已经累积到大量,一触发回收,立刻就是回写大量脏页,导致IO暴增。内存极度紧张 (free 和available同时很低)。这种情况下,anon page远比file page多,这意味着可回收的内存很少,内核会对活跃数据下手,一些进程上一秒还用着的数据,这一秒可能就被不幸回收了,但下一秒马上又要被使用,会再次被读入内存。如此,同一份数据,内核就进行了多次回收和读入,IO就加倍了。为什么低内存有时会引发hungtask?

低内存时,通常不是个别进程触发了direct reclaim,而是大量进程都在direct reclaim。

大家都要回写脏页,于是IO被打满了。

这时候,进程会频繁地被IO阻塞,被阻塞的进程为了不占用CPU,会调用io_schedule_timeout或io_schedule来挂起自己,直到IO完成。

这种等待是D状态的,一旦超过了120S,就会触发hungtask。当然,这是非常极端的情况,IO已经完全没救的情况。

大部分时候,IO虽然打满了,但是总能周转过来,所以这些进程并不会等太久。

然而,这些进程若是来自同一个业务,则大概率会访问同一个数据,这就需要通过mutex、rwsem、semaphore等同步机制来控制访问行为。

而这些同步机制的基本接口都是uninterruptible性质的,以semaphore为例:

extern void down(struct semaphore *sem); // 基本接口。获取信号量,获取不到则进入uninterruptible睡眠extern int __must_check down_interruptible(struct semaphore *sem); // 其他接口extern int __must_check down_killable(struct semaphore *sem); // 其他接口extern int __must_check down_trylock(struct semaphore *sem); // 其他接口extern int __must_check down_timeout(struct semaphore *sem, long jiffies); // 其他接口

所谓uninterruptible性质,即当进程获取不到同步资源时,直接进入D状态等待其他进程释放资源。

其他同步资源,rwsem、mutex等,都有这样的uninterruptible性质接口。

正常情况下,只要持有同步资源的进程正常运行不卡顿,那么即使有上百个进程来争抢这些同步资源,对于排序靠后的进程来说,时间也是够的,一般不会等待超过120s。

但在低内存情况下,大家都在等IO,这些持有资源的进程也不能幸免,引发堵车连锁反应。

如果此时同步资源的waiter们已累计了几十个甚至上百个,那么就算只有一瞬间的io卡顿,排序靠后的waiter也容易等待超过120s,触发hungtask。

一个非常典型的案例,一台CVM在连续报了几条hungtask warning后,彻底无响应了,通过魔术建触发重启。

系统信息如下:

内存状况不容乐观,典型的低内存:

log上有很多hungtask warning,超时原因都是等rwsem太长,写者waiter和读者waiter都有:

这些进程在等同一个rwsem,这个rwsem的地址为:ffff880e9703f370

进一步探究,发现当前对ffff880e9703f370有引用的进程为19个,11个正在读,8个排队。

而这11个正在读的进程,都在做同一件事——direct reclaim,并且都卡在IO等待:

这11个进程,虽然也是D状态,但由于时不时能调度到IO,相当于D状态的持续时间不断重置,所以本身并没有触发hungtask。

而这8个waiter进程就没这个好运了,被前面11个进程你方唱罢我登场地阻塞,持续时间也没有机会重置,最终超过120s,引发hungtask了。

优化低内存处理

我们已经知道了低内存会导致IO突增,甚至导致hungtask,那要如何避免呢?

可以从两方面来避免。

1、调整脏页回刷频率。

将平时的脏页回刷频率调高,这样内存回收时,需要回收的脏页就更少,降低IO的增量。

调低 /proc/sys/vm/dirty_writeback_centisecs调低/proc/sys/vm/dirty_background_ratio

2、调高low水线和min水线。

调高水线,可以更早地进入内存回收逻辑,这样可以将free维持在一个较高水平,避免陷入极端场景。由于low和min同时受min_free_kbytes管控,所以可以直接调整min_free_kbytes值。

调高/proc/sys/vm/min_free_kbytes
0 阅读:0

技术最新也最全

简介:感谢大家的关注