一文掌握KingbaseES会话与进程管理：从慢查询到复制冲突全解析

笃行_其道
3 阅读13分钟

在数据库的日常运维工作中，会话与进程管理是数据库管理员（DBA）必须掌握的核心技能之一。作为国产数据库的代表，电科金仓KingbaseES在政府、金融、能源、电信等关键行业承担着越来越重要的角色，其会话与进程管理机制也在大量生产实践中不断完善。一个运行良好的KingbaseES数据库系统，不仅依赖于合理的架构设计和优化的SQL语句，更依赖于对运行时会话状态的精准把控。

当电科金仓KingbaseES数据库出现响应迟缓、连接超限、复制延迟等问题时，能否快速定位问题会话、识别阻塞源头、合理控制连接资源，往往决定了故障处理的效率和业务恢复的速度。本文将围绕慢查询识别、阻塞会话排查、连接数控制以及流复制冲突分析等几个关键场景，系统梳理电科金仓KingbaseES数据库会话与进程管理的实战方法。

一、KingbaseES慢查询与阻塞会话的识别

1.1 为什么要关注慢查询和阻塞会话

当电科金仓KingbaseES数据库响应速度下降或处理出现延迟时，排查工作的第一步通常是定位那些执行时间过长的查询，也就是常说的"慢查询"。与此同时，因等待资源（例如锁）而暂停执行的"阻塞会话"也是性能问题的常见诱因。慢查询会持续占用CPU、内存和I/O资源，而阻塞会话则会形成连锁反应，导致更多的会话陷入等待，最终可能引发整个数据库的"雪崩式"性能塌陷。

通过对KingbaseES中慢查询和阻塞会话的有效监控与分析，DBA不仅能够识别当前的性能瓶颈，还可以从中发现潜在的设计缺陷或不合理的SQL写法，为长期的性能优化提供依据。

1.2 综合查询慢SQL与阻塞会话

电科金仓KingbaseES提供了功能丰富的sys_stat_activity视图，下面这条SQL可以一次性地从该视图中提取出当前所有非空闲会话的详细信息，包括运行时长、阻塞进程、等待事件等关键指标，是排查问题时非常实用的工具：

SELECT syssa.pid, 
       sys_blocking_pids(pid) AS blocking_pid, 
       TO_CHAR(INTERVAL '1 second' * trunc(EXTRACT(epoch FROM (NOW() - syssa.query_start))), 'HH24:MI:SS') AS query_runtime, 
       TO_CHAR(INTERVAL '1 second' * trunc(EXTRACT(epoch FROM (NOW() - syssa.xact_start))), 'HH24:MI:SS') AS xact_runtime, 
       syssa.client_port, 
       syssa.datname, 
       syssa.usename, 
       syssa.client_addr, 
       syssa.application_name, 
       syssa.state, 
       syssa.wait_event, 
       syssa.wait_event_type, 
       syssa.backend_xid, 
       syssa.backend_xmin, 
       syssa.backend_start, 
       syssa.xact_start, 
       syssa.state_change, 
       syssa.query_start AS query_start, 
       trunc(EXTRACT(epoch FROM (NOW() - syssa.xact_start))) AS xact_stay, 
       trunc(EXTRACT(epoch FROM (NOW() - syssa.query_start))) AS query_stay, 
       syssa.QUERY, 
       syssa.backend_type, 
       'select sys_terminate_backend('||syssa.pid||');' kill1, 
       'select sys_cancel_backend('||syssa.pid||');' kill2 
FROM sys_stat_activity AS syssa 
WHERE syssa.state NOT IN ('idle', 'idle in transaction (aborted)') 
  AND syssa.pid NOT IN (sys_backend_pid()) 
ORDER BY query_stay DESC, xact_stay DESC, pid 
LIMIT 100;

这条SQL在KingbaseES环境下有几个值得关注的设计细节。首先，结果中预先生成了sys_terminate_backend和sys_cancel_backend两条命令，DBA在确认问题会话后可以直接复制执行，无需手动拼接进程号；其次，按查询持续时间和事务持续时间倒序排列，最耗时的会话会出现在最前面；最后，过滤掉了空闲会话和当前查询本身，避免结果被无关信息干扰。

1.3 单独定位被阻塞的进程

