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_TIME、DB_TIME、OUTPUT_ROWSSQL 等 IO 多久、跑多久、产出多少SQL 监控视图 gv$ob_sql_monitor核心HASH_BUCKET_COUNTjoin/聚合哈希表大小过大直接吃内存同视图按算子看预警IO_READ_BYTES读盘总字节数读放大信号同视图按执行计划看预警JOIN_FILTER_FILTERED_COUNTjoin filter 命中行数过滤是否有效同视图调试DTL_LOOP_TOTAL_MISS、OPEN_TIME算子级执行细节见 src/share/diagnosis/runtime_profile_cn.md日常巡检只盯三件事IO 等待、哈希表、过滤效果。其余指标等出症状再按图索骥。 按症状排查4 类常见故障的指标组合响应突然变慢先看 IO 等待再看读放大现象业务 P99 延迟从毫秒跳到秒级但 CPU 并不高。指标看什么IO_TIME单次执行平均 IO 等待IO_READ_BYTES读盘字节数除以输出行数看读放大OUTPUT_ROWS该 SQL 实际产出行数阈值参考IO_TIME 均值超过 50ms 算异常IO_READ_BYTES 与 OUTPUT_ROWS 比值超过 1KB/行提示读放大。第一个动作从 SQL 监控里拉出最慢的 5 条 SQL对比它们读盘字节数是否明显偏高。内存持续上涨先查 memstore再查哈希表现象租户内存占用数天内阶梯式上涨业务低峰也不回落。指标看什么memstore 使用率租户级内存表占用HASH_BUCKET_COUNT是否存在单条 SQL 哈希表异常大MEMORY_DUMP是否已触发内存落盘阈值参考memstore 超过租户内存限额的 80% 即重大预警留 20% 余量防冻结时抖动。第一个动作确认租户是否在做 major 冻结不在冻结就通过 SQL 监控找哈希表最大的那条 SQL。内存模型细节见 docs/memory.md。连接数吃紧先分活跃和空闲现象应用报 too many connections但数据库 CPU 仍然很低。指标看什么__all_virtual_processlist当前会话清单区分活跃与空闲空闲会话占比判断问题在应用还是数据库阈值参考连接数超过上限 70% 警告、90% 严重空闲会话超过 80% 时问题大概率在应用连接池而不是数据库。第一个动作数一下空闲会话数量。多数空闲就先收应用侧连接池超时时间别急着在数据库侧扩上限。长事务堆积看事务持续时长现象锁等待变多其他 SQL 报超时回滚率抬升。指标看什么__all_virtual_trans_stat活跃事务清单与持续时长回滚率同期回滚事务占比阈值参考单事务超过 10 分钟就要点名跟进回滚率超过 1% 提示存在锁争用。第一个动作找到持续最久的那个会话先与业务确认能否提交不要直接杀掉。 阈值怎么定基线 三倍标准差写死的数字只对刚上线的集群好用。更稳的做法是滚动基线取该指标过去 24 小时为窗口均值当基线告警线设为基线加 3 倍标准差。正常波动不会误报真异常会立刻冒出来。举一个具体场景连接数上限 5000警告线取 70% 即 3500严重线取 90% 即 4500。大促预计流量上浮 50% 时把上限临时提到 7500警告线同步到 5250、严重线 6750同时慢查询阈值从 1 秒放宽到 3 秒IO 等待阈值从 50ms 放到 75ms活动结束后再恢复原值。⚡ 5 分钟排查 SOP命令、指标、判断一次说清找慢 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 步。看时间花在哪。对锁定的 sql_id 看 IO_TIME 和 OUTPUT_ROWSIO_TIME 大于 50ms 判为 IO 问题先查磁盘与缓存OUTPUT_ROWS 异常大判为计划问题重新审视执行计划。达标都正常则进第 3 步。查长事务。查oceanbase.__all_virtual_trans_stat存在持续超 10 分钟的活跃事务联系业务提交没有则本次症状为孤立事件观察 10 分钟复测。查内存与连接。看租户 memstore 使用率与 processlist 会话数memstore 超 80% 或连接数超上限 90%按上一章两条分支处理都正常问题大概率在应用侧或网络侧转交应用排查。出结论。用一句话写明哪个指标越线、做了什么处置同步到值班群复发两次的问题就把它的阈值固化成正式告警规则。自动巡检脚本可参考 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考