使用OBProxy时 所有的sql执行都会比直连OB多20ms左右

OceanBase 技术问题
#1

【 使用环境 】生产环境
【 使用版本 】
OceanBase 版本号 4.3.5.0
OBP版本号 4.3.2.0-42
OB集群是 3节点集群 (16C 128G) 部署在同一个机架 OB节点同时部署了OBP

【问题描述】使用OBProxy时 所有的sql执行都会比直连OB多20ms左右

请教下如何优化OBP响应时间

MYSQL8.0

image
image1287×377 9.31 KB

OB直连

image
image733×133 5.89 KB

OBP代理

image
image1179×163 10.8 KB 

我尝试去使用OCP的日志服务追踪 , 但是需要部署OpenSearch服务 , 如果有时间 请帮忙一起看下 OB官方提供的Docker镜像启动失败的问题
https://ask.oceanbase.com/t/topic/35623494
2 个赞
#3

毕竟多了一层的处理，20ms我是还算能接收

1 个赞
#4

是每条SQL都多20ms

我一个http请求会触发2-10条的sql 大约会造成延迟100ms+

1 个赞
#5

1、SET ob_enable_show_trace = 1;

2、执行SQL

3、show trace;
用上面这个方法能看到整个链路上的耗时，你可以看看多的耗时在什么地方，如果你的网络条件不好，每条SQL慢20ms也说的过去

OceanBase 社区dzs245_gaNjkwMjgyMTUuMTY2ODIzOTMxMA…_ga_T35KTM57DZ*czE3NDYzNDczNzEkbzEzNCRnMSR0MTc0NjM0OTA4NyRqMjkkbDAkaDA.

3 个赞
#6

所有的节点都在同一个机架上 是内网 万兆连接的
OB的节点是 Esxi的集群 网络ping都是 <1ms
这种场景下一般OBP耗时会增加多久呢?

1 个赞
#7

是用Navicat连接的是OBP的节点 执行了链路追踪 , 但是没有显示OBP这一层的数据

image
image1727×2095 250 KB

使用了 ODC的客户端去执行也是没有

image
image3875×1653 311 KB

image
image1579×889 83.6 KB

1 个赞
#8

看到官方文档上是有OBP这一层的数据

image
image1920×1463 194 KB

2 个赞
#9

ODP的版本是4.2以上吗，想起社区里面还有篇文档说要开几个参数，可以一起检查下

OceanBase 社区13vmi3q_gaNjkwMjgyMTUuMTY2ODIzOTMxMA…_ga_T35KTM57DZ*czE3NDYzNzQ0NTYkbzEzNSRnMSR0MTc0NjM3NTU1NiRqNjAkbDAkaDA.

2 个赞
#10

OBP参数是开着的 , 仍然没有返回 ＯＢＰ那一层 . 是必须使用OBClient来测试吗?

image
image2217×921 109 KB

1 个赞
#11

这种情况还需要优化啊

#12

@论坛小助手

#13

根据您的问题描述和提供的信息，以下是关于 OBProxy 响应时间优化以及链路追踪的详细分析和建议：

1. OBProxy 增加延迟的原因分析

您提到在生产环境中使用 OBProxy 时，所有 SQL 执行都会比直连 OB 多出约 20ms 的延迟。这种现象可能由以下原因导致：

(1) OBProxy 的额外开销

  • OBProxy 作为反向代理服务器，在转发请求时会引入一定的网络和计算开销。
  • 根据文档片段 8 的描述，OBProxy 在客户端与 OBServer 之间建立了逻辑连接，并管理多个物理连接。这种设计虽然提供了读写分离、分区表路由等功能，但也可能导致额外的延迟。

(2) 部署方式的影响

  • 您提到 OBProxy 和 OceanBase 数据库节点部署在同一台机器上。这种方式可能会导致资源竞争（如 CPU、内存等），从而增加 OBProxy 的响应时间。
  • 文档片段 10 中明确建议单独部署 OBProxy，以避免与 OceanBase 数据库的资源竞争。

