--- title: "负载均衡 | OceanBase 文档中心" description: "负载均衡 docslug#/oceanbase-database/oceanbase-database/V3.2.3/load-balancing 负载均衡是性能调优过程中经常关注的一个信息，包括集群内物理机负载均衡和业务流量负载均衡两个方面。较好的负载均衡状态能够充分利用软件、硬件环境，使得性能达到最优的状态。压测…" image: https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*OSPzQ6GUQF4AAAAAQHAAAAgAeiGDAQ/original --- 切换语言 - 中文站 - 简体中文 - International - English - 日本站 - 日本語 文档反馈![](https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*P8CuR4UJ_FkAAAAAAAAAAAAADiGDAQ/original) OceanBase 数据库分布式版 - V 4.0.0 社区版 # 负载均衡 更新时间：2026-03-27 14:15:30 [编辑](https://github.com/oceanbase/oceanbase-doc/edit/V4.0.0/zh-CN/500.administrator-guide/900.performance-tuning-guide/400.business-model-tuning/100.load-balancing.md) 负载均衡是性能调优过程中经常关注的一个信息，包括集群内物理机负载均衡和业务流量负载均衡两个方面。较好的负载均衡状态能够充分利用软件、硬件环境，使得性能达到最优的状态。压测过程中，我们需要关注集群内部各 OBServer 的资源使用率，包括：CPU、IO、Load 等参数。本文主要从集群部署、资源分布等方面简单阐述。 ## 集群部署 关于集群部署，需要搜集位置、延迟、带宽等信息。 ### 位置 位置信息至关重要，部分关键信息，如： IDC 、部署方式影响 SQL 路由转发、事务模型和性能。包括如下方面： - 部署方式：同城三机房？两地三中心？三地五中心？或其他部署方式。 - OBProxy 等中间件的位置：部署在客户端测还是跟 Observer 混布？不同的部署方式，对性能有一定的影响。 - 应用服务器及其他中间件位置。 查看集群各 Zone 分别在什么机房，机房所在城市，IDC 配置的相关 SQL 语句如下： ```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 如下： ```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 zone_list: z1;z2;z3 primary_zone: z1;z2,z3 locked: 0 collation_type: 0 info: system tenant locality: FULL{1}@z1, FULL{1}@z2, FULL{1}@z3 previous_locality: default_tablegroup_id: -1 compatibility_mode: 0 drop_tenant_time: -1 status: TENANT_STATUS_NORMAL in_recyclebin: 0 1 row in set ``` ### 资源分配信息 相关 SQL 如下： ```sql OceanBase(root@oceanbase)> select * from gv$ob_units limit 1\G; *************************** 1. row *************************** SVR_IP: xxx.xxx.xxx.xxx SVR_PORT: 59802 UNIT_ID: 1 TENANT_ID: 1 ZONE: zone1 MAX_CPU: 1 MIN_CPU: 1 MEMORY_SIZE: 17179869184 MAX_IOPS: 10000 MIN_IOPS: 10000 IOPS_WEIGHT: 1 LOG_DISK_SIZE: 17179869184 LOG_DISK_IN_USE: 81677640 DATA_DISK_IN_USE: 50331648 STATUS: NORMAL CREATE_TIME: 2022-10-24 16:37:01.245584 1 row in set ``` ### 单机用户分区总数量及 Leader 分布 ```sql MySQL [oceanbase]> select svr_ip,count(1) from __all_virtual_ls_meta_table where tenant_id=1002 group by svr_ip; +---------------+----------+ | svr_ip | count(1) | +---------------+----------+ | xxx.xxx.xxx.1 | 1 | | xxx.xxx.xxx.2 | 1 | | xxx.xxx.xxx.3 | 1 | +---------------+----------+ 3 rows in set MySQL [oceanbase]> select svr_ip,count(1) from __all_virtual_ls_meta_table where tenant_id=1001 and role=1 group by svr_ip; +---------------+----------+ | svr_ip | count(1) | +---------------+----------+ | xxx.xxx.xxx.1 | 5 | +---------------+----------+ 1 row in set ``` ## 其他 从应用服务器发出请求到 OBServer 应用服务器，中间经过的任何组件都是我们关注的重点，任何一处成为瓶颈，均能性能带来比较大的影响。需要关注： - 物理资源：中间链路各组件资源是否到瓶颈，比如：JVM 内存、应用服务器和 OBProxy CPU 使用率、软中断。 - 请求路由：OBProxy 是否能够正确路由 SQL 请求，是否存在乱转发的情况。 - 连接池：长和短连接数量，SocketTimeout 配置。 - 流量均衡：每个 OBServer上接收处理的 SQL 数量是否出现严重不均衡问题。 上一篇 下一篇 ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线