租户规格太小导致连接数超限问题

问题现象

客户在云上集群（云厂商 AWS）部署 OceanBase，应用报错 Too many connections。客户希望了解当前的连接数以及连接数上限。

问题原因

租户内存规格过小，导致实际支持的并发连接数超过了由隐藏参数 _resource_limit_max_session_num 决定的限制。

Too many connections 错误表明存在连接数超限的情况。由于监控数据通常是分钟级采集，而连接数打满可能发生在秒级，因此监控图表可能无法准确反映瞬间的超限现象。当怀疑连接数打满时，建议直接通过命令行执行 SHOW PROCESSLIST 来查看实时的连接情况。

关键信息

问题分析

1. 确定问题发生时间与连接数 根据客户提供的应用日志，报错时间为 14:16:12。需要查询该时刻租户的客户端连接数。

   查询结果显示，当时的连接数约为 1700。

2. 排查连接数限制来源 连接数超限通常由多个层面的限制共同决定，最终生效的是其中最小的限制值。需要依次排查以下常见限制：

   • OBProxy 层限制

     • 租户代理最大连接数：此参数一般默认为 5000。当前连接数 1700 未达到此限制。
     • OBProxy 客户端最大连接参数 (client_max_connections)：此参数值取决于 OBProxy 的规格。通常，1 GB 内存可支持 4096 个连接。 计算示例：当前 OBProxy 规格为 2C4G，因此 client_max_connections = 4 * 4096 = 16384。当前连接数 1700 未达到此限制。

   • 租户变量限制

     • max_user_connections：此变量一般默认为 0（表示不限制）。
     • max_connections：此变量一般默认为 2147483647。 通常业务连接数不会达到这两个变量的限制。

   • OBServer 租户内存限制

     • 隐藏参数 _resource_limit_max_session_num：此参数受租户内存规格影响。
       • 当该参数值为 0 时，系统根据内存自动计算（公式：memory_size * 0.05 / 100K，计算结果最小为 100）。
       • 若手动设置了该参数，则连接数受限于该设定值。 根据查询，该隐藏参数的值为 0，因此需根据租户内存计算。 租户规格为 2C4G，需注意内存中有一部分会分配给 meta 租户。扣除 1 GB 后，用于计算的内存为 3 GB。 计算过程：3 * 1024 * 1024 * 0.05 / 100 ≈ 1573。系统取 max(100, 1573) = 1573。 第一步查得的连接数峰值约为 1700，超过了内存计算出的上限 1573，因此触发了连接数超限。

3. 查看 ODP 及 OBServer 日志

   • 根据租户 ID 在 ODP 管控台确认 ODP 集群为 K8s 共享模式，规格为 2C4G，且有两个主节点。
   • 登录 ODP 节点，在 obproxy.log 中过滤关键字 'Too many connections'，发现在 14:47:56 到 14:48:05 期间（约 8 秒）存在相关报错，但日志中未记录具体的超限连接数值。
   • 查看 obproxy_error.log，发现历史日期（如 4 月 22 日）也存在相同报错，但同样未提供更多有效信息。

问题的风险及影响

当前连接数已达到系统或租户设定的上限，无法建立新的数据库连接，会导致：

• 大量业务请求超时或报错。
• 服务不可用或功能降级。

适用版本

所有 OBServer 版本。

解决方法

调大租户的内存规格。

规避方式

调大租户的内存规格。