configuration_lock_wait等待事件占比高

OceanBase 技术问题
,
#1

【 使用环境 】生产环境 or 测试环境
【 OB or 其他组件 】
【 使用版本 】4.3.5
【问题描述】configuration_lock_wait,在进行sysbench压测时，这个等待事件很高，是什么原因？

Clipboard_Screenshot_1784029982
Clipboard_Screenshot_17840299821200×1190 99.4 KB

8 个赞
#3

是不是哪个SQL语句执行的太慢了，还是有锁什么的

1 个赞
#4

@论坛小助手

#5

分析与建议

根据您提供的信息，configuration_lock_wait 等待事件在进行 sysbench 压测时占比较高。这种现象通常是由于系统中存在配置锁的争用问题。以下是对该问题的分析和可能的解决方案：

1. configuration_lock_wait 等待事件的含义

  • configuration_lock_wait 等待事件通常表示会话在等待获取或释放配置锁（Configuration Lock）。配置锁是 OceanBase 中用于管理数据库配置变更的一种机制。
  • 当多个会话同时尝试修改或读取某些配置项时，可能会导致配置锁的争用，从而产生等待。

2. 可能的原因

  • 高并发压力：在高并发场景下，如果频繁地修改或读取某些配置项，可能会导致配置锁的争用。
  • 配置变更频繁：如果在压测过程中有频繁的配置变更操作，也会增加 configuration_lock_wait 的等待时间。
  • 配置锁竞争：如果多个会话同时尝试访问或修改同一配置项，会导致配置锁的竞争。

3. 解决方案

  • 减少配置变更：尽量避免在高并发压测过程中进行频繁的配置变更。如果必须进行配置变更，可以考虑在压测之前或之后进行。
  • 优化配置项访问：检查并优化代码中对配置项的访问逻辑，减少不必要的配置读取和写入操作。
  • 调整配置参数：您可以尝试调整与配置锁相关的参数，例如 trx_try_wait_lock_timeout，以减少等待时间。具体的配置参数调整请参考 锁相关配置项。

4. 监控与诊断

  • 监控等待事件：使用 GV$SYSTEM_EVENT 视图来监控 configuration_lock_wait 等待事件的统计信息，以了解具体的等待次数和等待时间。
    obclient> select tenant_id, tenant_name, sum(total_waits) as total_waits, sum(time_waited_micro) / 1000000 as time_waited_seconds
from v$system_event join DBA_OB_TENANTS
on v$system_event.con_id = DBA_OB_TENANTS.tenant_id
where v$system_event.wait_class <> 'IDLE' and DBA_OB_TENANTS.tenant_type!='META'
group by tenant_name;
  • 查看等待明细：使用 GV$SESSION_WAIT 视图来查看具体的等待明细，帮助定位问题。
    obclient> select * from GV$SESSION_WAIT where EVENT='configuration_lock_wait' and STATE='WAITING' \G

5. 其他建议

  • 资源隔离：确保压测环境与生产环境隔离，避免影响生产环境的性能。
  • 性能调优：结合其他性能指标（如 CPU 使用率、内存使用情况等）进行综合分析，进一步优化系统性能。

通过上述方法，您可以更有效地定位和解决 configuration_lock_wait 等待事件占比高的问题。如果问题依然存在，建议联系 OceanBase 的技术支持团队以获取更多帮助。

具体信息可参考以下文档:

  1. 等待事件
  2. 内部等待问题
  3. 配置项总览
  4. 分析 ASH 报告
1 个赞
#6

sysbench 压测时 租户工作线程处理能力不足，请求在队列里大量排队等, 检查一下租户 CPU 规格、cpu_quota_concurrency、sysbench 并发线程数 三者是否匹配。

1 个赞
#7

租户的cpu规格时40核心，cpu_quota_concurrency这个参数默认值4，调整为了8，查看可用的应该是322工作线程。sysbench压测时128线程，
±------------±--------------±---------------------------±-------------±-----+
| svr_ip | wait_class | event | sample_count | pct |
±------------±--------------±---------------------------±-------------±-----+
| 10.40.xxx | OTHER | | 7582 | 33.5 |
| 10.40xxx | OTHER | | 7326 | 32.4 |
| 10.40.xxx | OTHER | | 7119 | 31.4 |
| 10.40.xxx | IDLE | mysql response wait client | 89 | 0.4 |
| 10.40.xxx | CONFIGURATION | wait in request queue | 84 | 0.4 |
| 10.40.xxx | IDLE | mysql response wait client | 84 | 0.4 |
| 10.40.xxxx | CONFIGURATION | wait in request queue | 79 | 0.3 |
| 10.40.xxx | CONFIGURATION | wait in request queue | 75 | 0.3 |
| 10.40.xxx | IDLE | mysql response wait client | 53 | 0.2 |
| 10.40.xxx | OTHER | exec inner sql wait | 22 | 0.1 |
| 10.40.xxx | OTHER | exec inner sql wait | 21 | 0.1 |
| 10.40.xxx | NETWORK | sync rpc | 20 | 0.1 |
| 10.40.xxx | OTHER | exec inner sql wait | 18 | 0.1 |
| 10.40.xxx| SYSTEM_IO | palf write | 16 | 0.1 |
| 10.40.xxx | SYSTEM_IO | palf write | 13 | 0.1 |
| 10.40.xxx | SYSTEM_IO | palf write | 11 | 0.0 |
| 10.40.xxx | NETWORK | sync rpc | 11 | 0.0 |
| 10.40.xxx | COMMIT | sync tx commiting wait | 6 | 0.0 |
| 10.40.xxx | CONCURRENCY | slog flush condition wait | 3 | 0.0 |
| 10.40.xxx | USER_IO | db file data read | 2 | 0.0 |
±------------±--------------±---------------------------±-------------±-----+
unit_min_cpu: 40
unit_max_cpu: 40
token_cnt: 322
ass_token_cnt: 322
lq_tokens: 0
workers: 322
lq_waiting_workers: 0
actives: 322
req_queue_total_size: 0
queue_0: 0
queue_1: 0
queue_2: 0
queue_3: 0
queue_4: 0
queue_5: 0

1 个赞
#8

现在看着几乎没有队列等待呀 wait in request queue 只有 0.3%~0.4% 看着只有极少数采样点落在“等 worker 处理”上，属于正常抖动，不是系统性瓶颈

1 个赞
#9

关于configur的见解很独特，受益匪浅。

1 个赞
#10

学到了

1 个赞
#11

此处标记一下，以后有问题来看

1 个赞
#12

great

1 个赞
#13

点赞~~

1 个赞
#14

逻辑清晰。

#15

签到…

#16

干货满满！

#17

configuration_lock_wait 是内部配置变更串行锁，压测时高说明有频繁的 DDL/配置变更并发。排查：是否有自动转储或合并与压测并发；调大合并间隔或错峰执行。纯 DML 压测不应有此等待。