引子
最近在做服务器压力测试，经常关注的就是服务器的负载情况。我们目前服务器的逻辑进程主要使用 lua 编写，开启定期 GC 后单个用户占用内存大概在1M 左右，开多逻辑进程后，单个进程占用内存都不大。
这次的小范围内部测试，只申请了一台 4 核 8 G的机器，测试开始后，cpu 和其他负载都不大。但是跑了大概1个小时左右，查看内存发现 free 的很少，只有几百兆了。其实实际占用的也并不多，但是很大一部分内存被 cache 住了，大概有 4 个多 G。
1 | $ free -m |
以前只知道 cached 的内存一般是缓存的磁盘文件，如果后续需要内存，内核会采取策略释放这些 cached 的内存，不会出什么问题。但是这次很想知道是什么文件被 cache 住了，有没有优化措施。于是决定查下资料定位一下是哪些文件导致内存被大量 cache 的。
内存使用
首先通过 proc 文件系统的 meminfo 看下当前内存的使用情况。由于 top、vmstat、free 命令都是采样的 proc 文件系统的数据，所以直接看 meminfo 会更全面准确。
1 | $ cat /proc/meminfo |
其中anno 匿名内存应该就是我们程序分配的堆栈内存，而 file 应该就是和文件关联的内存，比如我们的程序代码，打开的文件等。可以看到 Active(file)项已经很大了。
那怎么知道是哪个进程占用的比较多呢？这时候就要借助 top 命令的输出了。
shift + M 按内存占用排序后可以看到，果然是我们的游戏进程占用最多。
看 RES 列的实际占用内存并不高，但是虚拟内存 VIRT 就将近3倍于实际使用内存，多出来的内存基本就是 cache 住的文件缓存了。
为了查看进程打开了哪些文件，我们 lsof 看下
1 | lsof -p PID |
具体结果由于涉及业务这里就不贴了， 打开的文件主要是程序可执行文件、连接的 so、网络连接、日志文件等。从 size 大小看除日志文件外，其他都很小。我们的日志轮转大小是100M，打开的日志文件大概有 200M 左右，总的加起来也不会有4G 大小。
于是猜想，是不是可能缓存了其他日志文件。由于我们测试为了方便查找问题，是开启 DEBUG 级别日志的，因此日志量比较大，一个小时单个进程轮转了9个日志文件，如果缓存了部分，那就很可观了。为了证实这个猜想，我查找了一些工具来统计 cache 内存的大小。
统计大小
网上推荐了 linux-ftools 这个工具来进行统计，fincore 是其中的一个。fincore 的工作原理是将指定的文件的相应 inode data 与 kernel 的 page cache table 做对比，如果 page cache table 有这个 inode 信息，就找该inode 对应的 data block 的大小。因为 kernel 的 page cache table 只存储 data block 的引用而不是文件名，即文件的 inode 信息。所以并没有任何一个工具运行一次就可以找出所有的文件使用缓存的情况。
不过遗憾的是，linux-ftools 不再维护了，编译这个程序会出问题。所幸的是，还有个 Go 实现的类似功能的工具，叫 pcstat，下载方式是
1 | curl -L -o pcstat https://github.com/tobert/pcstat/raw/2014-05-02-01/pcstat.x86_64 |
这里感谢下作者的付出。
我们列出 log 目录下的所有目录文件，然后运行 pcstat 命令得到统计结果如下
1 | $ ~/pcstat `ls *.0831*.log` |
可以看到大量的轮转过的日志文件，虽然没有再被打开使用，仍然被操作系统缓存了起来，百分比不等。
我们可以使用 linux 的清除 cache 命令来手动释放一下试试，使用 root 执行
1 | $ sync |
再查看内存使用情况
1 | $ free -m |
cache 的大量内存被释放了，再查看 pcstat 的统计结果
1 | $ ~/pcstat `ls *.0831*.log` |
注意，这里只是通过清除命令展示一下 cache 前后的统计结果，生产环境在运行时，不要手动释放这些缓存，否则可能带来性能方面的问题，应该放心的由操作系统去实时他的策略。
参考资料