企业官网建设流程全解析

OceanBase 监控实战：6 个数据库性能指标与阈值快速上手

【免费下载链接】oceanbaseOceanBase is the unified distributed database for the AI era — open-source, multi-model, one engine for your most demanding workloads.项目地址: https://gitcode.com/GitHub_Trending/oc/oceanbase

本文面向 OceanBase 分布式数据库的运维与开发人员（含新手入门者）：用 6 个数据库性能指标解决"监控不知道盯哪个、阈值拍脑袋"的问题。6 分钟读完，可直接落地线上告警规则配置，慢查询定位不再靠猜。

🎯 先搞清该盯哪些数

OceanBase 把指标分成三级：核心（CRITICAL）必须实时盯，预警（STANDARD）日常巡检看，调试（AD_HOC）只在排查具体问题时才翻。指标 ID、单位和级别都定义在 src/share/diagnosis/ob_sql_monitor_statname.h，按这个级别表选指标就行。

日常巡检只盯三件事：IO 等待、哈希表、过滤效果。其余指标等出症状再按图索骥。

🔍 按症状排查：4 类常见故障的指标组合

响应突然变慢：先看 IO 等待，再看读放大

现象：业务 P99 延迟从毫秒跳到秒级，但 CPU 并不高。

阈值参考：IO_TIME 均值超过 50ms 算异常；IO_READ_BYTES 与 OUTPUT_ROWS 比值超过 1KB/行，提示读放大。

第一个动作：从 SQL 监控里拉出最慢的 5 条 SQL，对比它们读盘字节数是否明显偏高。

内存持续上涨：先查 memstore，再查哈希表

现象：租户内存占用数天内阶梯式上涨，业务低峰也不回落。

阈值参考：memstore 超过租户内存限额的 80% 即重大预警，留 20% 余量防冻结时抖动。

第一个动作：确认租户是否在做 major 冻结；不在冻结就通过 SQL 监控找哈希表最大的那条 SQL。内存模型细节见 docs/memory.md。

连接数吃紧：先分活跃和空闲

现象：应用报 "too many connections"，但数据库 CPU 仍然很低。

阈值参考：连接数超过上限 70% 警告、90% 严重；空闲会话超过 80% 时，问题大概率在应用连接池而不是数据库。

第一个动作：数一下空闲会话数量。多数空闲就先收应用侧连接池超时时间，别急着在数据库侧扩上限。

长事务堆积：看事务持续时长

现象：锁等待变多，其他 SQL 报超时，回滚率抬升。

阈值参考：单事务超过 10 分钟就要点名跟进；回滚率超过 1% 提示存在锁争用。

第一个动作：找到持续最久的那个会话，先与业务确认能否提交，不要直接杀掉。

📐 阈值怎么定：基线 + 三倍标准差

写死的数字只对刚上线的集群好用。更稳的做法是滚动基线：取该指标过去 24 小时为窗口，均值当基线，告警线设为基线加 3 倍标准差。正常波动不会误报，真异常会立刻冒出来。举一个具体场景：连接数上限 5000，警告线取 70% 即 3500，严重线取 90% 即 4500。大促预计流量上浮 50% 时，把上限临时提到 7500，警告线同步到 5250、严重线 6750；同时慢查询阈值从 1 秒放宽到 3 秒，IO 等待阈值从 50ms 放到 75ms，活动结束后再恢复原值。

⚡ 5 分钟排查 SOP：命令、指标、判断一次说清

1. 找慢 SQL。执行下面这条查询，看 elapsed_time 超 5 秒的语句：

SELECT sql_id, elapsed_time, io_time FROM oceanbase.gv$ob_sql_monitor WHERE elapsed_time > 5000000 ORDER BY elapsed_time DESC LIMIT 5;

有结果就锁定该 sql_id 进第 2 步；没结果直接跳到第 4 步。

2. 看时间花在哪。对锁定的 sql_id 看 IO_TIME 和 OUTPUT_ROWS：IO_TIME 大于 50ms 判为 IO 问题，先查磁盘与缓存；OUTPUT_ROWS 异常大判为计划问题，重新审视执行计划。达标（都正常）则进第 3 步。

3. 查长事务。查oceanbase.__all_virtual_trans_stat：存在持续超 10 分钟的活跃事务，联系业务提交；没有，则本次症状为孤立事件，观察 10 分钟复测。

4. 查内存与连接。看租户 memstore 使用率与 processlist 会话数：memstore 超 80% 或连接数超上限 90%，按上一章两条分支处理；都正常，问题大概率在应用侧或网络侧，转交应用排查。

5. 出结论。用一句话写明哪个指标越线、做了什么处置，同步到值班群；复发两次的问题，就把它的阈值固化成正式告警规则。自动巡检脚本可参考 script/dooba/。

✅ 落地清单

• 从核心级指标里挑 5 个接入告警，先覆盖 CRITICAL 再扩 STANDARD
• 给 memstore、连接数、IO 等待各配警告/严重两档线，并写进值班文档
• 用"24 小时基线 + 3 倍标准差"每月重算一次各条线
• 把 5 步 SOP 放进值班手册，让新同学照着也能独立执行
• 用一次真实慢查询定位案例，验证指标链路和告警规则都有效

告警线不是一劳永逸的，每次事件复盘后回头看一步，你的监控就会比上个月更准。

【免费下载链接】oceanbaseOceanBase is the unified distributed database for the AI era — open-source, multi-model, one engine for your most demanding workloads.项目地址: https://gitcode.com/GitHub_Trending/oc/oceanbase