最近发现一则比较奇怪的业务性能抖动问题

简单来说，就是离线作业频繁的触发oom，导致在线业务指标陡增。理论上来说，离线作业触发自身硬限，不应该导致其他容器出问题才是

先来说一下我们的 memory cgroup 层级结构，可以简单理解为如下：

/cgroups/v2/kubepods/

/cgroups/v2/kubepods/online/a -> a为在线服务

/cgroups/v2/kubepods/offline/job1 -> job1 为离线服务

通常来说，为了解决混部的内存争抢问题，我们会对整个 offline 大框设置一个内存上限，防止离线作业使用内存太多，导致在线服务出现内存压力。这看起来似乎没什么问题。

不过最近一个问题，发现离线 job1 频繁 oom，引发了在线的性能抖动

最后定位的结论如下：

根因分析：nr_dying_descendants 的原因是由于容器被销毁时，容器内还有未完全回收干净的 page cache，所以内核不会立即释放这个 cgroup（用户态操作系统从 /cgroups 文件系统下已经看不到了，但是内核态的数据结构还在）

cat /cgroups/v2/kubepods/online/cgroup.stat

nr_descendants 10

nr_dying_descendants 4172

这就有一个问题，如果有大量的dying cgroups，内核在oom处理过程中：

我们在使用容器的过程中，可能会遇到一个问题，容器利用率很低，但是经常发生 oom，这是什么情况？

很可能是业务使用了一些不可回收的 page cache，其中最主要的应该就是 mlock

1. mlock 的背景

mlock 的作用就是防止页面被换出到 swap 分区，或者 page cache 被内核回收

由于线上服务器，基本默认都会关闭 swap 分区，所以这种情况暂不讨论，防止 page cache 被内核回首是主要作用

什么样的 page 需要 mlock？

1）通过 mmap 方式映射到内存中的 page cache，比如一些关键的索引数据，需要经常访问，那就得 mlock 住，否则 pgmajfault 带来的性能抖动是很大的

2）程序自身依赖的一些 so 动态链接库，由于内核的 page cache 回收算法，并不感知 page 具体是普通的文件 cache，还是 so 动态链接库，所以当容器内存不足时，内核通过一些粗略的回收算法回收 page cache，一旦把 so 的缓存页回收掉了，程序在调用相关函数时，会出现严重的性能抖动

因此，通过 mlock，显式的把一些关键的不希望被回收的 page cache 锁定起来，达到保证业务性能的目的

2. mlock 的内核实现

mlock 相关的系统调用可以参考：https://linux.die.net/man/2/mlock

2.1. unevictable 内存

cgroup 的 memory.stat 接口，包含一个容器内存使用的详细信息

cat /cgroups/v2/matrix/memory.stat 
anon 200723943424
file 158665015296
kernel_stack 0
slab 0
sock 229249024
shmem 4258582528
file_mapped 48234749952
file_dirty 8605696
file_writeback 0
inactive_anon 4258234368
active_anon 200570675200
inactive_file 73935654912
active_file 40680521728
unevictable 39942680576

其中 unevictable 表示不剔除的 page cache，mlock 属于 unevictable 的一部分，除此之外，unevictable 还有一些其他内存

本文内核代码版本：https://elixir.bootlin.com/linux/v4.14.281/source/mm/shmem.c

1. tmpfs 内存简介

tmpfs 文件系统是 pod 中常见的一种“存储”介质，也叫 ram disk，都是一个东西

tmpfs 的特殊的地方在于：

所以要讲 tmpfs 的话，就得把这两部分都讲清楚，一个是文件系统的实现，一个是底层“持久化”层内存的管理

通常应用程序之间会通过 tmpfs 文件系统来实现高效的数据共享

/dev/shm 就是一个最典型的 tmpfs 文件系统，是操作系统为了解决大多数程序数据共享而默认挂在的一个 tmpfs

2. tmpfs 文件系统的实现

我们知道 file 是linux内核最重要的设计，一切皆文件

