postgresql-脏页和缓存失效

脏页和缓存失效

https://www.cnblogs.com/flying-tiger/p/7885478.html

Dirty pages and cache invalidation

我们一直在说的是查询语句(SELECT),那么对于DML语句情况又有什么不一样呢？

很简单，他们将数据也写回到相同的page。也就是说，如果该数据所在的页面就在内存的cache中，那就把数据写到cache中的这个page里，如果不在内存，那么就把数据所在的page从disk读取到cache中，然后再写到cache的page里。

这里就是脏页面的由来：page里面的内容被修改了，但是却没有写回disk。

说到写回的概念，我们又要引出另外的概念了：WAL 和 checkpoints。

WAL叫预写日志，它追踪并记录数据库系统中所发生的一切动作。中心概念是数据文件（存储着表和索引）的修改必须在这些动作被日志记录之后才被写入，即在描述这些改变的日志记录被刷到持久存储以后。如果我们遵循这种过程，我们不需要在每个事务提交时刷写数据页面到磁盘，因为我们知道在发生崩溃时可以使用日志来恢复数据库：任何还没有被应用到数据页面的改变可以根据其日志记录重做（这是前滚恢复，也被称为REDO）。

而Checkpointer进程呢？这个周期有系统参数可以配置。检查点是在事务序列中的点，这种点保证被更新的堆和索引数据文件的所有信息在该检查点之前已被写入。在检查点时刻，所有脏数据页被刷写到磁盘，并且一个特殊的检查点记录将被写入到日志文件（修改记录之前已经被刷写到WAL文件）。简而言之，它定期的将脏页面写回到disk。

有了这两个进程，就可以保证数据库很快地从崩溃中恢复过来，而不用手忙脚乱地回放崩溃之前的所有操作。

这是页面从内存中被换出的最常见的方式，在典型的情况下，LRU换出几乎不会发生。

 

数据写入

数据写入时，从内存到磁盘，这个页面就会被标记为脏页，一旦被标记为脏页，它就会被刷新到os缓存，然后写入磁盘。所以如果os高速缓存大小较小

，则它不能重新排序写入并优化io，这对于繁重的写入来说非常致命，因此os的缓存大小也非常重要。给予shared_buffers太大或太小都会损害性能。