通过bpftrace 分析pagecache 占用

最新推荐文章于 2023-09-04 12:00:44 发布

garth_fan

最新推荐文章于 2023-09-04 12:00:44 发布

阅读量544

点赞数 1

文章标签： linux 缓存

本文链接：https://blog.csdn.net/qq_23868387/article/details/124590430

版权

一项目问题

某数据库服务器出现数据同步降速的情况，影响业务正常运行，排查发现256G内存仅有2G左右的空闲内存。

二内存占用分析

起初通过top分析内存占用情况可知dmserver驻留的物理内存较高：

图一

同时通过pmap分析dmserver进程的内存分布情况，可以确认数据进程大部分内存占用于anon(匿名页)：

图二

分析过程中，现场技术人员告知存在节点未起dmserver，内存也持续增长的情况。故怀疑系统本身或者其他应用可能存在内存泄露的情况，针对当前系统走查了可能存在内存泄露的几个基本组件，发现对应组件本身占用内存正常，并无内存异常增长的情况。然后分析/proc/meminfo的分布情况：

图三

针对内存泄露的分析核心在于匿名页的分配(malloc和mmap)，以及内核态slab内存缓存块分配器的变化情况，经过持续观察并未发现anonpage和slab有明显变化。但是active file却有缓慢变化且占用最多，这意味着文件页持续增加，可能存在进程读写文件时导致pagecache持续递增。

pagecache的设计存在于vfs层，针对每个文件都有自己的缓存，以页为单位，这样可以避免读写文件时直接访问物理设备，提升读写速率。

内核inode索引节点的成员i_mapping指向address_space（文件地址结构空间结构体），同时file实例结构体成员f_mapping也会指向address_sapce。可以理解address_space中存着每个文件pagecache的存储结构（基数树）。

以下为address_space的结构体信息:

图四

成员host指向索引节点

成员i_pages为基数树结构

成员nr_pages为文件地址空间对应的pagecache总和

针对pagecache的添加内核提供对应了函数接口：

int add_to_page_cache_lru(struct page *page, struct address_space *mapping,

pgoff_t offset, gfp_t gfp_mask)

这里可以利用bpftrace工具编写针对add_to_page_cache_lru函数的kprobe，然后输出对应address_space中pagecache总和:

bpftrace脚本如下:

#!/usr/bin/bpftrace
#include<linux/fs.h>
BEGIN
{
	printf("Tracing page cache add... 通过 Ctrl-C结束.\n");
	printf("PID COMM  PAGENUM \n");
}



kprobe:add_to_page_cache_lru
{
	$address=(struct address_space *)arg1;
	/*获取pagecache数量总和*/ 
	$page_num=$address->nrpages;
        /获取inod索引编号/
	$ino=$address->host->i_ino;
	/*通过定义page数组,统计进程以及pagecache数量和函数调用次数*/
	printf("%d %s %d %ld\n",pid,comm,($page_num+1),$ino);
	
}

	
END
{
	printf("bye!");
}

图五

运行对应脚本，追踪文件地址空间中当pagecache数量大于10000，输出进程信息，结果如下:

图六

进程号2300，进程rs:main（rsyslog线程）,pagecache数量1341243,同时还在持续增加。已知页大小为65536，通过1341243*65536/1024/1024/1024=81,说明该进程打开对应文件的文件页就有81G。尝试重启rsyslog服务，cache释放了90G左右。通过strace 追踪rsyslog线程的系统调用：