系统技术非业余研究

在典型的IO密集型的数据库服务器如MYSQL中，会涉及到大量的文件读写，通常这些文件都是通过buffer io来使用的，以便充分利用到Linux操作系统的page cache。

Buffer IO的特点是读的时候，先检查页缓存里面是否有需要的数据，如果没有就从设备读取，返回给用户的同时，加到缓存一份;写的时候，直接写到缓存去，再由后台的进程定期涮到磁盘去。这样的机制看起来非常的好，在实践中也效果很好。

但是如果你的IO非常密集，就会出现问题。首先由于pagesize是4K，内存的利用效率比较低。其次缓存的淘汰算法很简单，由操作系统自主进行，用户不大好参与。当你的写很多，超过系统内存的某个上限的时候，后台的进程(swapd)要出来回收页面，而且一旦回收的速度小于写入的速度，就会出现不可预期的行为。

这里面最大的问题是：当你使用的内存包括缓存，没超过操作系统规定的上限的时候，操作系统选择不作为，让用户充分使用缓存，从它的角度来看这样效率最高。但是正是由于这种策略在实践中会导致问题。

比如说MYSQL服务器，我们可以把数据直接走direct IO,但是它的日志是走bufferio的。因为走directio需要对写入文件的偏移和大小都要扇区对全，这对日志系统来讲太麻烦了。由于MYSQL是基于事务的，会涉及到大量的日志动作，频繁的写入，然后fsync. 日志一旦写入磁盘，buffer page就没用了，但是一直会在内存呆着，直到达到内存上限，引起操作系统突然大量回收
页面，出现IO柱塞或者内存交换等负面问题。

那么我们知道了困境在哪里，我们可以主动避免这个现象的发生。有二种方法：
1. 日志也走direct io,需要规模的修改MYSQL代码，如percona就这么做了，提供相应的patch。
2. 日志还是走buffer io, 但是定期清除无用page cache.

第一张方法不是我们要讨论的，我们重点讨论第二种如何做：

我们在程序里知道文件的句柄，是不是就可以很轻松的用：

int posix_fadvise(int fd, off_t offset, off_t len, int advice);
POSIX_FADV_DONTNEED
The specified data will not be accessed in the near future.

来解决问题呢？
比如写类似 posix_fadvise(fd, 0, len_of_file, POSIX_FADV_DONTNEED)；这样的代码来清掉文件所属的缓存。

前面介绍的vmtouch就有这样的功能，清某个文件的缓存。
vmtouch -ve logfile 就可以试验，但是你会发现内存根本就没下来，原因呢？

我们从代码来看posix_fadvise如何运作的：
参看 mm/fadvise.c：
Read more…