Page Cache的落地问题
除非特别说明,否则本文提到的写操作都是 buffer write/write back。
起因
前几天讨论到一个问题:Linux 下文件 close成功,会不会触发 “刷盘”?
其实这个问题根本不用讨论,查一下就知道。
man 2 close
的 NOTES
一节里有这么一段话:
A successful close does not guarantee that the data has been successfully saved to disk, as the kernel defers writes. It is not common for a filesystem to flush the buffers when the stream is closed. If you need to be sure that the data is physically stored use fsync(2). (It will depend on the disk hardware at this point.)
所以,一个文件的描述符被 close 成功,并不会触发操作系统刷盘。
那么,问题来了,除了主动调用fsync
(或相关函数)之外,Linux 什么时候会“刷盘”呢?
一次正常的写流程
一次写数据的典型流程(不考虑异常和其它特殊情况):
1、数据在用户态的 buffer 中,调用 write 将数据传给内核;
2、数据在 Page Cache 中,返回写入的字节数(成功返回);
3、内核将数据刷新到磁盘。
第二步如果返回成功,说明数据已经到达操作系统的Page Cache,可以保证的是如果进程挂了,但是操作系统没挂,数据不会丢失。
如果调用 fsync
将数据刷新到磁盘上,返回成功,说明数据已经刷新到硬件上了——我们一般认为如果 fsync
返回成功,则表示数据持久化成功。
Page Cache 的异步刷新
那么,如果不调用fsync或其它类似功能的接口,Page Cache 是什么时候刷回磁盘的呢?
简单总结一下,有两种情况:
1、脏页太多。
2、脏页太久。
这些都由 Linux 内核的后台线程执行。相关的控制参数有:
说明: centy 中文意思是“百分之十”。
$ sysctl -a | grep dirty
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 5
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 3000
vm.dirty_ratio = 10
vm.dirty_writeback_centisecs = 500
- dirty_writeback_centisecs 表示多久唤醒一次刷新脏页的后台线程。这里的500表示5秒唤醒一次。
- dirty_expire_centisecs 表示脏数据多久会被刷新到磁盘上。这里的3000表示 30秒。
- dirty_background_ratio 表示当脏页占总内存的的百分比超过这个值时,后台线程开始刷新脏页。这个值如果设置得太小,可能不能很好地利用内存加速文件操作。如果设置得太大,则会周期性地出现一个写 IO 的峰值。
- dirty_ratio 当脏页占用的内存百分比超过此值时,内核会阻塞掉写操作,并开始刷新脏页。
- dirty_background_bytes、dirty_bytes 是和 dirty_background_ratio、dirty_ratio 表示同样意义的不同单位的表示。两者不会同时生效。
总结
触发刷新脏页的条件:
1、调用fsync等。
2、脏页太多(相关参数:dirty_background_ratio与dirty_ratio)。
3、脏页太久(相关参数:dirty_expire_centisecs)。
参考资料
作者:linjinhe
链接:https://www.jianshu.com/p/ed5900d31f1f
來源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。