0x0 背景
我们的网站平台上提供了可定制的语言模型功能，用户在使用定制工具定制完成后，这些模型需要让语音识别服务能够访问到。 为了识别服务能够更快的加载这些资源文件，我们需要将资源同步到每台部署有语音识别服务端物理机器上。
我们快速搭建了一套同步的服务，就是上一篇中提及的resync-server,resync-broker和resync-agent。 我们在每台需要在本地使用这些资源的机器上启动了一个resync-agent，它的作用是实时地将定制平台上新产生的资源拉到本地。
考虑到新增物理机节点或者维护更新agent时需要下掉agent, 我们加入了一个补偿的机制，即在新初始化物理机和agent更新时使用rsync同步一遍用户定制的语言模型的目录。
0x1 现象
在某次我们加入这个rsync机制后，监控到机器可用的free内存持续下降，大量的内存被cache占用。由于我们的agent和识别服务是部署在同一台机器上，而语音识别服务本身对内存的要求又非常高，这个功能上线后，直接影响到了识别业务，
0x2 分析
我们知道linux通过cache机制提高磁盘的读写效率，但是这里我们更希望少占用cache，尽量减少对业务的影响。
于是我们只能先采用事后修补的方式，起了一个定时任务手动drop cache，但是这种方式在清理cache后对服务是有影响的
echo 3 > /proc/sys/vm/drop_caches
0x3 修改
通过搜索引擎找到了两种方式
- 使用nocache + rsync 命令，nocache工具是一个最小化应用影响系统cache的工具，但是试用下来没有效果 我们使用下面命令rsync一个4G的目录
./nocache rsync -rlpt --progress 10.12.7.220::res/4G-data /opt/data/
对比前后，cache仍然会持续上涨。
- rsync有一个非官方的版本，支持了–drop-cache的选项，具体的项目是rsync-fadvise， 大致原理也是利用fadvise64()，文件写完进行flush，然后清内存，手动编译了一个版本，加上了–drop-cache选项
./rsync -rlpt --progress --drop-cache 10.12.7.220::res/4G-data /opt/data/
对比前后, 可以看到cache不会持续上涨了。
微信扫一扫，订阅我的博客动态^_^