(3) 网络环境的影响

  • 虽然您提到所有节点都在同一个机架内，且网络延迟小于 1ms，但 OBProxy 的性能也可能受到其他网络因素的影响，例如防火墙规则、带宽限制等。

2. 优化 OBProxy 响应时间的建议

(1) 调整 OBProxy 部署方式

  • 将 OBProxy 单独部署到一台专用机器上，避免与 OceanBase 数据库节点共享资源。
  • 确保 OBProxy 所在机器的硬件配置足够高（如更高的 CPU 和内存），以减少其自身的性能瓶颈。

(2) 优化 OBProxy 参数配置

  • 检查 OBProxy 的相关参数配置，确保启用了高性能模式。例如：
    • enable_ob_protocol_v2 和 enable_ob_protocol_v2_with_client 参数均已设置为 True（从您提供的图片中可以看到这些参数已开启）。
  • 如果需要进一步优化，可以参考官方文档中的 OBProxy 参数说明，调整以下关键参数：
    • obproxy_max_connections_per_server：控制每个 OBServer 的最大连接数。
    • obproxy_idle_timeout：设置空闲连接的超时时间，避免过多的空闲连接占用资源。

(3) 减少网络开销

  • 确保 OBProxy 和 OceanBase 数据库节点之间的网络连接稳定且低延迟。
  • 如果可能，使用本地负载均衡器（如 HAProxy 或 Nginx）来聚合多个 OBProxy 实例，提高整体性能。

(4) 监控和调优

  • 使用 OCP 或 obdiag 工具监控 OBProxy 的性能指标，包括连接数、QPS、延迟等。
  • 分析 OBProxy 的日志文件（如 obproxy_error.log 和 obproxy.log），定位潜在的性能瓶颈。

3. 链路追踪问题分析

(1) OBProxy 层数据未显示的原因

  • 您提到在使用链路追踪功能时，OBProxy 层的数据未显示。这可能是由于以下原因：
    • 使用的客户端工具（如 Navicat 或 ODC）不支持完整的链路追踪功能。
    • OBProxy 的版本（4.3.2.0-42）可能存在兼容性问题，导致无法正确记录链路信息。

(2) 解决方案

  • 使用 OBClient 测试：根据文档片段 9 的描述，OBClient 是支持 show trace 功能的推荐客户端工具。建议您使用 OBClient 进行测试，以确保能够完整记录 OBProxy 层的链路信息。
  • 检查协议兼容性：确保 OBProxy 和 OceanBase 数据库之间的协议版本一致，并启用了 OceanBase 2.0 协议。
  • 启用全链路诊断：按照以下步骤启用全链路诊断功能：
    -- 启用 session 级别的 show trace
SET ob_enable_show_trace = 'on';

-- 执行目标 SQL
SELECT ...;

-- 查看链路追踪信息
SHOW TRACE;

4. OBProxy 延迟的合理范围

根据文档片段 8 的描述，OBProxy 的设计目标是尽可能减少跨机数据访问，并提供高性能的路由转发服务。在理想情况下，OBProxy 的延迟应该在 几毫秒以内。如果您的环境中 OBProxy 的延迟达到 20ms，说明存在明显的性能瓶颈，需要重点排查。

5. 关于 OpenSearch 镜像启动失败的问题

您提到在尝试使用 OCP 的日志服务时，OpenSearch 镜像启动失败。这是一个独立的问题，建议您：

  • 检查 OpenSearch 镜像的依赖环境是否配置正确。
  • 查阅 OCP 的官方文档或联系技术支持团队，获取更详细的解决方案。

总结

  1. 优化 OBProxy 响应时间：单独部署 OBProxy，调整参数配置，减少网络开销，并使用高性能客户端工具（如 OBClient）进行测试。
  2. 解决链路追踪问题：确保协议兼容性，启用全链路诊断功能，并使用 OBClient 测试。
  3. 合理范围：在理想环境下，OBProxy 的延迟应在几毫秒以内。如果延迟过高，请重点排查部署方式、参数配置和网络环境。

