OceanBase 数据更新性能

OceanBase 技术问题
#1

【 使用环境 】测试环境
【 OB or 其他组件 】OceanBase 压测疑惑
【 使用版本 】4.3.1 社区版
【问题描述】使用 sysbench 进行压测，发现相同资源和测试场景下，ob 读和插入性能比 tidb 有明显优势，单更新性能比 tidb 差，请问下具体原因是否跟 ob 默认数据压缩逻辑有关系呢，如果需要调优这部分逻辑应该如何进行，同时官方 sysbench 压测未见更新相关测试用例，是否也是因为更新性能不佳呢 https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001033263

【复现路径】sysbench --mysql-host=${host} --mysql-port=${port} --mysql-user=${user} --mysql-db=${db} --mysql-password=${pwd} --time=60 --threads=400 --report-interval=10 --db-driver=mysql --rand-type=uniform --tables=16 --table-size=5000000
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

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

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

#3

针对您在 OceanBase 4.3.1 社区版中使用 sysbench 进行压测时遇到的更新性能问题，我们可以使用 obdiag 工具来帮助诊断和收集相关信息。

首先，我们需要确认是否存在某些特定场景下的性能瓶颈。为此，可以先通过 obdiag 收集一些基础信息和性能指标。

日志采集场景:

集群基础信息
这可以帮助我们了解您的集群配置和当前状态。

日志采集命令:

obdiag gather scene run --scene=observer.base

解释:

上述命令会收集集群的基础信息，包括但不限于集群配置、版本信息、硬件信息等，这对于理解整体环境非常有帮助。

此外，由于您提到可能与数据压缩有关，我们还可以进一步收集与性能相关的日志，特别是与 SQL 性能相关的信息。

日志采集场景:

SQL性能问题
这可以帮助我们了解具体的 SQL 执行情况，包括执行计划、执行时间等。

日志采集命令:

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

解释:

请确保替换上述命令中的 -h (主机地址)、-P (端口)、-u (用户名)、-p (密码) 和 -D (数据库名) 为您实际使用的值。trace_id 可以根据实际情况填写或留空。

提供信息:

为了更准确地定位问题，请提供以下信息：

  1. 您在进行 sysbench 压测时的具体配置参数是什么？
  2. 是否已经尝试过调整 OceanBase 的相关参数，如 enable_compression 等？
  3. 您是否有观察到任何异常的日志信息或错误提示？

这些信息将有助于我们更深入地了解您的环境并提供针对性的建议。

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

#4

没有这个 --scene=observer.base参数呀

obd obdiag gather scene list
The tool oceanbase-diagnostic-tool is already installed the latest version 2.0.0
[Other Problem Gather Scenes]:

command info_en info_cn

obdiag gather scene run --scene=other.application_error [application error] [应用报错问题]

[Obproxy Problem Gather Scenes]:

command info_en info_cn

obdiag gather scene run --scene=obproxy.restart [obproxy restart] [obproxy无故重启]

[Observer Problem Gather Scenes]:

command info_en info_cn

obdiag gather scene run --scene=observer.backup [backup problem] [数 据备份问题]
obdiag gather scene run --scene=observer.backup_clean [backup clean] [备 份清理问题]
obdiag gather scene run --scene=observer.clog_disk_full [clog disk full] [clog盘满]
obdiag gather scene run --scene=observer.cluster_down [cluster down] [集 群无法连接]
obdiag gather scene run --scene=observer.compaction [compaction] [合 并问题]
obdiag gather scene run --scene=observer.cpu_high [High CPU] [CPU高]
obdiag gather scene run --scene=observer.delay_of_primary_and_backup [delay of primary and backup] [主 备库延迟]
obdiag gather scene run --scene=observer.io [io problem] [io 问题]
obdiag gather scene run --scene=observer.log_archive [log archive] [日 志归档问题]
obdiag gather scene run --scene=observer.long_transaction [long transaction] [长 事务]
obdiag gather scene run --scene=observer.memory [memory problem] [内 存问题]
obdiag gather scene run --scene=observer.perf_sql --env “{db_connect=’-h127.0.0.1 -P2881 -utest@test -p****** -Dtest’, trace_id=‘Yxx’}” [SQL performance problem] [SQL性能问题]
obdiag gather scene run --scene=observer.px_collect_log --env “{trace_id=‘Yxx’, estimated_time=‘2024-08-20 19:07:04’}” [Collect error source node logs for SQL PX] [SQL PX 收集报错源节点日志]
obdiag gather scene run --scene=observer.recovery [recovery] [数 据恢复问题]
obdiag gather scene run --scene=observer.restart [restart] [observer无故重启]
obdiag gather scene run --scene=observer.rootservice_switch [rootservice switch] [有 主改选或者无主选举的切主]
obdiag gather scene run --scene=observer.sql_err --env “{db_connect=’-h127.0.0.1 -P2881 -utest@test -p****** -Dtest’, trace_id=‘Yxx’}” [SQL execution error] [SQL 执行出错]
obdiag gather scene run --scene=observer.suspend_transaction [suspend transaction] [悬 挂事务]
obdiag gather scene run --scene=observer.unit_data_imbalance [unit data imbalance] [unit迁移/缩小 副本不均衡问题]
obdiag gather scene run --scene=observer.unknown [unknown problem] [未 能明确问题的场景]

#5

更新到obdiag 2.3.0