除了普通的文件，平时我们接触到的，unix管道、socket、proc、cgroup 等等，都是基于文件的实现

为了实现灵活可扩展的文件系统架构，Linux设计了 virtual file system 抽象层，简称 vfs，对用户台程序屏蔽了所有具体的底层文件系统的实现细节，提供统一的文件系统接口

2.1. virtual file system 接口定义

https://www.kernel.org/doc/html/latest/filesystems/vfs.html

vfs 属于一个专题，我们这里不讲那么复杂，有时间可以专门展开讲

vfs 定义了文件系统实现最关键的2个接口：

inode_opertions 定义如下：

struct inode_operations {
    int (*create)(struct user_namespace*, struct inode*, struct dentry*, umode_t, bool);
    int (*symlink)(struct user_namespace*, struct inode*, struct dentry*, const char*);
    int (*mkdir)(struct user_namespace*, struct inode*, struct dentry*, umode_t);
    int (*rmdir)(struct inode*, struct dentry*); /* 省略一万字 */
};

是不是很熟悉？

file_operations 的定义如下：

struct file_operations {
    int (*open)(struct inode*, struct file*);
    loff_t (*llseek)(struct file*, loff_t, int);
    ssize_t (*read)(struct file*, char __user*, size_t, loff_t*);
    ssize_t (*write)(struct file*, const char __user*, size_t, loff_t*); /* 省略一万字 */
};

是不是也很熟悉？

内核 tmpfs 文件系统的源码：mm/shmem.c

tmpfs 其实并没有实现 vfs 中的所有接口，主要原因是因为由于绝大部分的 file system 底层实现其实都是一样的，没区别，所以内核为了简化文件系统的开发，把这些通用的实现都抽象出来，变成 generic_file_read/write 之类的通用实现

