介绍
您有没有遇到这样的问题:已经重启了 PostgreSQL 服务器,但是第二次运行同样的查询仍然快得多,这是为什么?
这个问题的答案很简单,因为重新启动数据库服务器只会清除数据库缓冲区的缓存,但是其他缓存没有变化,这些缓存是:
缓冲区缓存 - PostgreSQL 从磁盘加载包含表和索引的页面的共享缓冲池,以直接从内存工作,从而减少磁盘访问。
页面缓存 - 操作系统通常会缓存文件 IO,除非您通过使用 O_DIRECT 标志,或者以直接 IO 模式挂载文件系统,来显式跳过页面缓存。
硬件缓存 - CPU 状态缓存可能会轻微地影响到查询执行速度,但硬件 IO 缓存可能会造成巨大影响。其中一个是硬件 RAID 缓存,但更重要的是 SAN 缓存,它可能影响非常大。
准备工作
让我们通过一个示例来更好地了解,页面缓存会如何影响查询性能。
假设我们有一个名为t1
的表:
CREATE TABLE t1 (id integer, str text);
下面是用于生成数据的示例 SQL 查询:
我们已经给此表填充了数百万行示例数据。
页面缓存示例
在我们观察页面缓存对查询性能的影响之前,我们需要先停止 PostgreSQL 服务器,首先以 root 帐户清理系统页面缓存:
# echo 3 > /proc/sys/vm/drop_caches
然后,启动 PostgreSQL 服务器。
现在,假设我们要检索总共的记录数:
SET max_parallel_workers_per_gather TO 0;
PLAIN (analyze, buffers) SELECT count(*) FROM t1;
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------
Aggregate (cost=32909.00..32909.01 rows=1 width=8) (actual time=439.977..439.978 rows=1 loops=1)
Buffers: shared read=20409
-> Seq Scan on t1 (cost=0.00..30409.00 rows=1000000 width=0) (actual time=0.244..349.652 rows=1000000 loops=1)
Buffers: shared read=20409
Planning:
Buffers: shared hit=13 read=6
Planning Time: 3.522 ms
Execution Time: 440.979 ms
(8 rows)
表现很好。让我们重新启动 PostgreSQL 服务器。
实际上,我们可以通过 pgfincore 来查看页面缓存的统计信息。
现在,让我们再次检索记录总数,看看它会如何影响性能:
SET max_parallel_workers_per_gather TO 0;
EXPLAIN (analyze, buffers) SELECT count(*) FROM t1;
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------
Aggregate (cost=32909.00..32909.01 rows=1 width=8) (actual time=199.904..199.906 rows=1 loops=1)
Buffers: shared read=20409
-> Seq Scan on t1 (cost=0.00..30409.00 rows=1000000 width=0) (actual time=1.131..113.739 rows=1000000 loops=1)
Buffers: shared read=20409
Planning:
Buffers: shared hit=13 read=6
Planning Time: 0.413 ms
Execution Time: 199.955 ms
(8 rows)
现在查询性能明显更好。我们已将执行时间缩短了两倍以上!