如果只关心阻塞关系，可以使用电科金仓KingbaseES提供的更简洁的查询方式：

SELECT pid, usename, sys_blocking_pids(pid) AS blocking_pid, query 
FROM sys_stat_activity 
WHERE cardinality(sys_blocking_pids(pid)) > 0;

KingbaseES中的sys_blocking_pids函数返回的是一个进程ID数组，表示当前进程正在被哪些进程阻塞。通过cardinality函数判断数组长度大于0，即可筛选出所有处于被阻塞状态的会话。需要注意的是，目前KingbaseES提供的blocking系统函数只能用于查询重量级锁的冲突，对于轻量级锁（lwlock）等场景并不适用。

二、KingbaseES连接数限制策略

会话管理的另一个重要环节是连接数控制。无序增长的连接数会消耗大量服务器内存，严重时甚至导致操作系统资源耗尽。除了在应用层使用连接池之外，在电科金仓KingbaseES数据库层面进行连接数限制也是必要的防线。

2.1 实例级连接数限制

KingbaseES整个数据库实例的连接数上限由max_connections参数控制，而superuser_reserved_connections参数（默认值为3）则为超级用户预留了一定数量的连接。实际可用于普通用户的连接数等于二者之差：

真实的连接数限制 = max_connections - superuser_reserved_connections

值得一提的是，这是Oracle数据库所没有的对应参数功能。这种设计的意义在于，即使在KingbaseES数据库被大量普通连接占满的极端情况下，超级用户依然能够登录数据库进行排查和处理，避免出现"想救火却进不了门"的尴尬局面。

2.2 数据库级连接数限制

在KingbaseES中，可以针对单个数据库设置连接数上限：

ALTER DATABASE test CONNECTION LIMIT 4;

设置后可以通过sys_database系统视图的datconnlimit字段查看当前限制，值为-1表示无限制：

TEST=# select datname,datconnlimit from sys_database;
  datname  | datconnlimit
-----------+--------------
 security  |           -1
 template1 |           -1
 template0 |           -1
 test1     |           -1
 test      |            4

当超过上限时，新连接将被KingbaseES拒绝，并返回类似too many connections for database "test"的错误提示。

2.3 用户级连接数限制

对于多用户共用一个数据库的场景，KingbaseES支持按用户限制连接数，这种方式更为灵活：

ALTER USER tiutest WITH CONNECTION LIMIT 2;

通过sys_roles视图的rolconnlimit字段可以查看每个角色的连接限制：

TEST=# select rolname,rolconnlimit from sys_roles;
          rolname          | rolconnlimit
---------------------------+--------------
 tiutest                   |            2
 system                    |            1
 u1                        |           -1

当用户达到连接数上限后再次尝试连接时，KingbaseES会返回too many connections for role "tiutest"错误。

需要特别注意的是，在电科金仓KingbaseES中，超级用户不受连接数限制的约束。即使为超级用户设置了CONNECTION LIMIT 1，实际仍可创建多个连接。这是因为超级用户拥有特殊权限，绕过了常规的连接数检查逻辑，这一点在权限规划时需要特别留意。

2.4 KingbaseES连接数限制的最佳实践

在电科金仓KingbaseES的实际部署中，建议采用分层限制的思路：

  1. 整体限制：先在实例级通过max_connections设定整体天花板，根据服务器内存容量合理评估。
  2. 数据库级限制：对多租户数据库使用数据库级限制，确保某个数据库的连接溢出不会影响其他业务。
  3. 用户级限制：对应用账号使用用户级限制，特别是对于经常出现连接溢出的特定用户，可以单独收紧其连接配额。

这种"由粗到细"的策略既能保证整体资源可控，又能避免一刀切带来的灵活性损失。

三、KingbaseES流复制场景下的会话冲突分析

电科金仓KingbaseES支持完善的主备流复制架构，在生产环境中应用广泛。但在主备复制场景下，会话管理还会遇到一类特殊问题——备库上的查询与WAL重放之间的冲突。

3.1 KingbaseES复制冲突相关参数概览

