日更系列：一次线上服务内存问题

线上预估服务节前升级到线上，元旦假期出现了P99耗时超过检测阈值。因为正值节假日应用商店流量都有增长，便直观想简单扩容进行解决。但是简单看了下观察了cpu和内存，都是不忙。然后再细看内存里的各种统计指标。有两项指标MEM实际使用率和MEM CACHED这两项几乎涨到了物理内存的上限。实际使用率使用到了90%。观察到上涨的时机正是预估模型每天更新时间点，而且涨了之后并不会跟随pv变化而明显变化。

自然想到排查模型加载和mem cached增长的关联，应用商店ctr预估训练模型可以达到30G以上。每次读文件到内存加载都会花费几分钟时间。而cached相当于free的buff/cache部分。

查了下资料：

Buffers 是内核缓冲区用到的内存，对应的是 /proc/meminfo 中的 Buffers 值。

Cache 是内核页缓存和 Slab 用到的内存，对应的是 /proc/meminfo 中的 Cached 与 SReclaimable 之和。

Buffers 是对原始磁盘块的临时存储，也就是用来缓存磁盘的数据，通常不会特别大（20MB 左右）。这样，内核就可以把分散的写集中起来，统一优化磁盘的写入，比如可以把多次小的写合并成单次大的写等等。

Cached 是从磁盘读取文件的页缓存，也就是用来缓存从文件读取的数据。这样，下次访问这些文件数据时，就可以直接从内存中快速获取，而不需要再次访问缓慢的磁盘

事实上，proc 文件系统同时也是很多性能工具的最终数据来源。比如 free ，就是通过读取 /proc/meminfo ，得到内存的使用情况。

做个实验（写大文件），使用vmstat观察到mem的cache一直在涨：

# 首先清理缓存
$ echo 3 > /proc/sys/vm/drop_caches
# 然后运行 dd 命令向磁盘分区 /dev/sdb1 写入 2G 数据
$ dd if=/dev/urandom of=/dev/sdb1 bs=1M count=2048

再做个实验（读大文件），使用vmstat观察到mem的cache一直在涨：

# 首先清理缓存
$ echo 3 > /proc/sys/vm/drop_caches
# 运行 dd 命令读取文件数据
$ dd if=/tmp/file of=/dev/null

总结：

到这里问题就很明确了，服务加载大模型文件，消耗了大量的mem cached，但是这个内存cache不会随着文件读取结束而消失。内存cache大量占用导致后续有请求进来分配内存需要时都被delay了，所以请求p99耗时都明显增加了。

那么如何手动规避模型更新后的遗留问题呢？使用以下命令清理系统缓存：

# 清理文件页、目录项、Inodes 等各种缓存$ echo 3 > /proc/sys/vm/drop_caches

这里的 /proc/sys/vm/drop_caches ，就是通过 proc 文件系统修改内核行为的一个示例，写入 3 表示清理文件页、目录项、Inodes 等各种缓存。同时也学习到内存的一个知识：

Buffer 是对磁盘数据的缓存，而 Cache 是文件数据的缓存，它们既会用在读请求中，也会用在写请求中。