OcenBase社区版和自建Mysql性能对比

AntTech_EYIPUQ · 2025 年4 月 27 日 14:50

【使用环境】
测试环境

CentOS Linux release 7.4.1708 (Core)
3.10.0-693.el7.x86_64
cpu:Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz
配置:8核32G

【 OB or 其他组件】
使用obd demo --oceanbase-ce.version=4.3.3.0 快速部署(仅部署的OB数据库未部署其他任何组件)
（sysbench 1.0.20）
Mysql8.0.42
【使用版本】
【问题描述】
最近我司产品在做信创适配相关产品计划适配Oceanbase。出于好奇和学习在同一台服务器上同时部署了社区最新版本5.7.25-OceanBase_CE-v4.3.5.1和Mysql8.0.42。测试下来发现和预期结果不一样在oltp_write_only和oltp_insert 负载场景下性能(QPS)均低于自建Mysql.

理论上 OceanBase 使用LSM tree在write_only和insert场景应该更具优势不应该低于Mysql B+ tree，希望帮忙看看是否社区需要对参数要进行调整才能发挥性能？官方是否有进行过类似的测试可以提供相关文档进行参考。另外测试中遇到的以下问题也希望帮忙解答下，多谢！
1.测试数据量很小(4张表每张100w 理论上应该都能命中缓存) 但oltp_write_only 和oltp_insert负载都会在主机磁盘上产生大量的read IO, 相同测试Mysql基本上没有read IO 。

2.停止测试数据库没有任何压力的情况下为什么observer进程依旧会占用25%+的cpu？perf诊断了observer进程发现没有压力情况下存在调用oceanbase::omt::ObThWorker::worker去destory_context 并且在没有压力时oceanbase::omt::ObThWorker::worker 还会生成执行计划去执行计划这是为什么？

【复现路径】

yum install sysbench 
sysbench --test=/usr/share/sysbench/oltp_insert.lua --mysql-host=xxxx--mysql-port=xxx--mysql-user=xxx --mysql-password=xxx --mysql-db=testdb --db-driver=mysql --tables=4 --table-size=1000000 --report-interval=10 --threads=128 prepare

sysbench --db-driver=mysql --time=300 --threads=128 --report-interval=2 --mysql-host=192.168.148.163 --mysql-port=2881 --mysql-user=root --mysql-password=xxx--mysql-db=demo --tables=4 --table_size=1000000 oltp_insert --db-ps-mode=disable run

oceanbase 内存相关配置如下(默认配置)

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

论坛小助手 · 2025 年4 月 27 日 14:51

根据您的描述，OceanBase 在 OLTP_write_only 和 OLTP_insert 场景下的性能表现不如预期，并且存在磁盘读 IO 高、无负载时 observer 进程 CPU 占用高以及频繁调用 destory_context 和生成执行计划的问题。以下是针对您问题的分析和建议。

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

为了进一步诊断问题，推荐使用 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 性能相关的日志信息，帮助分析是否存在查询优化空间。

CPU 高问题：
```
obdiag gather scene run --scene=observer.cpu_high
```
该命令用于收集 observer 进程在高 CPU 情况下的相关日志和堆栈信息，帮助定位 CPU 使用率高的原因。

需要进一步确认的信息：

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

当前 OceanBase 的版本号是多少？（例如：4.2.1）
是否已经对 OceanBase 的参数进行了自定义调整？如果有，请列出具体的参数及其值。
测试环境的硬件配置如何？（包括 CPU 核心数、内存大小、磁盘类型等）
在小数据量测试时，磁盘读 IO 的具体数值是多少？是否有对应的 iostat 或 dstat 数据？
observer 进程的 CPU 占用率是否持续保持在 25% 以上？是否有通过 top 或 pidstat 获取的详细进程信息？
是否可以提供一个简单的测试脚本或 SQL 示例，以便我们复现问题？

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

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

淇铭 · 2025 年4 月 27 日 15:07

压测首先要保证observer节点cpu跑满：

先查看租户cpu和内存是否足够：
select * from oceanbase.dba_ob_tenants;
通过top查看cpu使用率是否达到租户cpu和机器上限，如果没有，top -H看看子线程是否打满；
如果某些子线程占用100%，那么可能是该线程成为瓶颈；
如果没有线程是瓶颈，那很可能是发送到observer的请求压力不够，比如obproxy的瓶颈（可以尝试直连observer的leader测试）；
也可能是硬件瓶颈，比如网卡虽然带宽很高，但网卡队列数量过低，可以通过以下命令增加：sudo ethtool -L eth0 combined 4；或者磁盘性能不足，但一般高性能SSD就够了；
observer的CPU跑满之后，再考虑sysbench的参数是否合理，observer集群的配置和租户的配置是否合适。
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000749129

AntTech_EYIPUQ · 2025 年4 月 27 日 16:05