如果您仍有疑问，建议联系 OceanBase 的人工答疑团队，获取更专业的技术支持。

检索到的文档如下:

  1. Show Trace
  2. 遇到问题如何向技术支持同学提问
  3. 产品 FAQ
  4. 进行 TPC-C 测试
  5. 进行 Sysbench 测试
  6. 数据库连接和路由概述
  7. OceanBase 数据库整体架构
4 个赞
#14

@淇铭 @辞霜 请帮忙看一下

#15

可以按照小助手的提示 链路诊断一下

image
image754×393 49.4 KB

#16

已经执行了 链路诊断了 , 返回结果里面没有 返回OBP这一层的统计数据

OBP已经设置了对应的参数

8e13a65b66a4e3516478f22ed562695d_3ee027c28905a698cbeb43f5671e93f966091b66_2_690x286
8e13a65b66a4e3516478f22ed562695d_3ee027c28905a698cbeb43f5671e93f966091b66_2_690x2861035×429 15.7 KB

使用ODC去查询也是没有返回OBP这一层的耗时

525bed7aa44d662ec31a88171b999292_c4c2e3b983da318fa0e810a5ea2eb36affd887a2_2_690x388
525bed7aa44d662ec31a88171b999292_c4c2e3b983da318fa0e810a5ea2eb36affd887a2_2_690x3881035×582 54.2 KB

#17

注意看小助手的解释 我楼上也给你发了 用obclient客户端

#18

你提到通过 OBProxy 访问 OceanBase 时，SQL 执行比直连 OB 慢 20ms 左右。这类问题通常可以从以下几个方向排查与优化：
一、OBProxy 延迟分析

  1. 网络延迟

    OBProxy 通常部署在客户端和 OBServer 之间，多出来的这 20ms 可能部分是网络传输带来的。

    优化建议：尽可能将 OBProxy 与业务应用部署在同一个机房或同一个网络环境，避免跨网络转发。

  2. OBProxy 参数优化

    检查 enable_compression_protocol 参数是否开启，可以减少网络传输大小。

    调整 client_max_connections 和 thread_num 等参数，确保 OBProxy 不因资源限制变慢。

    确保 OBProxy 启用了连接池功能，减少连接创建的开销。

  3. OBProxy 日志分析

    查看 OBProxy 的 obproxy.log 中是否有 slow query 或 wait queue too long 的情况。

二、OceanBase 配置与行为

  1. 连接初始化开销

    OBProxy 会进行路由缓存、连接初始化、认证等操作，首个请求尤其明显。

    优化建议：使用连接池复用连接，降低每次新建连接的成本。

  2. OBP 节点压力

    如果 OBP 节点资源本身偏紧（你提到和 OB 在同一节点），可能会导致资源竞争。

    优化建议：可以考虑将 OBP 和 OB 分离部署，或单独给 OBP 分配 CPU 资源（cgroups 限制）。

三、性能对比确认

为确认是 OBProxy 的问题，建议你：

使用 tcpdump 分析客户端到 OBProxy，再到 OBServer 的延迟时间。

在 OBProxy 和直连之间用同样的 SQL、多次测试，排除缓存、预热等因素干扰。

在 OBProxy 上开启性能统计参数，例如：

set global enable_perf_event=true;

四、使用系统提供工具分析

OceanBase 提供了 ob_admin、obproxy_perf_stat 等工具可以用来分析性能瓶颈。
建议总结

优先优化部署结构：将 OBProxy 与业务靠近，资源隔离。

调优参数：合理设置 OBProxy 的连接池和压缩参数。

使用连接池：避免每次新建连接造成额外延迟。

分析性能日志：定位具体耗时的操作。

如果你希望，我可以帮你制定一个具体的调优脚本或检查清单。是否需要？

1 个赞