static const struct file_operations shmem_file_operations = { /* 普通文件的读、写、seek、fsync */ .mmap = shmem_mmap, .get_unmapped_area = shmem_get_unmapped_area, #ifdef CONFIG_TMPFS .llseek = shmem_file_llseek, .read_iter = shmem_file_read_iter, .write_iter = generic_file_write_iter, .fsync = noop_fsync, .splice_read = generic_file_splice_read, .splice_write = iter_file_splice_write, .fallocate = shmem_fallocate, #endif };
static const struct inode_operations shmem_inode_operations = { /* 这个是针对普通文件的 inode 操作 */ .getattr = shmem_getattr, .setattr = shmem_setattr, };
static const struct inode_operations shmem_dir_inode_operations = { /* 这个是针对目录的 inode 操作 */ #ifdef CONFIG_TMPFS .create = shmem_create, .lookup = simple_lookup, .link = shmem_link, .unlink = shmem_unlink, .symlink = shmem_symlink, .mkdir = shmem_mkdir, .rmdir = shmem_rmdir, .mknod = shmem_mknod, .rename = shmem_rename2, .tmpfile = shmem_tmpfile, #endif };

最近追查某线上服务发现一个问题：频繁的创建&删除目录或者文件，会消耗大量的物理内存。

原因是因为，目录或者文件删除后，dentry并没有立即释放，而是保存在了superblock上的lru链表上。通常只有内核认为内存紧张的时候才会回收此部分内存。

不过由于dentry结构非常小，这种case下内存增长是很慢。

// linux-2.6.32.68/fs/dcache.c
/*
 * dput - release a dentry
 * @dentry: dentry to release 
 *
 * Release a dentry. This will drop the usage count and if 
 * appropriate call the dentry unlink method as well as
 * removing it from the queues and releasing its resources. 
 * If the parent dentries were scheduled for release
 * they too may now get deleted.
 *
 * no dcache lock, please.
 */

void dput(struct dentry *dentry)
{
	if (!dentry)
		return;

repeat:
	if (atomic_read(&dentry->d_count) == 1)
		might_sleep();
	if (!atomic_dec_and_lock(&dentry->d_count, &dcache_lock))
		return;

	spin_lock(&dentry->d_lock);
	if (atomic_read(&dentry->d_count)) {
		spin_unlock(&dentry->d_lock);
		spin_unlock(&dcache_lock);
		return;
	}

	/*
	 * AV: ->d_delete() is _NOT_ allowed to block now.
	 */
	if (dentry->d_op && dentry->d_op->d_delete) {
		if (dentry->d_op->d_delete(dentry))
			goto unhash_it;
	}
	/* Unreachable? Get rid of it */
 	if (d_unhashed(dentry))
		goto kill_it;
  	if (list_empty(&dentry->d_lru)) {
  		dentry->d_flags |= DCACHE_REFERENCED;
                // 这里把dentry放到sb的lru链表里
		dentry_lru_add(dentry);
  	}
 	spin_unlock(&dentry->d_lock);
	spin_unlock(&dcache_lock);
	return;

unhash_it:
	__d_drop(dentry);
kill_it:
	/* if dentry was on the d_lru list delete it from there */
	dentry_lru_del(dentry);
	dentry = d_kill(dentry);
	if (dentry)
		goto repeat;
}

而内存回收有两种方式：

1. 内核发现内存不足时主动处罚。例如分配不了内存时，达到某种指定的阈值时等等。
2. 手动触发 sysctl vm.drop_caches。

这里只讨论第二种方法。内核在初始化的时候，注册了一个dcache_shrinker来释放dcache内存。shrink_dcache_memory的最主要的逻辑时prune_dcache()函数

static struct shrinker dcache_shrinker = {
	.shrink = shrink_dcache_memory,
	.seeks = DEFAULT_SEEKS,
};
static void __init dcache_init(void)
{
	int loop;
	/* 
	 * A constructor could be added for stable state like the lists,
	 * but it is probably not worth it because of the cache nature
	 * of the dcache. 
	 */
	dentry_cache = KMEM_CACHE(dentry,
		SLAB_RECLAIM_ACCOUNT|SLAB_PANIC|SLAB_MEM_SPREAD);
	// 注册钩子函数，当用户手动触发内存回收时，调用dcache_shrinker
	register_shrinker(&dcache_shrinker);
	/* ... */
}

以内核3.10.79为例。这里分析一下内核对于cgroup.memory进程组oom的过程，以及混部环境下需要什么样的oom策略。

触发时机

内核对于每个memory cgroup维护一个计数器，统计当前cgroup内已经使用了的内存。每当cgroup内进程创建页面时，页面大小所占用的内存就会通过res_counter_charge_locked()函数计入计数器里。而当内存占用超过memory.limit_in_bytes所设置的阈值时，charge失败，返回ENOMEN错误。

int res_counter_charge_locked(
struct res_counter *counter, unsigned long val, bool force)
{
        int ret = 0;
        if (counter->usage + val > counter->limit) {
                counter->failcnt++;
                ret = -ENOMEM;
                if (!force)
                        return ret;
        }
        counter->usage += val;
        if (counter->usage > counter->max_usage)
                counter->max_usage = counter->usage;
        return ret;
}

另外有一个问题需要注意的是，内存这个子系统是拓扑型控制的，不是平级控制的。下一级子系统的所有limit_in_bytes之和不能超过父亲的limit_in_bytes值，否则会设置失败。

所以内存计数的时候：

1. 进程新创建的页面，会被反向递归计入到所有的父cgroup下面。
2. memory子系统的根的计数一定是当前内核所有进程的内存使用之和。（注意，由于cgroup.memory对内存的统计和proc文件系统的统计方法不一致，所以这两个系统对于内存使用的值并不是完全对等的）

子cgroup也许内存配额有冗余，但父cgroup不一定会有冗余，所以在反向递归计数的时候，谁内存超过阈值了，就oom谁（选择这个cgroup下的某个进程kill掉，所以这里是有可能某个cgroup明明内存没有被超限但也会被莫名的干掉了）。