感谢回复:
1/2/3: select * from oceanbase.dba_ob_tenants;这个SQL哪个结果可以表示内存是否足够？查询了dba_ob_units 压测数据量小内存足够，压测过程中cpu是打满已经超过了租户的上限(3 core）top-H检查不存在100%的子线程
4.部署的单机版本应该不存proxy瓶颈？
5.同一太机器部署的mysql和Oceanbase 相同网络&磁盘带宽下进行的对比测试不需要考虑网络和磁盘问题，尝试使用sudo ethtool -L eth0 combined 4 测试结果相同。
另外 sysbench 使用的参数和官网测试文档中的参数一致除了没指定–rand-type=uniform

最后咨询下，你们有和自建Mysql性能对比(相同配置下)的相关数据吗？

淇铭 · 2025 年4 月 27 日 16:16

看你设置的 memory_limit 按照最小的配置设置的你创建业务租户了么？不建议使用sys租户压测
select * from oceanbase.dba_ob_tenants; 使用哪个业务租户压测，查询哪个业务租户

不建议使用这个版本如果使用oltp建议使用ob425这个版本 olap建议使用ob435版本

OceanBase Sysbench 高性能参数配置

https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000002508010

论坛小助手 · 2025 年4 月 27 日 16:16

根据您的补充信息，以下是针对您问题的进一步分析和解答：

1. 如何判断 OceanBase 的内存是否足够？

在 dba_ob_tenants 和 dba_ob_units 中，可以通过以下字段来判断租户的内存配置是否合理：

memory_limit：表示租户的最大内存限制。
used_memory：表示当前租户已使用的内存。
max_cpu：表示租户的最大 CPU 配额。

判断依据：

如果 used_memory 接近或超过 memory_limit，说明租户内存不足，可能需要调整 memory_limit 参数。
如果 CPU 使用率（通过 top 或 pidstat 检查）持续打满，并且超过了租户的 max_cpu 配额，则需要增加租户的 CPU 配额。

参考文档：

数据库内存上限

2. 关于 CPU 超过租户上限的问题

即使 CPU 打满，但如果子线程没有达到 100%，可能是由于以下原因：

多线程调度不均：OceanBase 的多线程模型可能导致某些线程负载较高，而其他线程负载较低。
SQL 执行计划问题：某些 SQL 的执行计划可能不够优化，导致资源消耗过高。

建议：

使用 EXPLAIN 查看 SQL 的执行计划，确认是否存在性能瓶颈。
调整租户的 max_cpu 参数，确保其能够满足测试需求。

3. OBProxy 是否会成为瓶颈？

在单机部署的情况下，如果 OBProxy 和 OceanBase 数据库部署在同一台机器上，可能会存在资源竞争。但根据您的描述，测试中并未指定 OBProxy，因此可以排除 OBProxy 的瓶颈问题。

注意事项：

如果后续测试中使用了 OBProxy，建议将其部署在独立的机器上，以避免资源竞争。

4. 网络和磁盘带宽的影响

既然测试是在同一台机器上进行的，并且网络和磁盘带宽相同，可以排除网络和磁盘带宽对性能的影响。

5. Sysbench 测试参数

您提到未指定 --rand-type=uniform，这可能导致测试数据的随机性与官方文档中的测试条件不一致。建议按照官方文档中的参数进行测试，以确保结果的可比性。

官方文档参考：

OceanBase Sysbench 高性能部署和问题分析

6. OceanBase 与自建 MySQL 的性能对比数据

目前，官方并未公开具体的性能对比数据，但可以根据以下几点进行分析：

OceanBase 的优势场景：

写入性能：OceanBase 使用 LSM Tree 存储引擎，在写入密集型场景下通常优于 MySQL 的 B+ 树存储引擎。
分布式架构：OceanBase 支持水平扩展，适合大规模数据处理场景。
高可用性：OceanBase 默认三副本架构，支持跨机房、跨城市部署，具备更高的可用性和容灾能力。

MySQL 的优势场景：

单机性能：在小规模数据量和简单查询场景下，MySQL 的性能可能更优。
生态成熟度：MySQL 的生态系统更为成熟，插件和工具支持丰富。

性能对比建议：

在相同的硬件配置下，OceanBase 的写入性能通常优于 MySQL，但在读取性能上可能略逊一筹。
如果您的业务场景以写入为主，建议优先考虑 OceanBase；如果以读取为主，可以结合缓存等技术优化 MySQL 的性能。

7. 下一步建议

调整租户配置：
- 增加租户的 memory_limit 和 max_cpu 参数，确保其能够满足测试需求。
- 示例命令：
```
ALTER TENANT your_tenant_name SET RESOURCE UNIT = (MAX_CPU = 8, MEMORY_SIZE = '16G');
```
优化 SQL 执行计划：
- 使用 EXPLAIN 分析 SQL 的执行计划，确保其高效运行。
- 如果发现性能瓶颈，可以通过添加索引或调整查询语句来优化。
复现官方测试条件：
- 按照官方文档中的参数重新进行测试，确保结果的可比性。
联系技术支持：
- 如果问题仍未解决，建议联系 OceanBase 的技术支持团队，提供详细的日志和测试数据，以便进一步分析。

希望以上信息对您有所帮助！如果有其他问题，请随时提问。

检索到的文档如下:

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

AntTech_EYIPUQ · 2025 年4 月 27 日 16:17

这里还有个疑问我看util 租户配置中最大/最小cpu都是3 ，但实际压测observer observer 的cpu使用率能超过300% （当前数据库只有一个租户）配置里的3表示的是什么意思？

淇铭 · 2025 年4 月 27 日 16:18

淇铭 · 2025 年4 月 27 日 16:20

建议先看看官方文档了解一些ob的原理配置信息再去用sysbench做压测

AntTech_EYIPUQ · 2025 年4 月 27 日 16:39

感谢指导，按照建议我去了解下下ob的配置再去创建业务租户试试。