线上预估服务节前升级到线上,元旦假期出现了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 是文件数据的缓存,它们既会用在读请求中,也会用在写请求中。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。