zone优先级设置

OceanBase 技术问题
#1

【 使用环境 】测试环境
【 OB or 其他组件 】OBServer 和OBProxy
【 使用版本 】4.2.x
【问题描述】
问题1：在真实使用的时候，如果我有3个zone，如果所有zone的优先级一样，是不是会产生较多的分布式事务？
问题2：是否推荐把每个zone的优先级不一样，这样就能保证所有数据的leader都在一个zone里，避免了分布式事务，这样性能是最优的吗？
问题3：对于sysbench 100个表的场景，我配置不同的zone不同的优先级的性能，要低于配置所有zone相同的优先级，这是为什么呢？所有机器的配置都是64C128g，且都在同一机房，租户是32c30g，我压测4、8并发都是如此

【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！

1 个赞
#3

根据您的描述，您在测试环境中配置了3个Zone，并且遇到了在不同优先级设置下性能反而不如相同优先级的情况。这可能涉及到分布式事务的产生、Leader选举机制以及系统资源的利用效率等问题。

日志采集场景: 集群基础信息

为了更好地理解集群的配置和运行状态，建议先收集集群的基础信息。

日志采集命令:

obdiag gather scene run --scene=observer.base

日志采集场景: 合并问题

考虑到合并操作可能会影响性能，建议同时收集合并相关的日志。

日志采集命令:

obdiag gather scene run --scene=observer.compaction

日志采集场景: SQL性能问题

为了分析具体SQL执行情况，特别是sysbench测试中的表现，建议收集SQL性能相关日志。

日志采集命令:

obdiag gather scene run --scene=observer.perf_sql --env "{db_connect='-h127.0.0.1 -P2881 -utest@test -p****** -Dtest', trace_id='Yxx'}"

请将上述命令采集到的日志提供给我们，以便我们进一步分析问题所在。

另外，为了确定具体的问题，在此需要您提供一些信息：

  1. 在不同优先级设置下，是否确实观察到了Leader集中在某个特定Zone？可以通过SHOW PARTITION LEADER BALANCE命令查看。
  2. 您是否有监控数据或日志显示在不同优先级设置下，分布式事务的数量或类型有何变化？
  3. 在进行sysbench测试时，是否有其他并发任务或后台作业影响了测试结果？
  4. 是否有启用任何特定的优化参数或配置项（如_ob_enable_partition_balance等），这些配置项可能会对性能产生影响？
  5. 在不同优先级设置下，各个Zone的负载情况如何？是否存在某些Zone负载过重的情况？

通过以上信息，我们可以更准确地定位问题并给出优化建议。

附上敏捷诊断工具 obdiag 使用帮助链接

#4

这里测试的场景是oltp write only

1 个赞
#5

根据您的描述，您在测试环境中配置了3个Zone，并且遇到了在不同优先级设置下性能反而不如相同优先级的情况，特别是在OLTP写入场景中。针对您的问题，我将逐一解答：

1. Zone优先级与分布式事务

问题1：如果所有Zone的优先级一样，是不是会产生较多的分布式事务？

  • 答案：当所有Zone的优先级相同时，Leader副本可能会分布在不同的Zone中。在这种情况下，跨Zone的读写操作会增加分布式事务的数量，因为每次写入都需要确保多个副本的一致性。这确实可能导致更多的分布式事务。

2. 推荐的Zone优先级设置

问题2：是否推荐把每个Zone的优先级不一样，这样就能保证所有数据的Leader都在一个Zone里，避免了分布式事务，这样性能是最优的吗？

  • 答案：理论上，通过设置不同的Zone优先级，可以将Leader副本集中在一个或少数几个Zone中，从而减少跨Zone的分布式事务，提高写入性能。然而，这种做法也存在潜在的风险：

    • 单点故障风险：如果Leader集中的Zone发生故障，可能会导致整个集群的服务中断。
    • 负载不均衡：Leader集中的Zone可能会承受过大的负载，影响整体性能。

    因此，虽然这种方式可以在某些情况下提升性能，但需要权衡可靠性和负载均衡。

3. 不同优先级设置下的性能差异