理解KingbaseES复制冲突首先要熟悉几个关键参数：

  • hot_standby_feedback：允许备库将快照信息反馈给主库，从而避免主库过早回收备库长查询所需的旧版本数据。但代价是备库的长查询可能导致主库表膨胀。
  • vacuum_defer_cleanup_age：当触发vacuum时，延迟指定事务后才真正触发清理，以缓解冲突。
  • recovery_min_apply_delay：让备库刻意延迟重放WAL。例如设置为5分钟，则只有在备库时间至少比主库提交时间多五分钟时，备库才会重放WAL，常用于灾备场景。
  • max_standby_streaming_delay：当startup进程replay流式WAL记录时，遇到冲突最多等待多久。
  • max_standby_archive_delay：当startup进程replay归档（restore command）WAL记录时，遇到冲突最多等待多久。

3.2 判断KingbaseES备库冲突是否发生

KingbaseES提供了sys_stat_database_conflicts视图来查看各类冲突的累计次数：

test=# select * from sys_stat_database_conflicts;
 datid |  datname  | confl_tablespace | confl_lock | confl_snapshot | confl_bufferpin | confl_deadlock
-------+-----------+------------------+------------+----------------+-----------------+----------------
 14187 | test      |                0 |          0 |              0 |               0 |              0
 16387 | test      |                0 |          0 |              4 |               0 |              0

判断当前是否存在冲突阻塞，可以观察startup进程的等待事件。当startup进程的等待事件为空时，表示它被堵塞了，可以理解为此时startup进程什么工作也没做：

test=# select * from sys_stat_activity where backend_type ='startup' and wait_event is null;

如果wait_event_type为IO、wait_event为DataFileExtend，则表明startup正在正常重放WAL，这种情况不是conflict堵塞。

如果wait_event为RecoveryWalAll、wait_event_type为Activity，则表示startup在等待新的WAL到达，通常此时备库处于未delay状态，也并非冲突阻塞。

3.3 在KingbaseES中寻找疑似阻塞者

由于KingbaseES现有系统函数无法精确定位阻塞WAL重放的查询，通常需要通过经验性方法推断。一个常用思路是：阻塞WAL重放的查询，往往是事务开始时间最早，或事务号、xmin值最小的那个会话。

按时间最老查找：

SELECT a.* FROM (
  SELECT *, row_number() OVER (PARTITION BY state ORDER BY xact_start) AS rn 
  FROM sys_stat_activity 
  WHERE datname = current_database() 
    AND pid <> sys_backend_pid() 
    AND state <> 'idle'
) a, (
  SELECT * FROM sys_stat_activity 
  WHERE backend_type = 'startup' AND wait_event IS NULL
) b 
WHERE a.rn <= 1 
ORDER BY a.xact_start;

按事务号最老查找：

SELECT a.* FROM (
  SELECT *, row_number() OVER (
    PARTITION BY state 
    ORDER BY least(backend_xid::text::int8, backend_xmin::text::int8)
  ) AS rn 
  FROM sys_stat_activity 
  WHERE datname = current_database() 
    AND pid <> sys_backend_pid() 
    AND state <> 'idle'
) a, (
  SELECT * FROM sys_stat_activity 
  WHERE backend_type = 'startup' AND wait_event IS NULL
) b 
WHERE a.rn <= 1 
ORDER BY least(a.backend_xid::text::int8, a.backend_xmin::text::int8);

需要强调的是，这种方法找到的是疑似阻塞者，结果并不绝对精确。期待未来电科金仓KingbaseES能够提供更精准的关联查询能力，帮助DBA直接定位真正的WAL replay阻塞者。

3.4 查看KingbaseES备库WAL重放的滞后情况

在KingbaseES备库上，要了解还有多少WAL未重放，可以使用：

SELECT sys_is_wal_replay_paused(), 
       sys_last_wal_receive_lsn(),
       sys_last_wal_replay_lsn(), 
       sys_size_pretty(sys_wal_lsn_diff(sys_last_wal_receive_lsn(), sys_last_wal_replay_lsn()));

返回结果示例：

 sys_is_wal_replay_paused | sys_last_wal_receive_lsn | sys_last_wal_replay_lsn | sys_size_pretty
--------------------------+--------------------------+-------------------------+-----------------
 f                        | 4/A5C524A0               | 4/A5C524A0              | 0 bytes

这条查询返回WAL重放是否暂停、最新接收的LSN位置、最新重放的LSN位置，以及二者之间的差值大小。差值持续增长是KingbaseES主备复制延迟加剧的明确信号，需要立即介入排查。

