oms-kafka-performance

name: oms-kafka-performance description: 标准 SOP：OceanBase 社区版经 OMS 同步至 Kafka 的延迟、吞吐与调优。涵盖全量/增量并发与限速、KafkaSink、OMS 平台 limitator 与 JVM、源端 OB 与表结构策略；与 observer 日志、OBProxy、单条 SQL 深查 skill 分工明确。

OceanBase 社区版 → Kafka（OMS）：性能排查与调优

使用场景

• 排查 OMS 同步到 Kafka 的 延迟、吞吐不足 或组件跟不上（如 Incr-Sync 落后 Store）。
• 调优 全量导入（Full-Import） 或 增量同步（Incr-Sync） 到 Kafka。
• 配置 Kafka 数据源、KafkaSink 的读写并发、RPS/BPS 限速、序列化与分区规则。
• 优化 OMS 平台线程、批处理、连接数与 JVM，或 OceanBase 服务端与表结构以配合同步负载。

与其它 skill 的分工

工具与取证（Agent）

• OMS 日志 ≠ analyze_log：analyze_log 仅 observer 侧。OMS / Ghana / CDC 用 Agent 工具 gather_oms_log（封装 obdiag gather oms_log），成功后在同一轮内对 pack 目录 file_list / file_read；遇 .tar.gz / .zip 先 run_shell 解压（需审批）— 流程对齐 obproxy-log-analysis。
• config.yml 的 oms 段：必须配置正确，否则 gather_oms_log 会失败。CDC 类 scope（如 cdc、libobcdc）常需 oms_component_id，格式为 IP-进程编号（例如 192.168.1.100-1）；具体值可在 OMS 控制台「组件管理」或 obdiag gather oms_log --help 查看。
• gather_oms_log 失败排查：优先检查 config.yml 中 oms 段（主机、端口、SSH 凭据）是否填写完整；其次确认 OMS 机器 SSH 可达且 obdiag 对应版本支持；必要时用 run_shell 在 OMS 机器本地查看日志路径。
• 若无 Agent、仅终端：可手动执行 obdiag gather oms_log ...；已有 obdiag_gather_pack_* 时直接用 file_list / file_read。

阶段 1：性能排查思路

• 看延迟：关注 oms_sync_delay 等；若 Incr-Sync 落后 Store，延迟会逐渐拉大，从消费端并发与资源入手。
• 看瓶颈：区分 源端（OceanBase）读压、OMS 处理、目标端（Kafka）写压；结合监控与限速配置反推。
• 看限速：全量/增量均可配 RPS、BPS；实际吞吐还受源、目标与规格影响，限速多为上限与保护。

完成标准：能说明当前更怀疑哪一侧（OB / OMS / Kafka），并给出下一步（采日志、看指标、调参建议）。

阶段 2：OMS 平台侧调优（全量/增量通用）

• 并发与线程：如调大 limitator.platform.threads.number（例：32→64）。
• 批处理：如调大 limitator.select.batch.max（例：1200→2400）、limitator.image.insert.batch.max（例：200→400）。
• 连接数：如调大 limitator.datasource.connections.max（例：50→200）。
• JVM：按机器资源增大堆（例：由 -Xms16g -Xmx16g -Xmn8g 调至更大规格）。
• 经验量级：单并发网络流入约 1–2M、RPS 约千级，视字段与行宽而定。

完成标准：列出已建议项与风险提示（过高并发压垮源端或 Kafka）。

阶段 3：Kafka 同步专项配置

• 全量：读取/写入并发（最大均 512 等，以文档为准）；全量 RPS/BPS 限速。
• 增量：写入并发与增量 RPS/BPS；关注 消息顺序 策略（见官方文档）。
• KafkaSink：序列化（Default、Canal、Debezium、Avro 等）；分区规则（Hash、Table、One 等）。
• 注意：并发逐步提高并结合监控。

阶段 4：OceanBase 源端（配合高负载）

• 日志压缩，减少 clog：enable_clog_persistence_compress（默认关）建议开启。
• 合并相关：merge_thread_count（建议 4–16，视核数）、_mini_merge_concurrency（建议 4–8）、minor_merge_concurrency（建议 4–8）。
• 转储/冻结与内存：关注 freeze_trigger_percentage（默认 70）与 memstore_limit_percentage（默认 50）；高写入时可适当上调。
• 必要时写入限流：writing_throttling_trigger_percentage（默认 60，降低可缓解写入压力）。
• 变更提醒：上述参数均需 ALTER SYSTEM SET ... = ...，由 DBA 在维护窗口执行；调整前确认当前值（可通过 db_query 查 gv$ob_parameters）。

说明：Agent 默认 db_query 只读；涉及 ALTER SYSTEM 等变更时输出 建议 SQL / 运维步骤，由 DBA 在变更窗口执行。

阶段 5：表结构与迁移策略

• 分区表全量：可评估改为非分区（单表规模上限以官方与现场规范为准）；全量前可临时删二级索引，完成后重建。
• 大表、宽表：关注批大小与并发，避免单线程或小批次成瓶颈。

阶段 6：文档与社区

• 全量/增量调优、Kafka 数据源与 KafkaSink 以 当前 OMS 版本文档 为准。
• 延迟指标、顺序、认证（如 GSSAPI）等可查社区问答与云厂商帮助文档。
• 参数名随版本变化时，用 query_oceanbase_knowledge_base 核对，query 中写明 OMS 与 OB 版本。

输出与自检

• 输出：瓶颈判断、可执行调优项（分 OMS / Kafka / OB）、下一步取证（日志路径、指标、CLI）。
• 自检：
  • 未用 analyze_log 充当 OMS 日志分析。
  • 用户要「采集 + 解读」OMS 日志时，是否在同一轮内调用 gather_oms_log + file_list/file_read（及必要时解压）？
  • 改参类建议是否标明 需人工执行 与 风险？