OceanBase负载均衡

负载均衡是性能调优过程中经常关注的一个信息，包括集群内物理机负载均衡和业务流量负载均衡两个方面。较好的负载均衡状态能够充分利用软件、硬件环境，使得性能达到最优的状态。压测过程中，我们需要关注集群内部各 OBServer 的资源使用率，包括：CPU、IO、Load 等参数。本文主要从集群部署、资源分布等方面简单阐述。

集群部署

关于集群部署，需要搜集位置、延迟、带宽等信息。

位置

位置信息至关重要，部分关键信息，如： IDC 、部署方式影响 SQL 路由转发、事务模型和性能。包括如下方面：

• 部署方式：同城三机房？两地三中心？三地五中心？或其他部署方式。
• OBProxy 等中间件的位置：部署在客户端测还是跟 Observer 混布？不同的部署方式，对性能有一定的影响。
• 应用服务器及其他中间件位置。

查看集群各 Zone 分别在什么机房，机房所在城市，IDC 配置的相关 SQL 语句如下：

MySQL [oceanbase]> select zone, name, info from __all_zone where name in ('region', 'idc') ;
+------+--------+------+
| zone | name   | info |
+------+--------+------+
| z1   | idc    |      |
| z1   | region | SZ   |
| z2   | idc    |      |
| z2   | region | SZ   |
| z3   | idc    |      |
| z3   | region | SZ   |
+------+--------+------+
6 rows in set (0.00 sec)

延迟

可通过延迟信息评估单条 SQL 的 rt 是否符合预期。整个集群具体的延迟信息如下：

• 机房间延迟；
• Zone 间延迟；
• OBProxy 到 OBServer 端延迟；
• 客户端到 OBProxy 端延迟。

带宽

需要确认如下组件的带宽：

• OBProxy 所在机器网卡带宽。
• 应用服务器网卡带宽。
• OBServer 网卡、磁盘 IO 带宽。

这些信息的获取可以通过注入 ping 、tsar 、ethtool xxx 、ifconfig 等命令获取。接下来的描述，我们以同城三机房、三副本 FFF 部署为例。

资源分布

了解租户资源分布，为接下来的性能诊断做准备。

租户的基本信息

包括 primary , locality 等，相关 SQL 如下：

MySQL [oceanbase]> select * from __all_tenant limit 1\G;
*************************** 1. row ***************************
                 gmt_create: 2021-08-25 20:38:18.699528
               gmt_modified: 2021-08-25 20:38:18.699528
                  tenant_id: 1
                tenant_name: sys
                replica_num: -1
                  zone_list: z1;z2;z3
               primary_zone: z1;z2,z3
                     locked: 0
             collation_type: 0
                       info: system tenant
                  read_only: 0
      rewrite_merge_version: 0
                   locality: FULL{1}@z1, FULL{1}@z2, FULL{1}@z3
        logonly_replica_num: 0
          previous_locality:
     storage_format_version: 0
storage_format_work_version: 0
      default_tablegroup_id: -1
         compatibility_mode: 0
           drop_tenant_time: -1
                     status: TENANT_STATUS_NORMAL
              in_recyclebin: 0
1 row in set (0.01 sec)

资源分配信息

相关 SQL 如下：

MySQL [oceanbase]> select * from gv$unit where tenant_id=1002 limit 1 \G;
*************************** 1. row ***************************
              unit_id: 1004
       unit_config_id: 1002
     unit_config_name: box1
     resource_pool_id: 1002
   resource_pool_name: fpool
                 zone: z1
            tenant_id: 1002
          tenant_name: tt1
               svr_ip: 192.168.30.65
             svr_port: 40000
  migrate_from_svr_ip:
migrate_from_svr_port: 0
              max_cpu: 4
              min_cpu: 4
           max_memory: 24604378624
           min_memory: 24604378624
             max_iops: 128
             min_iops: 128
        max_disk_size: 536870912
      max_session_num: 64
1 row in set (0.01 sec)

单机用户分区总数量及 Leader 分布

MySQL [oceanbase]> select svr_ip,count(1) from __all_virtual_meta_table where tenant_id=1002 group by svr_ip;
+---------------+----------+
| svr_ip        | count(1) |
+---------------+----------+
| 192.168.30.65 |        1 |
| 192.168.30.66 |        1 |
| 192.168.30.67 |        1 |
+---------------+----------+
3 rows in set (0.01 sec)

MySQL [oceanbase]> select svr_ip,count(1) from __all_virtual_meta_table where tenant_id=1001 and role=1 group by svr_ip;
+---------------+----------+
| svr_ip        | count(1) |
+---------------+----------+
| 192.168.30.65 |        5 |
+---------------+----------+
1 row in set (0.00 sec)

其他

从应用服务器发出请求到 OBServer 应用服务器，中间经过的任何组件都是我们关注的重点，任何一处成为瓶颈，均能性能带来比较大的影响。需要关注：

• 物理资源：中间链路各组件资源是否到瓶颈，比如：JVM 内存、应用服务器和 OBProxy CPU 使用率、软中断。
• 请求路由：OBProxy 是否能够正确路由 SQL 请求，是否存在乱转发的情况。
• 连接池：长和短连接数量，SocketTimeout 配置。
• 流量均衡：每个 OBServer上接收处理的 SQL 数量是否出现严重不均衡问题。