rsync cache之坑

0x0 背景

我们的网站平台上提供了可定制的语言模型功能,用户在使用定制工具定制完成后,这些模型需要让语音识别服务能够访问到。
为了识别服务能够更快的加载这些资源文件,我们需要将资源同步到每台部署有语音识别服务端物理机器上。

我们快速搭建了一套同步的服务,就是上一篇中提及的resync-server,resync-broker和resync-agent。 我们在每台需要在本地使用这些资源的机器上启动了一个resync-agent,它的作用是实时地将定制平台上新产生的资源拉到本地。

考虑到新增物理机节点或者维护更新agent时需要下掉agent, 我们加入了一个补偿的机制,即在新初始化物理机和agent更新时使用rsync同步一遍用户定制的语言模型的目录。

0x1 现象

在某次我们加入这个rsync机制后,监控到机器可用的free内存持续下降,大量的内存被cache占用。由于我们的agent和识别服务是部署在同一台机器上,而语音识别服务本身对内存的要求又非常高,这个功能上线后,直接影响到了识别业务,

image

0x2 分析

我们知道linux通过cache机制提高磁盘的读写效率,但是这里我们更希望少占用cache,尽量减少对业务的影响。

于是我们只能先采用事后修补的方式,起了一个定时任务手动drop cache,但是这种方式在清理cache后对服务是有影响的

1
echo 3 > /proc/sys/vm/drop_caches

0x3 修改

通过搜索引擎找到了两种方式

  1. 使用nocache + rsync 命令,nocache工具是一个最小化应用影响系统cache的工具,但是试用下来没有效果
    我们使用下面命令rsync一个4G的目录
    1
    ./nocache rsync -rlpt --progress 10.12.7.220::res/4G-data /opt/data/

对比前后,cache仍然会持续上涨。
image
image

  1. rsync有一个非官方的版本,支持了–drop-cache的选项,具体的项目是rsync-fadvise, 大致原理也是利用fadvise64(),文件写完进行flush,然后清内存,手动编译了一个版本,加上了–drop-cache选项
    1
    ./rsync -rlpt --progress --drop-cache 10.12.7.220::res/4G-data /opt/data/

对比前后, 可以看到cache不会持续上涨了。
image
image

您的支持将鼓励我继续创作!