租户内存超限

本节介绍内存超限的问题排查方法。

问题现象

当集群中出现租户内存使用超限或异常时，客户端会报错 Over tenant memory limits，错误码 4030 或 4013，租户内存不足。OCP 中收到如下图所示的日志告警：

收到相关告警后，管理员需要登录对应告警对象的 OceanBase 集群的 sys 租户，进行具体原因定位。

问题排查思路

通常租户内存使用问题跟用户使用行为相关，比如存在慢 SQL、大事务或配置不当等，因此可以使用 OCP 性能趋势和 SQL 监控两个监控功能排查定位。如果能排除这些常见原因的影响，请联系 OceanBase 技术支持人员处理。

租户性能趋势排查

在使用 OCP 租户级别性能监控前，需要先登录 sys 租户，根据报错日志中的 tenant_id 信息，使用下面的 SQL 查询到具体告警租户名称。如上图的日志告警中 tenant_id 为 1006，SQL 语句示例如下：

obclient> SELECT tenant_name FROM __all_tenant WHERE tenant_id IN (1006);

查询到对应租户名后，在 OCP 中找到对应集群租户的性能监控展示界面，详细操作信息，请参见 租户性能诊断。

在租户的 性能监控 页面中主要关注指标 QPS 、 响应时间 、 TPS 、 事务响应时间 和 MEMStore，并找到告警对应时间点，确认是否符合预期。一般在告警时间点附近，以上监控指标变化情况可能包括以下几种情况：

• 事务响应时间突然明显升高，其他指标无明显变化趋势，同时 MEMStore 指标未达到合并阈值。这种情况说明查询中存在大查询，且大查询消耗内存超过阈值触发了日志告警。

• 事务响应时间突然明显升高，同时响应时间也有升高趋势但是其他指标变化不明显，且 MEMStore 指标未达到合并阈值。这种情况说明租户执行了一些大事务，事务消耗内存超过阈值触发了日志告警，同时对查询性能也造成了一定影响。

• QPS 。 和 TPS 同时有下降趋势，且事务响应时间有升高趋势，而 MEMStore 指标已经达到合并阈值但未出现下降。这种情况说明租户可用内存无法通过转储或合并进行释放，很有可能与转储或合并异常有关，详细操作信息，请参见 合并问题排查。

用户 SQL 监控排查

在排查完性能趋势变化后，除发生合并异常的情况外，由于大查询或大事务引起的租户内存使用超限问题，均需要通过 OCP 监控中的 SlowSQL 监控功能进行慢查询定位。

问题排查方法

当遇到租户内存不足的情况下，具体的问题排查方法如下：先排除几个常见问题的原因，如慢 SQL、大事务、配置不当；当排除已知原因带来的影响后，需要 OceanBase 技术支持人员支持时，请收集相关信息进行反馈。

常见原因

针对排查过程中遇到的不同情况，本文将根据问题解决的推荐度及收益从高到低的顺序依次进行介绍。

1. 大查询。由大查询或者烂 SQL 引起的租户内存超限问题，在定位到问题 SQL 后，可进行 SQL 优化达到减小查询内存消耗的目标，从而避免出现租户内存使用日志告警。

2. 大事务。由于大事务或者批量导数引起的租户报内存不足的情况，通过定位到具体事务内容后，进行事务处理优化最终达到大事务变为小事务的目标，避免发生内存使用超限。

3. 租户变量配置。当 SQL 调优到极限或事务大小已经到最小业务许可范围时，通过增大目标业务租户的 ob_sql_work_area_percentage 变量（默认值为 5，即租户单个资源单元内存规格的 5%）可增加 Session 使用内存量，此变量可配置为 Global 级别，推荐值域为 [5,80]。

   示例语句如下所示：

   • Global 级别

     obclient> SET GLOBAL ob_sql_work_area_percentage = xxx;
     

4. 租户内存扩容。当以上方法均尝试后仍有租户内存超限告警的，可考虑对租户进行扩容，操作的详细信息，请参见 租户管理概述章节。如果最终定位异常原因与转储、合并异常有关，详细操作信息请参见 合并问题排查。

收集相关信息

先定位内存不断增长的模块，然后针对该模块开启内存分配监控，进行问题重现后，定位内存增长（泄露）的原因。具体排查步骤如下：

1. 定位问题模块

   1. 查询 __all_virtual_memory_info 表。具体命令如下：

      SELECT * FROM __all_virtual_memory_info  ORDER BY used desc limit 10;
      

   2. 查询 observer.log 的日志。查看是哪个 mod 消耗的内存绝对占比比较大。下图中示例了从observer.log 中打印的内存信息可以查询到的 mod 内存消耗：

2. 开启 mod 模块的内存分配监控。

   ALTER system SET leak_mod_to_check='xxx';
   

   如果想要捕获 libeasy context 中 OB_TEST2_PCODE 模块的内存的代码路径，示例如下。

   ALTER system SET leak_mod_to_check='OB_TEST2_PCODE'
   

3. 问题重现

   监控以上模块的内存使用（参照第一步，通过 observer.log 或者 __all_virtual_memory_info)，观察到问题重现。

4. 执行以下命令，并将返回的内容保存为文本格式。

   SELECT * FROM __all_virtual_mem_leak_checker_info  ORDER BY alloc_count; 
   

5. 停止内存分配监控。

   通过步骤 4 可以看到该模块的内存分配代码路径（是地址 hex 值），这表示已经定位到内存增长（泄露）的原因，然后您可执行以下命令停止内存分配监控。

    ALTER system set leak_mod_to_check= '';
   

6. 将步骤 3 中的 back_trace 字段内容拷贝出来，尝试用 addr2line -pCfe $observer $back_trace 打印出来栈信息。示例如下：

    addr2line -pCfe /home/admin/oceanbase/bin/observer $back_trace
   

7. 将步骤 3、4、6 的内容发给 OceanBase 技术支持人员进行处理。