sysbench点查测试结果较多

OceanBase 技术问题
,
#1

【 使用环境 】生产环境 or 测试环境
测试环境
【 OB or 其他组件 】
OB
【 使用版本 】
OceanBase All in One 4.3.5_BP1,
sysbench 1.0.20
【问题描述】清晰明确描述问题
使用OceanBase All in One部署3个obs的实例在3台物理机上，把sysbench和obd部署在同一台额外的物理机上。
sysbench的sbtest%u表为partition by hash, partition_count=3，对每个sbtest%u表的k列上创建索引；
把原来的点查select * from sbtest%u where id = ?的语句改为测试select k from sbtest%u where k = ?，然后跑sysbench的点查测试。
结果sysbench的结果很差，才跑到45719qps。
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

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

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

#3

用户问题总结：在测试环境中使用 OceanBase All in One 部署了 3 个 observer 实例，通过 sysbench 测试发现点查性能较差（45719 QPS），希望了解如何优化。

推荐使用 obdiag 工具进行日志采集，以便进一步分析性能瓶颈。

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

解释：上述命令将收集与 SQL 性能相关的诊断信息，包括执行计划、系统资源使用情况等，有助于定位点查性能较低的原因。请将采集到的日志压缩包提供给我们以进一步分析。

为了更好地帮助您，请您提供以下信息：

  1. 当前测试环境的硬件配置（CPU 核数、内存大小、磁盘类型等）是什么？
  2. OceanBase 数据库的具体版本号是多少？
  3. sysbench 测试时使用的表结构和数据量是多少？是否已经创建了合适的索引？
  4. 是否观察到高 CPU 使用率或 IO 瓶颈？可以通过 top 或 iostat 命令查看系统资源使用情况。
  5. 是否对 OceanBase 的系统参数进行了调整？如果有，请列出主要修改的参数及其值。
  6. 是否有其他负载同时运行在该测试环境中，可能影响性能测试结果？

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

#4

租户建议手动创建个新的，sys租户不适合进行压测和业务使用。
有部署obproxy么