问题3：对于sysbench 100个表的场景，配置不同Zone不同优先级的性能要低于配置所有Zone相同优先级，这是为什么呢？

  • 答案：在OLTP写入场景中，配置不同Zone不同优先级可能会导致以下情况：
    • Leader迁移开销：当优先级较高的Zone成为Leader后，其他Zone的Follower副本需要频繁地从Leader同步数据，增加了网络和磁盘I/O开销。
    • 负载不均衡：如前所述，Leader集中的Zone可能会承受过大的负载，导致性能瓶颈。
    • 分布式事务延迟：尽管减少了跨Zone的分布式事务，但如果Leader所在的Zone负载过高，仍然会导致写入延迟增加。

建议的优化措施

为了更好地理解具体原因并进行优化，建议采取以下步骤：

  1. 监控Leader分布：使用SHOW PARTITION LEADER BALANCE命令查看Leader副本的分布情况，确认是否集中在某个Zone。

    SHOW PARTITION LEADER BALANCE;

  2. 分析分布式事务：检查是否有大量的分布式事务产生，可以通过查询系统表__all_virtual_transaction_info来获取相关信息。

  3. 评估负载均衡：使用OCP或其他监控工具，评估各个Zone的CPU、内存、磁盘I/O等资源使用情况，确保没有明显的负载不均衡现象。

  4. 调整参数配置：根据实际情况调整相关参数，例如_ob_enable_partition_balance，以优化Leader分布和负载均衡。

  5. 测试不同场景：尝试不同的Zone优先级配置，结合实际业务场景进行多轮测试，找到最优配置。

如果您能提供更详细的日志和监控数据，我们将能够更准确地分析问题并给出具体的优化建议。您可以使用obdiag工具收集诊断信息，并上传相关日志供进一步分析。

检索到的文档如下:

  1. CANCEL BALANCE JOB
  2. What’s New
  3. 快速入门系列教程
  4. PL 执行机制
  5. oceanbase.DBA_OB_KV_TTL_TASKS
  6. 4500 ~ 4999
  7. 进行 TPC-H 测试
  8. 进行 Sysbench 测试
  9. 通过 OCP 部署 OceanBase 集群

(小助手的答复已结束，如未能解决您的问题，请继续提问并等待其他同学的回复，谢谢！)

1 个赞
#6

上面小助手写的很清楚了，

  1. 当你的业务是OLTP对延迟要求高时，推荐zone优先级不一样，这样把leader集中到一个zone里，这样有点像mysql的1主2从了，分布式查询几乎没有了，缺点是：只有zone1真实服务用户，zone2/3在陪跑，如果业务接受，这时也可以做些设置，查询走follower，写入走leader，比较像mysql1主2从，读写分离了。
  2. 如果是OLAP业务(大数据分析)，是应该把数据打散到所有节点，充分发挥CPU做分布式运算，反而更快。
#7

感谢回答。那第三个问题，就不大好理解了。我这边相当于避免了分布式事务，但是tps却降低了。

#8

那问您，第三个压力测试，算OLAP, 还是OLTP呢？每个事务都是在1秒内完的吧？
感觉像OLTP压测，如果每个表数据量都很大，压测变成一条1000行的大SQL，应该结果不一样了。

#9

看起来您这边设置zone优先级相同的时候，100个表分布在三台机器上，写入性能应该要高些，但是如果是zone1>zone2>zone3,那么100个表的主副本分布在zone1，可能zone1就是相对的瓶颈，这边方便的话给下测试的数据，看下性能能差多少

#10

TP类的，一个事务一个update index；一个update non index；一个delete；一个insert。

#11

1、leader分布在不同的zone 跨机的分布式事务会增多
2、如果leader分布在一个zone里 会减少跨zone的分布式事务，可以提高写入性能，但是会有性能上的压力，会有性能瓶颈，数据保护来说也有风险
3、如果集中在一个zone里 性能应该有瓶颈 如果分布在不同的zone里 压力会分散 性能上会优点

#12

好的！

#13

如果每个表数据量都很大，压测变成一条1000行的大SQL，应该结果不一样了。