PostgreSQL的WAL(1)--Buffer Cache
2020-09-17 12:05 abce 阅读(895) 评论(0) 编辑 收藏 举报为什么需要提前写日志
DBMS处理的数据部分存储在RAM中，并异步写入磁盘（或其他非易失性存储）中。即写延迟了一段时间。这种情况发生的频率越低，输入/输出越少，系统运行越快。
通常，尤其是在PostgreSQL中，写入磁盘的数据似乎不一致，并且在故障后恢复时，需要采取特殊措施来恢复数据一致性。预写日志记录（WAL）只是一项使之成为可能的功能。
buffer cache
buffer cache不是存储在RAM中的唯一结构，而是其中最关键和最复杂的结构之一。理解其工作原理本身很重要；此外，我们将以它为例以熟悉RAM和磁盘如何交换数据。
缓存在现代计算机系统中无处不在。一个处理器仅具有三级或四级缓存。通常，需要缓存来减轻两种内存之间的性能差异，其中一种相对较快，但是容量较小，循环不足；另一种相对较慢，但是容量足够。缓冲区缓存减轻了访问RAM的时间（纳秒）和磁盘存储的时间（毫秒）之间的差异。
请注意，操作系统还具有解决相同问题的磁盘缓存。因此，数据库管理系统通常尝试通过直接访问磁盘而不是通过OS缓存来避免双重缓存。但是PostgreSQL并非如此：所有数据都是使用常规文件操作读取和写入的。
此外，磁盘阵列的控制器甚至磁盘本身也具有自己的缓存。当我们讨论可靠性时，这将很有用。
但是，让我们回到DBMS的buffer cache。
每个buffer由数据页（块）的空间和header组成。header中包含：
·page在buffer中的位置(文件和块号)。
·page上数据更改的指示符，更改迟早需要将其写入磁盘(这样的缓冲区称为脏缓冲区)。
·buffer的使用计数。
·buffer的pin计数。
buffer cache位于服务器的共享内存中，所有进程都可以访问它。为了处理数据，即读取或更新数据，这些进程会将页面读取到缓存中。当页面在缓存中时，我们在RAM中使用它并在磁盘访问中保存它。
在cache中寻找一个page
当进程需要读取页面时，它首先尝试通过哈希表在buffer cache中找到它。文件号和文件中的页面号用作哈希键。该进程在适当的哈希桶中找到buffer编号，并检查它是否确实包含所需的页面。像任何哈希表一样，此处可能会发生冲突，在这种情况下，该过程将不得不检查多个页面。
哈希表的使用长期以来一直是人们抱怨的源头。像这样的结构可以快速按页查找缓冲区，但是，例如，如果您需要查找某个表占用的所有缓冲区，则哈希表绝对是无用的。但是还没有人建议好的替代品。
如果在高速缓存中找到所需的页，则该进程必须通过增加pin计数来“pin”住缓冲区（多个进程可以同时执行此操作）。被固定的缓冲区（计数值大于零）时，它被认为是已使用并且具有无法“急剧”更改的内容。例如：一个新的元组可以出现在页面上-由于多版本并发和可见性规则，这对任何人都无害。但是无法将其他页面读入固定的缓冲区。
Eviction
可能会出现在缓存中找不到所需的页面的情况。在这种情况下，需要将该页从磁盘读入某个缓冲区。
如果缓存中的空缓冲区仍然可用，则选择第一个空缓冲区。但是它们迟早会不够(数据库的大小通常大于为缓存分配的内存)，然后我们将不得不选择一个已占用的缓冲区，将位于那里的页清除出去，并将新的页读入已释放的空间。
清除技术基于这样一个事实:对于每次访问缓冲区，进程都会增加缓冲区header中的使用计数。因此，与其他缓冲区相比，使用频率较低的缓冲区的计数值较小，因此是清除的良好候选对象。
时钟扫描算法循环地遍历所有缓冲区(使用指向«next victim»的指针)，并将它们的使用量减少1。 为清除选择的第一个缓冲区要满足:
·使用计数是0
·pin计数也是0
请注意，如果所有缓冲区都有一个非零的使用计数，那么算法将不得不在缓冲区中进行多次循环，减少计数的值算，直到其中一些减少到零为止。算法为了避免«做重叠»的操作，使用计数的最大值被限制为5。然而，对于大型的buffer cache，该算法可能会造成相当大的开销。
找到缓冲区后，将对它执行以下操作。
缓冲区被固定以显示使用它的其他进程。除了固定之外，还使用了其他锁定技术，但是我们将在后面更详细地讨论。
如果缓冲区看起来是脏的，也就是说，包含已更改的数据，就不能直接删除页面——它需要首先保存到磁盘。 这很难说是一种好情况，因为要读取页面的进程必须等待其他进程的数据被写入，但是检查点和后台写入器进程缓解了这种影响，这将在后面讨论。
然后将新页从磁盘读入选定的缓冲区。使用计数被设置为1。此外，必须将对已加载页面的引用写入哈希表，以便将来能够查找该页面。
对«next victim»的引用现在指向下一个缓冲区，而刚刚加载的缓冲区有时间增加使用计数，直到指针循环地遍历整个缓冲区缓存并再次返回。
自己验证一下
和往常一样，PostgreSQL有一个扩展，可以让我们查看缓冲区缓存的内部。
=> CREATE EXTENSION pg_buffercache;
让我们创建一个表并在那里插入一行。
=> CREATE TABLE cacheme( id integer ) WITH (autovacuum_enabled = off); => INSERT INTO cacheme VALUES (1);
buffer cache将包含什么?至少，必须出现只添加了一行的页面。让我们用下面的查询来检查这个，它只选择与我们的表相关的缓冲区(通过relfilenode号)，并解释relforknumber:
=> SELECT bufferid,
CASE relforknumber
WHEN 0 THEN 'main'
WHEN 1 THEN 'fsm'
WHEN 2 THEN 'vm'
END relfork,
relblocknumber,
isdirty,
usagecount,
pinning_backends
FROM pg_buffercache
WHERE relfilenode = pg_relation_filenode('cacheme'::regclass);
bufferid | relfork | relblocknumber | isdirty | usagecount | pinning_backends
----------+---------+----------------+---------+------------+------------------
15735 | main | 0 | t | 1 | 0
(1 row)
正如我们所想的那样:缓冲区只包含一个页面。它是脏的(isdirty)，使用计数(usagecount)等于1，并且页面没有被任何进程固定(pinning_backends)。
| => INSERT INTO cacheme VALUES (2);
=> \g
bufferid | relfork | relblocknumber | isdirty | usagecount | pinning_backends
----------+---------+----------------+---------+------------+------------------
15735 | main | 0 | t | 2 | 0
(1 row)
没有添加新的缓冲区:第二行适合同一页。注意增加的使用量。
| => SELECT * FROM cacheme;
| id | ---- | 1 | 2 | (2 rows)
=> \g
bufferid | relfork | relblocknumber | isdirty | usagecount | pinning_backends
----------+---------+----------------+---------+------------+------------------
15735 | main | 0 | t | 3 | 0
(1 row)
在读取页面之后，计数也会增加。
| => VACUUM cacheme;
=> \g
bufferid | relfork | relblocknumber | isdirty | usagecount | pinning_backends
----------+---------+----------------+---------+------------+------------------
15731 | fsm | 1 | t | 1 | 0
15732 | fsm | 0 | t | 1 | 0
15733 | fsm | 2 | t | 2 | 0
15734 | vm | 0 | t | 2 | 0
15735 | main | 0 | t | 3 | 0
(5 rows)
调优buffer cache的大小
我们可以使用shared_buffers参数设置缓存大小。默认值是128mb，这是安装PostgreSQL后应该马上增加的参数之一。
=> SELECT setting, unit FROM pg_settings WHERE name = 'shared_buffers'; setting | unit ---------+------ 16384 | 8kB (1 row)
注意，更改此参数需要重新启动服务器，因为缓存的所有内存都是在服务器启动时分配的。
即使是最大的数据库也只有一组有限的“热”数据，这些数据一直在被集中处理。理想情况下，必须在缓冲区缓存中容纳这个数据集(加上一些用于一次性数据的空间)。如果缓存大小较小，那么频繁使用的页面将不断地相互清除，这将导致过多的输入/输出。但是盲目地增加缓存也不好。当缓存很大时，维护它的开销将增加，除此之外，其他用途也需要RAM。
通常建议使用1/4的内存作为第一个近似(低于10的PostgreSQL版本建议Windows使用更小的内存)。
然后我们最好进行实验:增加或减少缓存大小，并比较系统特性。为此，您当然需要测试，并且应该能够重新生成工作负载。在生产环境中进行这样的实验是一种可疑的乐趣。
但是，您可以通过相同的pg_buffercache扩展名获得一些关于您的系统上正在发生的事情的信息。 最重要的是要从正确的角度看问题。
例如:你可以通过它们的使用来探索缓冲区的分布:
=> SELECT usagecount, count(*)
FROM pg_buffercache
GROUP BY usagecount
ORDER BY usagecount;
usagecount | count
------------+-------
1 | 221
2 | 869
3 | 29
4 | 12
5 | 564
| 14689
(6 rows)
在这种情况下，计数的多个空值对应于空缓冲区。对于一个什么都没有发生的系统来说，这并不奇怪。
=> SELECT c.relname,
count(*) blocks,
round( 100.0 * 8192 * count(*) / pg_table_size(c.oid) ) "% of rel",
round( 100.0 * 8192 * count(*) FILTER (WHERE b.usagecount > 3) / pg_table_size(c.oid) ) "% hot"
FROM pg_buffercache b
JOIN pg_class c ON pg_relation_filenode(c.oid) = b.relfilenode
WHERE b.reldatabase IN (
0, (SELECT oid FROM pg_database WHERE datname = current_database())
)
AND b.usagecount is not null
GROUP BY c.relname, c.oid
ORDER BY 2 DESC
LIMIT 10;
relname | blocks | % of rel | % hot
---------------------------+--------+----------+-------
vac | 833 | 100 | 0
pg_proc | 71 | 85 | 37
pg_depend | 57 | 98 | 19
pg_attribute | 55 | 100 | 64
vac_s | 32 | 4 | 0
pg_statistic | 27 | 71 | 63
autovac | 22 | 100 | 95
pg_depend_reference_index | 19 | 48 | 35
pg_rewrite | 17 | 23 | 8
pg_class | 16 | 100 | 100
(10 rows)
例如:我们在这里可以看到vac表占用了大部分空间，但是它没有被长时间访问，而且也没有被驱逐，这只是因为空缓冲区仍然可用。
·您需要多次重新运行此类查询:这些数字将在一定范围内变化。 ·您不应该连续运行这样的查询(作为监视的一部分)，因为扩展会暂时阻塞对缓冲区缓存的访问。
Massive eviction
批量读和写操作容易产生这样的风险，即有用的页面可能会被«一次性»从缓冲区缓存中快速驱逐。
为了避免这种情况，使用了所谓的 buffer rings:只是为每个操作分配一小部分缓冲区缓存。驱逐仅在环内执行，因此缓冲区缓存中的其余数据不受影响。
对于大型表(其大小大于缓冲区缓存的四分之一)的连续扫描，将分配32个页面。如果在扫描一个表的过程中，另一个进程也需要这些数据，那么它不会从头开始读取表，而是连接到已经可用的缓冲区环。在完成扫描之后，进程继续读取表的«missed»开头部分。
让我们验证一下。创建一个表，以便一行占据整个页面——这样计数更方便。缓冲区缓存的默认大小为128 MB = 16384个页面(8 KB)。这意味着我们需要向表中插入超过4096行(即页)。
=> CREATE TABLE big( id integer PRIMARY KEY GENERATED ALWAYS AS IDENTITY, s char(1000) ) WITH (fillfactor=10); => INSERT INTO big(s) SELECT 'FOO' FROM generate_series(1,4096+1);
我们来分析一下这个表
=> ANALYZE big;
=> SELECT relpages FROM pg_class WHERE oid = 'big'::regclass;
relpages
----------
4097
(1 row)
现在我们必须重新启动服务器以清除分析中读取的表数据的缓存。
student$ sudo pg_ctlcluster 11 main restart
重启后读取整个表:
=> EXPLAIN (ANALYZE, COSTS OFF) SELECT count(*) FROM big;
QUERY PLAN
---------------------------------------------------------------------
Aggregate (actual time=14.472..14.473 rows=1 loops=1)
-> Seq Scan on big (actual time=0.031..13.022 rows=4097 loops=1)
Planning Time: 0.528 ms
Execution Time: 14.590 ms
(4 rows)
让我们确保表页面在缓冲区缓存中只占用32个缓冲区：
=> SELECT count(*)
FROM pg_buffercache
WHERE relfilenode = pg_relation_filenode('big'::regclass);
count
-------
32
(1 row)
但如果我们禁止顺序扫描，表将读取使用索引扫描:
=> SET enable_seqscan = off;
=> EXPLAIN (ANALYZE, COSTS OFF) SELECT count(*) FROM big;
QUERY PLAN
-------------------------------------------------------------------------------------------
Aggregate (actual time=50.300..50.301 rows=1 loops=1)
-> Index Only Scan using big_pkey on big (actual time=0.098..48.547 rows=4097 loops=1)
Heap Fetches: 4097
Planning Time: 0.067 ms
Execution Time: 50.340 ms
(5 rows)
在这种情况下，没有使用缓冲区环，整个表将进入缓冲区缓存(几乎整个索引):
=> SELECT count(*)
FROM pg_buffercache
WHERE relfilenode = pg_relation_filenode('big'::regclass);
count
-------
4097
(1 row)
缓冲区环以类似的方式用于vacuum过程(也是32页)和批量写操作copy和create table as select(通常为2048页，但不超过缓冲区缓存的1/8)。
临时表是常见规则中的一个例外。由于临时数据只对一个进程可见，因此不需要在共享缓冲区缓存中使用它们。 此外，临时数据只存在于一个会话中，因此不需要防止失败的保护。
临时数据使用拥有该表的进程的本地内存中的缓存。由于这些数据只对一个进程可用，因此不需要使用锁保护它们。本地缓存使用正常的驱逐算法。
与共享缓冲区缓存不同，本地缓存的内存是在需要时分配的，因为在许多会话中都不会使用临时表。单个会话中临时表的最大内存大小受到temp_buffers参数的限制。
为cache预热
在服务器重启后，缓存必须经过一段时间才能“预热”，也就是说，要填充活跃使用的数据。它可能有时看起来有用，立即读取某些表的内容到缓存中，一个专门的扩展是可用的:
=> CREATE EXTENSION pg_prewarm;
以前，该扩展只能将某些表读入缓冲区缓存(或仅读入操作系统缓存)。但是PostgreSQL 11允许它将缓存的最新状态保存到磁盘，并在服务器重启后恢复。要使用它，需要将库添加到shared_preload_libraries并重新启动服务器。
=> ALTER SYSTEM SET shared_preload_libraries = 'pg_prewarm';
student$ sudo pg_ctlcluster 11 main restart
重启后，如果pg_prewarm.autoprewarm的值没有改变，autoprewarm主后台进程将启动，每隔pg_prewarm.autoprewarm_interval秒数完成一次刷新缓存中存储的页面列表。(在设置max_parallel_processes值时，不要忘记将新进程计算在内)。
=> SELECT name, setting, unit FROM pg_settings WHERE name LIKE 'pg_prewarm%';
name | setting | unit
---------------------------------+---------+------
pg_prewarm.autoprewarm | on |
pg_prewarm.autoprewarm_interval | 300 | s
(2 rows)
postgres$ ps -o pid,command --ppid `head -n 1 /var/lib/postgresql/11/main/postmaster.pid` | grep prewarm 10436 postgres: 11/main: autoprewarm master
现在缓存不包含big表:
=> SELECT count(*)
FROM pg_buffercache
WHERE relfilenode = pg_relation_filenode('big'::regclass);
count
-------
0
(1 row)
如果我们认为它的所有内容都是关键的，我们可以通过调用以下函数将其读入缓冲区缓存:
=> SELECT pg_prewarm('big');
pg_prewarm
------------
4097
(1 row)
=> SELECT count(*)
FROM pg_buffercache
WHERE relfilenode = pg_relation_filenode('big'::regclass);
count
-------
4097
(1 row)
块列表被刷新到autoprewarm.blocks文件中。要查看列表，我们可以等到autoprewarm主进程第一次完成，或者我们可以手动启动刷新，如下所示:
=> SELECT autoprewarm_dump_now();
autoprewarm_dump_now
----------------------
4340
(1 row)
刷新的页面数量已经超过4097;已被服务器读取的系统目录页被计算在内。这是文件:
postgres$ ls -l /var/lib/postgresql/11/main/autoprewarm.blocks -rw------- 1 postgres postgres 102078 jun 29 15:51 /var/lib/postgresql/11/main/autoprewarm.blocks
现在让我们重新启动服务器。
student$ sudo pg_ctlcluster 11 main restart
在服务器启动后，我们的表将再次位于缓存中。
=> SELECT count(*)
FROM pg_buffercache
WHERE relfilenode = pg_relation_filenode('big'::regclass);
count
-------
4097
(1 row)
相同的autoprewarm主进程提供了这一点:它读取文件，按数据库划分页面，对它们进行排序(尽可能使从磁盘顺序读取)，并将它们传递到一个单独的autoprewarm worker进程进行处理。
原文地址：
https://habr.com/en/company/postgrespro/blog/491730/
