问个问题，我用sysbench分别直连3个OBServer去压测，为什么连OBServer1的速度要明显比连其他两个的速度要快很多

OceanBase 技术问题
#1

【 使用环境 】测试环境
【 OB or 其他组件 】OBSERVER
【 使用版本 】
【问题描述】问个问题，我用sysbench分别直连3个OBServer去压测，为什么连OBServer1的速度要明显比连其他两个的速度要快很多；我的sysbench和几个OBServer都在同一个机房里；优先级为zone1,zone2,zone3
【复现路径】在一个机房的5个物理机上，部署3个OBServer，一个OBProxy，一个sysbench。分别连接进行压测，为什么性能差距明显？
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

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

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

1 个赞
#3

日志采集场景: SQL性能问题
日志采集命令: obdiag gather scene run --scene=observer.perf_sql --env “{db_connect=’-h127.0.0.1 -P2881 -utest@test -p****** -Dtest’, trace_id=‘Yxx’}”

为了更好地了解和解决您遇到的性能差距问题，建议您使用上述obdiag命令进行日志采集。该命令可以帮助我们收集与SQL性能相关的诊断信息，从而分析为什么OBServer1的连接速度明显快于其他两个OBServer。

请您提供一些额外的信息以便我们更好地帮助您：

  1. 您能否提供具体的sysbench测试配置参数？例如线程数、表大小等。
  2. 三个OBServer的硬件配置是否一致？包括CPU、内存、磁盘I/O等方面。
  3. OBServer1与其他两个OBServer在软件版本或配置上是否存在差异？
  4. 在压测过程中，是否有监控到各OBServer的资源使用情况（如CPU、内存、磁盘I/O）？
  5. 是否有查看过各个OBServer的日志中是否存在异常或者错误信息？

请根据以上要求执行日志采集，并将结果提供给我们，以便进一步分析问题所在。

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

#4

还有一个现象就是，经过obproxy和直接压测OBServer1的速度几乎一样，但是直接压测OBServer2和OBServer3就差距较大，有50%以上的性能差距

#5

根据您提供的信息，结合文档中的内容，以下是可能的原因分析和建议：

可能原因

  1. OBProxy 路由优化

    • 根据文档片段6（标题: 进行 Sysbench 测试 → Sysbench 高性能部署和问题分析），OBProxy 的一个主要功能是将 SQL 查询路由到恰当的服务器节点。如果用户查询没有指定使用弱一致性读属性，Proxy 需要将其路由到所涉及的表（或具体分区）的主节点上，以避免服务器节点之前的二次转发；否则，Proxy 会根据预先设置好的规则将其转发到恰当的节点。
    • 如果 OBServer1 是某些表或分区的主节点，那么通过 OBProxy 访问时，请求会被直接路由到 OBServer1，从而减少了额外的网络延迟和处理时间。

  2. 资源分配与负载均衡

    • 文档片段2（标题: 负载均衡）提到，较好的负载均衡状态能够充分利用软件、硬件环境，使得性能达到最优的状态。压测过程中，我们需要关注集群内部各 OBServer 的资源使用率，包括：CPU、IO、Load 等参数。
    • 如果 OBServer2 和 OBServer3 在资源使用率上有显著差异，或者存在负载不均衡的情况，这可能导致它们在处理相同类型的请求时表现出不同的性能。

  3. 物理资源瓶颈

    • 文档片段1（标题: 从应用服务器发出请求到 OBServer 应用服务器）指出，需要关注物理资源是否到达瓶颈，比如 JVM 内存、应用服务器和 OBProxy CPU 使用率、软中断等。
    • 如果 OBServer2 和 OBServer3 在这些方面存在瓶颈，可能会导致性能下降。

  4. 网络延迟

    • 尽管所有机器在同一机房内，但不同 OBServer 之间的网络延迟可能存在细微差异。特别是当通过 OBProxy 访问时，OBProxy 到 OBServer 的网络路径也可能影响性能。

建议措施

  1. 检查 OBProxy 路由配置

    • 确认 OBProxy 是否正确配置了路由规则，确保查询被合理地分发到各个 OBServer 上。
    • 检查是否有特定的表或分区总是被路由到 OBServer1，如果是这样，可以考虑调整数据分布策略以实现更好的负载均衡。

  2. 监控资源使用情况

    • 使用工具如 obdiag 收集并分析 OBServer2 和 OBServer3 的资源使用情况，找出是否存在资源瓶颈。
    • 对比 OBServer1 的资源使用情况，看是否存在明显的差异。

  3. 优化负载均衡

    • 确保集群内的负载均衡机制正常工作，避免某个 OBServer 承担过多的工作量。
    • 如果发现负载不均衡，可以通过调整租户配置或重新分配数据来改善。

  4. 排查网络问题

    • 检查 OBProxy 到各个 OBServer 的网络连接质量，确保网络延迟最小化。
    • 如果有必要，可以尝试更换网络设备或优化网络拓扑结构。

  5. 查看日志

    • 查看 OBServer2 和 OBServer3 的日志文件，寻找任何异常或错误信息，这些信息可能有助于定位问题的根本原因。

总结

为了进一步缩小问题范围，请按照上述建议逐步排查，并提供更多的诊断信息。如果您有具体的日志或监控数据，欢迎分享，我们将继续协助您解决问题。

具体信息可参考以下文档:

  1. 负载均衡
  2. 进行 Sysbench 测试
  3. ODP 端故障
  4. 进行 TPC-H 测试
  5. SQL 调优常见问题
  6. SQL 性能问题的典型场景和排查思路
  7. 检查 OBServer 状态
  8. 性能分析
  9. OBProxy 性能监控

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

#6

符合预期。
推测租户的primary_zone 是在 zone1， 或者大部分表分区 的主副本在 zone1 。

observer 也有路由功能，但是相比obproxy 的路由功能 observer会比较重。直连 observer2 和observer3 的时候 sql 可能要远程发到 observer1 执行，网络上多了一个来回，性能自然就下降了。

任何时候读写 ob 都建议走 obproxy 。生产就是这样。有多个 obproxy 的时候 obproxy 前面还要加一个负载均衡设计。f5 或者 nginx、haproxy 等负载提供一个 vip 用于obproxy 的连接。

1 个赞
#7

还有一个现象就是，经过obproxy和直接压测OBServer1的速度几乎一样，但是直接压测OBServer2和OBServer3就差距较大，有50%以上的性能差距