OB三机房遇到的问题咨询

OceanBase 技术问题
#1

【 测试环境 】
【 OB 】
【 4.2.1.8 】
【问题描述】
搭建了一个OB三机房集群(部署方式为1-1-1)，其中AB机房为同城，C为异地，延迟和AB大概有20ms。
现在发现对这个集群进行sysbench压测后，qps性能到6、7万左右就上不去了。

如果把机房C的服务停掉之后，再进行sysbench压测，QPS性能就正常了，能达到30W。
如何排查瓶颈在哪？是单纯的网络延迟造成的吗

1 个赞
#3

压测首先要保证observer节点cpu跑满：

  1. 先查看租户cpu和内存是否足够：
    select * from oceanbase.dba_ob_tenants;
  2. 通过top查看cpu使用率是否达到租户cpu和机器上限，如果没有，top -H看看子线程是否打满；
  3. 如果某些子线程占用100%，那么可能是该线程成为瓶颈；
  4. 如果没有线程是瓶颈，那很可能是发送到observer的请求压力不够，比如obproxy的瓶颈（可以尝试直连observer的leader测试）；
  5. 也可能是硬件瓶颈，比如网卡虽然带宽很高，但网卡队列数量过低，可以通过以下命令增加：sudo ethtool -L eth0 combined 4；或者磁盘性能不足，但一般高性能SSD就够了；
    observer的CPU跑满之后，再考虑sysbench的参数是否合理，observer集群的配置和租户的配置是否合适。
    https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000749129
2 个赞
#4

停掉 C 机房后性能反而能提升，推测你 SYS 租户以及业务租户的 primary_zone 都是随机的。
你可以在 SYS 租户里修改一下。

alter tenant sys primary_zone='zone1,zone2';
alter tenant 业务租户 primary_zone='zone1,zone2';

然后你停不停 C 服务都应该不影响性能。然后再针对问题优化。

1 个赞
#5

照着这样改了下，确实是停不停C都不影响影响。这个该如何排查呢

1 个赞
#6

资源和性能看了下应该都不是瓶颈

1 个赞
#7

接下来就是按上面社区支持的建议 逐个检查优化了。官网文档对 sysbench也有一些建议。

1 个赞
#8

建议直连leader测一下试试。同时检查一下sysbench客户端和observer所在机器的cpu核数：lscpu；网卡队列数量：ethtool -l eth0（改下网卡名字）
leader的IP地址可以通过日志流的位置判断：select * from __all_virtual_ls_info where tenant_id = 1002 and ls_state=‘leader’;

1 个赞
#9

直连leader发现qps都很低。

1 个赞
#10

cpu打满了么？网卡的流量看了么？A-A和C机房的qps是不是一样的，尽量按照我前面发的逐一排查。

1 个赞
#11

cpu没打满，网卡流量也不高。A-A机房能到6、7千，C只有三四千。但是都不高

#12

直连测试了么？直连的结果是什么样的

1 个赞
#13

直连A的是QPS6、7千
直接C的是QPS3、4千

我现在想要不要把C直接拿出来建一个单机版集群压测看看

#14

那有可能C有问题 性能上达不到 分区leader均衡么？
查一下 分区的leader
select svr_ip,svr_port,ls_id,count(*) from CDB_OB_TABLE_LOCATIONS where role=‘leader’ and table_type=‘USER TABLE’ and tenant_id=xxx group by svr_ip,svr_port,ls_id;
select a.svr_ip,a.svr_port,b.ls_id,sum(data_size)/1024/1024/1024 as total_data_size from CDB_OB_TABLET_REPLICAS a, CDB_OB_TABLE_LOCATIONS b where a.tenant_id=b.tenant_id and a.svr_ip=b.svr_ip and a.svr_port=b.svr_port and a.tablet_id=b.tablet_id and b.role=‘leader’ and b.table_type=‘USER TABLE’ and a.tenant_id=xxxx group by svr_ip,svr_port,ls_id;
也可以单机版测一下

#15

垮机房网络延迟是个避免不了大问题，我们MySQL异地跨机房都用的单独同步DRC工具来做的

#16

你好 这个后面又测试了么 找到问题了么