PostgreSQL数据库扩展包——pg_buffercache使用

冷不防 2022-10-09 03:00 304阅读 0赞

## 概述 ##

pg\_buffercache模块提供了一种实时检测共享缓冲区的方法。这个模块提供了一个C函数：pg\_buffercache\_pages，它返回一个记录的集合和一个视图：pg\_buffercache，它包装了这个函数来更方便的使用。默认情况下，公共访问会从这两者中撤回，来预防潜在的安全问题。

pg\_buffercache这个视图中各列定义的详细解释如下：

<table> 
 <thead> 
  <tr> 
   <th>名称</th> 
   <th>描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>bufferid</td> 
   <td>ID范围是1到shared_buffers</td> 
  </tr> 
  <tr> 
   <td>relfilenode</td> 
   <td>关系的文件节点号</td> 
  </tr> 
  <tr> 
   <td>reltablespace</td> 
   <td>关系的表空间OID</td> 
  </tr> 
  <tr> 
   <td>reldatabase</td> 
   <td>关系的数据库OID</td> 
  </tr> 
  <tr> 
   <td>relforknumber</td> 
   <td>关系内的分叉树</td> 
  </tr> 
  <tr> 
   <td>relblocknumber</td> 
   <td>关系内的页面数</td> 
  </tr> 
  <tr> 
   <td>isdirty</td> 
   <td>页面是否为脏</td> 
  </tr> 
  <tr> 
   <td>usagecount</td> 
   <td>clock-sweep访问计数</td> 
  </tr> 
  <tr> 
   <td>pinning_backends</td> 
   <td>对这个缓冲区加pin的后端数量</td> 
  </tr> 
 </tbody> 
</table>

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70]

共享缓存中的每个缓冲区都有一行。未使用的缓冲区除了bufferid以外的所有列为null。共享系统目录被显示为属于数据库零。因为缓存被所有的数据库共享，通常会有关系中的一些页面不属于当前的数据库。这意味着对许多行来说，在pg\_class中可能不会有匹配的连接行，或者甚至可能会有错误连接。如果你试图连接pg\_class，一个好的办法就是将连接限制为reldatabase等于当前数据库的OID或者为零的行。  
当访问pg\_buffercache视图时，内部缓冲区管理器会锁住足够长的时间来拷贝所有这个视图会展示的缓冲区状态数据。这确保了这个视图产生一个一致的结果集，同时不会不必要的长时间阻碍正常的缓冲区活动。虽然如此，但是如果这个视图被频繁读取的话，会对数据库性能产生一些影响。

## 测试 ##

登录psql，并创建两个数据库：`create database test; create database mydb;`  
连接到测试数据库，并执行：`create extension pg_buffercache;`  
在shell提示符中，进入/usr/local/pgsql/share/extension目录：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 1]  
![在这里插入图片描述][20210623122717534.png]  
连接到数据库，看看缓冲区缓存的内容：

[postgres@MyCentOS extension]$ psql -d test
    test=# SELECT DISTINCT reldatabase FROM pg_buffercache;
      reldatabase
    --------------
            12896
                0
            24741

在缓存中找到两个数据库的某些部分。带0的记录表示缓存区尚未使用：

test=# \! oid2name
    All databases:
      Oid   Database Name   Tablespace
    -----------------------------------
     16440           mydb    pg_default
     12896       postgres    pg_default
     12891      template0    pg_default
         1      template1    pg_default 
     24741           test    pg_default

可以用一些其他视图再次连接，以获得更清晰的结果：  
`select c.relname, count(*) as buffers from pg_class c join pg_buffercache b on b.relfilenode = c.relfilenode inner join pg_database d on (b.reldatabase=d.oid and d.datname=current_database()) group bu c.relname order by 2 desc;`  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 2]  
可以看到主要是数据字典视图。许多数据字典表和视图会提供各种对象、对象类型、权限等的相关信息。这些为集群共同管理者记录活动；pg\_class是其中一个类目表。这个表的其中一列是relname。尽管它看上去像是要存储关系/表名称，它也可以为其他对象类型存储数据。我们应该将它与列relkind一起使用。列relkind告诉我们记录指向的对象类型。relkind可能包括这些值，如r表、i索引、s序列、v视图等。

删除查询中relname，并修改  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 3]  
尝试使用用户创建的表填充缓冲区。创建一个表，并插入一条记录。  
![在这里插入图片描述][2021062312424228.png]  
可以重复查询，检查缓冲区是否包含新创建的表及其序列：  
![在这里插入图片描述][2021062312432285.png]  
对查询稍作修改，isdirty标记是f：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 4]  
更新数据，重复查询缓存区，页面表脏：  
![在这里插入图片描述][20210623124420576.png]  
![在这里插入图片描述][20210623124449257.png]  
强制设置检查点：`CHECKPOINT;`  
重复查询，页面不为脏：  
![在这里插入图片描述][20210623124550471.png]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70]: /images/20221005/6aa31050dea54fe3821d645e790120cc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 1]: /images/20221005/669290760dca481b901d563c6f7aa3be.png
[20210623122717534.png]: /images/20221005/8edc1d3902534233a5e378de3eb94b00.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 2]: /images/20221005/bac0a77500994e55b2cd1a7fd53b3a49.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 3]: /images/20221005/5abff32d819042d9b4a81fe1677dcb9f.png
[2021062312424228.png]: /images/20221005/64fc21896b1f44fda12439815670c9b6.png
[2021062312432285.png]: /images/20221005/a6727fe7fd404302a31826d65c79c41c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 4]: /images/20221005/a44bd1718c074dcb9ddb873e79439bab.png
[20210623124420576.png]: /images/20221005/7668d5598d284f799145dc8d80c9fb0d.png
[20210623124449257.png]: /images/20221005/383b7fbd92b44c98a4a3911d859d74a2.png
[20210623124550471.png]: /images/20221005/d37abb0169074115ba4cb34f687a5e80.png