OBServer 系统高负载处理

本文主要介绍 OBServer 系统高负载问题的排查方法。

问题描述

如果 OBServer 独占机器上的物理资源，当 CPU 使用率升高至 85% 以上时，可能会出现系统的 CPU 瓶颈，导致 OBServer 在执行请求时获取不到需要的 CPU 资源，最终导致 OceanBase 要处理的请求（租户请求、系统请求等）滞后、阻塞甚至失败。此时，您可以根据以下思路对问题进行分析，并做出相应的操作来规避或者解决问题。

问题排查思路

OBServer 是一个支持多租户架构的分布式数据库，应用系统通过业务租户连接数据库，来进行数据库的相关操作。在 OceanBase 对租户进行初始化时，需要通过资源单元对租户可用的资源（包含 CPU、内存等）进行配置。当租户的资源单元不足以负担负载时，会导致租户队列堆积，请求处理滞后甚至中断，最终影响应用。

当出现 OBServer 请求滞后、请求整体变慢，特别是伴随着 CPU 升高的现象时，需要正确的诊断判断系统瓶颈。一般情况下，需要做以下排查：

1. 检查 OBServer 是否存在整体性的系统资源不足。

   通过 top 命令查看实时的 CPU 使用情况或用 tsar 命令查看 CPU 使用率历史或通过 topH 直接查看消耗 CPU 的线程。根据使用情况判断当前消耗 CPU 较高的是租户线程或后台线程。从而进行如下判断：

   a. 业务负载发生变化

   通过观察线程消耗 CPU 的情况，判断当前是否业务负载增加，包含负载并发量、负载类型。如果是增加了业务负载，考虑慢 SQL 的影响，然后找到对应的 SQL，进行优化或负载限流处理。

   b. 业务负载无明显变化

   此时，OBServer 消耗 CPU 突然增高，也没有直接的线索能够找到造成 CPU 负载增高的原因，需要进一步考虑 OceanBase 内核的原因。请联系 OceanBase 技术支持人员获取 obstack 工具来捕获 OB 的线程栈进行分析。

2. OBServer 整体的 CPU 使用率有可能并没有发生巨大的飙升，但是当前租户的租户请求产生了缓慢、滞后、甚至中断的情况。

   此时很可能是因为租户的队列产生了积压，您可在 observer.log 里面搜索 dump tenant info 关键字。对应租户中如果有 req_queue 字段则显示队列中有请求挤压（请求数不为 0），您可进行以下分析：

   a. 租户资源规格是否过小。

   当租户是第一次使用的时候，需要按照规划的租户大小来承载预期的业务量。如果租户资源规格设置的过小，就会引起租户的请求堆积的情况。从而使租户或者 OBServer 处在高负载的状态。在资源足够的情况下应当适当调高资源规格或者是 unit number 来增大租户的能力。

   b. 高业务负载、变化的 SQL 进入系统。

   此时可以通过 OCP 的 Top SQL 功能进行诊断。

   c. 业务负载没有明显变化。

   此时租户的基本配置也符合预期的情况下，需要进一步考虑 OceanBase 内核的原因。请联系 OceanBase 技术支持人员获取 obstack 工具来捕获 OB 的线程栈进行分析。