金仓数据库 KingbaseES等待事件之LWLock buffer_mapping

目录

等待事件含义

分析等待事件增加的原因

解决

监控缓冲区相关指标

评估索引策略

减少必须分配buffer数量

调大共享缓冲区

---

等待事件含义

当会话将数据块与共享缓冲池中的缓冲区关联时，会发生此等待事件。

类似Oracle cbc闩锁的是一种Kingbase的轻量级锁lwlock，这个锁的名字在不同数据库版本中可能有所不同，我们统一称之为buffer_mapping（BufMappingLock），这个轻量级锁用于HASH BUCKET的串行化访问。因为在每个buffer 访问中都需要使用这个锁，因此和Oracle一样，Kingbase采用了分区锁的方式，将整个HASH TABLE分为多个分区（缺省位128个，不同版本缺省值会有不同），每个分区使用一个lwlock。
当有多个backend进程来访问buffer cache的时候，首先通过计算HASH值，找到HASH TABLE的位置，然后获得相关的BufMappingLock，才能去访问HASH TABLE，找到HASH CHAIN，最终找到对应的BUFFER。当两个BACKEND访问的BUFFER属于不同的分区锁控制的时候，不会产生冲突，反之会产生冲突。

如图：两个进程同时以独占方式获取 BufMappingLock 各自的分区，以插入新的数据条目

LWLock:buffer_mapping等待事件发生在以下场景：

• 进程在缓冲区表中搜索页面并获取共享缓冲区映射锁。
• 进程将页面加载到缓冲池中并获取独占缓冲区映射锁。
• 一个进程从池中删除一个页面并获取一个独占缓冲区映射锁。

分析等待事件增加的原因

当buffer_mapping 增加到不寻常的值，可能的原因：

• 大型长查询
• 膨胀的索引和表（膨胀的表需要更多的缓冲区分区映射关系）
• 全表扫描
• 小于工作集的共享池大小（很常见的原因，考虑增加共享缓冲池以减少此等待事件的发生）

解决

监控缓冲区相关指标

当LWLock:buffer_mapping等待高峰时，调查缓冲区命中率。您可以使用这些指标来更好地了解缓冲区缓存中发生的情况。检查以下指标：

• BufferCacheHitRatio

  此指标衡量由数据库集群中数据库实例的缓冲区缓存提供服务的请求的百分比。您可能在 LWLock:buffer_mapping等待事件发生前看到此指标减少。

• blks_hit

  此指标指示从共享缓冲池中命中的块数。 LWLock:buffer_mapping等待事件出现后，您可能会观察到blks_hit峰值.

• blks_read

  此指标指示需要将 I/O(pages)读入共享缓冲池的块数。LWLock:buffer_mapping等待事件发生前，您可能会观察blks_read的峰值。

评估索引策略

要确认您的索引策略不会影响性能，请检查以下内容：

• 索引和表膨胀

  确保索引和表膨胀不会导致不必要的页面被读入共享缓冲区。如果您的表包含未使用的行，请考虑归档数据并从表中删除死亡行或没必要的行。然后，您可以为调整大小的表重建索引。重建索引显然比vacuum表的同时维护索引的效率更高，因为vauum索引时可能需要反复用到maintenance_work_mem.

• 常用查询的索引

  要确定您是否拥有最佳索引，sys_stat_database中tup_returned指标显示读取的行数。该 tup_fetched指标显示返回给客户端的行数。如果 tup_returned明显大于``tup_fetched，则可能无法正确索引数据。此外，表统计信息可能不是最新的。避免一个表上创建超过5个索引。

减少必须分配buffer数量

要减少LWLock:buffer_mapping等待事件，请尝试减少必须的缓冲区数量。一种策略是执行较小的批量操作。您可以通过对很大的表进行分区来实现较小的批次。

调大共享缓冲区

如果系统可用内存充足，调大shared_buffers参数，可一定程度规避等待事件LWLock:buffer_mapping。