数据库的一些等待事件的疑问

OceanBase 技术问题
#1

【 使用环境 】生产环境
【 OB or 其他组件 】OB
【 使用版本 】4.2.1.4
【问题描述】数据库出现很多latch: default spin rwlock wait和latch: default bucket lock wait等待事件，对于ash中这些事件占的比较多的sql要怎么处理，这块的资料比较缺乏

image
image1746×198 12.4 KB

image
image1738×204 12.4 KB

【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！

#3

从您的描述来看，您在使用 OceanBase 4.2.1.4 版本的过程中遇到了大量的 latch 等待事件，这通常表明存在较高的锁竞争情况。这类问题可能会影响系统的整体性能，尤其是在 Application Support History (ASH) 报告中显示这些等待事件占比很高时，说明它们对 SQL 查询的执行效率产生了显著影响。

针对这种情况，我们可以先通过 obdiag 工具来采集一些必要的诊断信息，以便进一步分析问题的原因。不过，根据现有的 obdiag 支持的场景，这里更适合进行日志采集而非直接进行根因分析，因为 obdiag 目前还没有直接针对 latch 竞争问题的根因分析场景。

日志采集场景: 内存问题

日志采集命令:

obdiag gather scene run --scene=observer.memory

该命令会收集与内存相关的信息，包括但不限于锁竞争的情况，这对于理解 latch 等待事件的上下文非常有帮助。

推荐步骤:

  1. 执行上述命令，并等待命令执行完毕。这将生成一个包含诊断信息的压缩文件。
  2. 上传压缩文件，您可以将这个文件发送给我们，我们将进一步分析这些 latch 等待事件的具体原因。

为了更准确地定位问题，请您提供以下信息：

  1. SQL执行频率和并发度: 您能否提供这些 SQL 的执行频率和并发度信息？这有助于了解是否存在某些特定 SQL 导致了锁的竞争。
  2. 数据库负载: 当前数据库的负载情况如何？是否有其他操作或任务正在运行，可能会导致锁竞争加剧？
  3. 配置信息: 您是否对数据库进行了任何特殊配置调整？例如，与锁相关的参数设置。
  4. 业务场景: 您能否简单描述一下业务场景？这有助于我们理解 SQL 的执行背景及其重要性。

附上敏捷诊断工具 obdiag 使用帮助链接

#4

通过查询DBA_WR_SYSTEM_EVENT表来查看系统级别的等待事件统计情况。以下是一个示例查询结果：
obclient [oceanbase]> SELECT * FROM oceanbase.DBA_WR_SYSTEM_EVENT LIMIT 10;
±--------±---------------±---------±---------±------------------------------------------±--------------±------------±------------±---------------±------------------+
| SNAP_ID | SVR_IP | SVR_PORT | EVENT_ID | EVENT_NAME | WAIT_CLASS_ID | WAIT_CLASS | TOTAL_WAITS | TOTAL_TIMEOUTS | TIME_WAITED_MICRO |
±--------±---------------±---------±---------±------------------------------------------±--------------±------------±------------±---------------±------------------+
| 1 | 172.xx.xxx.xxx | 2882 | 2 | latch: default spin rwlock wait | 104 | CONCURRENCY | 7 | 0 | 113693 |
| 1 | 172.xx.xxx.xxx | 2882 | 3 | latch: default mutex wait | 104 | CONCURRENCY | 517 | 0 | 29687 |
| 1 | 172.xx.xxx.xxx | 2882 | 8 | latch: trans ctx latch wait | 104 | CONCURRENCY | 84 | 0 | 68001 |
| 1 | 172.xx.xxx.xxx | 2882 | 33 | latch: ls latch wait | 104 | CONCURRENCY | 2 | 0 | 9829 |
| 1 | 172.xx.xxx.xxx | 2882 | 40 | latch: config lock wait | 104 | CONCURRENCY | 20 | 0 | 358460 |
| 1 | 172.xx.xxx.xxx | 2882 | 47 | latch: rs bootstrap lock wait | 104 | CONCURRENCY | 1 | 0 | 29706546 |
| 1 | 172.xx.xxx.xxx | 2882 | 55 | latch: unit manager lock wait | 104 | CONCURRENCY | 2 | 0 | 2965 |
| 1 | 172.xx.xxx.xxx | 2882 | 92 | latch: block manager lock wait | 104 | CONCURRENCY | 1 | 0 | 5 |
| 1 | 172.xx.xxx.xxx | 2882 | 99 | latch: tablet bucket lock wait | 104 | CONCURRENCY | 3 | 0 | 2684 |
| 1 | 172.xx.xxx.xxx | 2882 | 202 | latch: zone merge manager write lock wait | 104 | CONCURRENCY | 1 | 0 | 554 |
±--------±---------------±---------±---------±------------------------------------------±--------------±------------±------------±---------------±------------------+
10 rows in set
从这个查询结果中我们可以看到，确实存在latch: default spin rwlock wait等待事件，但是没有直接提到latch: default bucket lock wait这一特定类型的等待事件。
针对latch: default spin rwlock wait这类等待事件，我们可以观察到它属于CONCURRENCY等待类别，并且在这个例子中有7次等待记录，总等待时间为113,693微秒。这表明数据库中可能存在一些并发操作导致了这些等待的发生。
通常来说，latch等待事件的发生可能是因为数据库内部的一些资源竞争，例如并发的事务处理或数据结构访问等。具体原因可能包括但不限于：

多个事务同时访问同一资源。
数据库内部的缓存管理机制。
并发控制策略。

为了进一步诊断问题，您可以考虑以下步骤：

分析具体的等待事件：检查DBA_WR_SYSTEM_EVENT表中与latch相关的其他等待事件，了解是否有特定的模式或趋势。
监控SQL执行：使用DBA_HIST_SQLTEXT等视图来查看是否有某些SQL语句频繁触发这些等待事件。
调整并发设置：根据具体情况调整数据库的并发控制参数，比如事务隔离级别等。
优化SQL语句：如果发现某些SQL语句是问题的根源，尝试优化这些语句以减少对共享资源的竞争。

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

oceanbase.DBA_WR_SYSTEM_EVENT