四、KingbaseES轻量级锁等待事件的识别与处理

会话管理中还有一类容易被忽视的问题——轻量级锁（lwlock）等待。在电科金仓KingbaseES V8R6中，以buffer_mapping等待事件为例，它发生在会话尝试将数据块与共享缓冲池中的缓冲区建立映射关系时。

4.1 KingbaseES中buffer_mapping等待事件的成因

轻量级锁类似于Oracle中的闩锁。在KingbaseES中，为了降低多个后端进程访问哈希表时的冲突，采用了分区锁机制，将整个HASH TABLE分为多个部分（默认通常为128个，具体数目视版本而定），每个部分配备一个lwlock。

当多个后端进程访问缓冲区时，它们首先计算HASH值以确定HASH TABLE的位置，然后获取相应的BufMappingLock，以便进一步访问HASH TABLE、查找HASH CHAIN，并最终定位到特定的BUFFER。如果两个后端进程访问的BUFFER位于不同的分区锁范围内，则不会发生冲突；如果位于相同分区，则可能产生冲突。

LWLock:buffer_mapping等待事件在KingbaseES V8R6中主要发生在三种场景：

  1. 当进程在缓冲区表中搜索页面，并尝试获取共享缓冲区映射锁时。
  2. 当进程需要将页面加载到缓冲池中，并因此获取独占缓冲区映射锁时。
  3. 当进程从缓冲池中删除页面，并获取独占缓冲区映射锁时。

这些场景反映了KingbaseES在处理缓冲区访问和管理时的不同操作需求，其中锁的获取是为了确保数据的一致性和完整性。

4.2 等待事件异常升高的常见原因

当KingbaseES中buffer_mapping等待事件异常增多时，通常可以归结为以下几类原因：

  • 执行大型长时间查询
  • 索引和表存在过度膨胀
  • 频繁进行全表扫描
  • 共享缓冲池shared_buffers配置过小

4.3 KingbaseES优化方向

针对这类问题，可以从几个方向入手优化电科金仓KingbaseES数据库：

1. 评估索引策略：确保索引和表没有过度膨胀，这可能导致不必要的页面读取。对于含有大量冗余行的表，建议先归档删除无用数据再重建索引，这通常比一边维护索引一边清理表更高效。

2. 优化常用查询的索引覆盖度：检查KingbaseES sys_stat_database视图中的tup_returned和tup_fetched指标，确认索引是否能够有效支持查询。如果读取的行数明显高于返回给客户端的行数，可能需要重新设计索引。

3. 减少缓冲区需求：通过实施小批量操作或对大表进行分区，降低对缓冲区的需求。KingbaseES提供了完善的分区表功能，可以充分利用。

4. 增加共享缓冲区大小：如果服务器有足够的内存，可以考虑增加shared_buffers参数的值，这有助于减少等待事件发生频率。

通过这些方法，可以有效减少KingbaseES中LWLock:buffer_mapping等待事件的发生，提升数据库整体性能。

五、总结

会话与进程管理贯穿电科金仓KingbaseES数据库运维的方方面面，从日常的慢查询排查到极端场景下的复制冲突分析，都依赖于对系统视图和等待事件的深入理解。一个成熟的KingbaseES DBA应当熟练掌握以下核心能力：

  • 熟练使用sys_stat_activity、sys_stat_database_conflicts、sys_database、sys_roles等核心系统视图
  • 能够通过sys_blocking_pids等KingbaseES提供的函数快速定位锁冲突
  • 能够通过等待事件识别底层资源争抢
  • 能够根据业务特征制定合理的连接数限制策略
  • 在主备流复制环境下能够准确判断WAL重放是否被阻塞，并定位疑似阻塞者

更重要的是，会话管理不应只是被动的"救火"，而应当是主动的"防火"。通过定期审视长事务、监控连接数趋势、分析等待事件分布，可以在问题真正爆发之前就识别出潜在的风险点。

作为国产数据库的代表，电科金仓KingbaseES在持续演进中不断完善其会话管理能力。希望本文梳理的方法和SQL语句，能够为广大KingbaseES DBA在实际运维工作中提供有价值的参考。

avatar
文章
阅读
粉丝