问题描述及分析

问题发现自一次对业务的性能分析中，发现add_to_page_cache_lry()->__add_to_page_cache_lock()->mem_cgroup_try_charge()->try_charge().... 调用栈存在较大CPU消耗。初步判断是cgroup对pagecache的管理带来了开销，影响IO性能。

cgroup mem 对pagecache的处理

Linux 使用LRU对pegecache进行管理，每个cgroup有其独立的LRU，其回收机制与Linux系统的回收机制类似，当cgroup内存（含匿名和文件映射，swap cache）达到限定值（memory.limit_in_bytes）会触发LRU上的内存回收。

参考链接：https://www.cnblogs.com/charlieroro/p/10180827.html

业务跑在docker里，并设置了cgroup memory 限制，高IO的业务特性导致其申请大量pagechage, 此时若系统内存充足cgroup mem使用很快达到上限，cgroup LRU上的pagecache会被经常回收，造成CPU消耗上升。

优化思路

cgroup mem 设计旨在限制cgroup内所有用到的内存包括：含匿名页，文件映射(pagecache)，swap cache 等等。然而对于一些实际应用，可能并不关注所有这些内存的使用，我们做限制的目的只是为了防止应用内存泄露或者申请大量匿名内存影响系统其它业务，对于pagecache没有限制的需求。pagecache已经在系统全局的LRU中管理了，各cgroup*竞争，看谁的文件数据热度高，谁的数据就被更多的保留在pagecache里，从整体效率来看也许是更好的策略。

所以去掉cgroup 对pagecache的管理并不会对我们的使用造成影响，还会降低因此带来的CPU开销。为了灵活配置考虑，实际优化中还是将该特性做成cgroup mem的选项，可动态设置是否需要cgroup统计pagecache。

测试效果

创建memory cgroup ， 并设置内存限制memory.limit_in_bytes=52428800（50MB），在cgroup内运行fio进行测试。

关闭cgroup mem 的pagecache统计，随机读IO性能提升约7%，连续读IO性能提升约10%，与火焰图中的CPU消耗占比基本一致。