是什么原因导致内核吞噬page_fault上的CPU？

Question

硬件/操作系统: linux 4.9，64G RAM。

16个后台进程正在运行。每个读取5GiB文件的随机短片段(100字节)，在守护进程启动时通过mmap()将其作为内存进行访问。每个守护进程读取自己的文件，因此总共有16个5GiB文件。

每个守护进程每秒可能进行10次读取。不是太多，磁盘负载相当小。

有时(5分钟内发生1个事件，没有周期，完全随机)一些随机的守护进程会在内核代码中使用下面的堆栈(见图) 300毫秒。这与大断层并不一致:大断层以每秒100…200的恒定速度移动。磁盘读取也是恒定的。

是什么导致了这种情况？

​

​

图片文本：__list_del_entry isolate_lru_pages.isra.48 shrink_inactive_list shrink_node_memcg shrink_node node_reclaim get_page_from_freelist enqueue_task_fair sched_clock __alloc_pages_nodemask alloc_pages_vma handle_mm_fault __do_page_fault page_fault

Answer 1

堆栈中有shrink_node和node_reclaim函数。调用它们来释放内存( free命令行工具将其显示为缓冲区/缓存)：https://www.kernel.org/doc/html/latest/admin-guide/mm/concepts.html#reclaim

释放可回收的物理内存页面并重新利用它们的过程称为(惊喜！)回收。Linux可以异步或同步回收页面，具体取决于系统的状态。当系统未加载时，大部分内存是空闲的，分配请求将立即从空闲页供应中得到满足。随着负载的增加，空闲页面的数量会下降，当它达到某个阈值(高水位线)时，分配请求将唤醒kswapd守护进程。它将异步扫描内存页面，如果内存页面包含的数据在其他地方可用，则将其释放，或者将其逐出到后备存储设备(还记得那些脏页面吗？)。随着内存使用量进一步增加并达到另一个阈值-最小水印-分配将触发直接回收。在这种情况下，分配会停止，直到回收足够的内存页来满足请求。

因此，您的64 GB RAM系统会出现没有剩余可用内存的情况。这个内存量足以容纳12个文件的副本，每个文件大小为5 GB，而您的守护进程使用16个文件。使用预读技术("Linux readahead: less tricks for more", ols 2007 pp273-284，man 2 readahead)，Linux可能会从文件中读取比应用程序所要求的更多的数据。MADV_SEQUENTIAL也可以打开这个机制，https://man7.org/linux/man-pages/man2/madvise.2.html

MADV\_SEQUENTIAL 期望按顺序进行页面引用。(因此，给定范围内的页面可以被积极地提前读取，并且可能在它们被访问后不久被释放。)

MADV_RANDOM

期望随机顺序的页面引用。(因此，预读可能没有正常情况下那么有用。)

不确定你的守护进程是如何打开和读取文件的，MADV_SEQUENTIAL对它们是否是活动的(或者这个标志是由glibc或其他库添加的)。另外，透明的巨型页面https://www.kernel.org/doc/html/latest/admin-guide/mm/transhuge.html也会有一些影响。普通的4.9内核是从2016年开始的，文件系统的扩展计划在2019年https://lwn.net/Articles/789159/，但如果你使用RHEL/CentOS，一些功能可能会被反向移植到4.9内核的分支中。

您应该定期检查free和cat /proc/meminfo输出，以检查守护进程和linux内核readahead是如何使用内存的。