---
title: 一次OceanBase集群压测性能较差的定位过程-官方技术文章-鲲鹏社区
description: 一次OceanBase集群压测性能较差的定位过程
keywords: OceanBase,一次,集群压测性能,较差的定位过,官方技术文章,鲲鹏社区,问题现象,应用信息
url: https://www.hikunpeng.com/developer/techArticles/20250429-3?envFlag=1
section: (其他)
---

# 一次OceanBase集群压测性能较差的定位过程-官方技术文章-鲲鹏社区

URL: https://www.hikunpeng.com/developer/techArticles/20250429-3?envFlag=1
描述: 一次OceanBase集群压测性能较差的定位过程
关键词: OceanBase,一次,集群压测性能,较差的定位过,官方技术文章,鲲鹏社区,问题现象,应用信息

官方技术文章 [了解详情](https://www.hikunpeng.com/zh/developer/techArticles)

一次OceanBase集群压测性能较差的定位过程

一次OceanBase集群压测性能较差的定位过程

oceanbase

发表于 2025/04/29

0

作者|郭智聪

### 问题现象

某次sysbench压测中，发现oceanbase集群的性能较差，sql执行速度较慢，sysbench指标较低

# 应用信息

| 软件名称 | 版本 |
| --- | ---|
| sysbench | 1.0.17 |
| OceanBase Database | 4.3.5.1 |
| OBProxy | 4.3.3.0 |
| OCP Express | 4.2.2 |
| OBAgent | 4.2.2 |

# 测试用例

cleanup 清除数据库测试数据

`sysbench oltp_point_select.lua --mysql-host=xxx --mysql-port=2881 --mysqldb=sysbench --mysql-user=root@sysbench --mysql-password='xxxxxx' --
table_size=2000000 --tables=100 --threads=50 --report-interval=10 --time=60 cleanup`

prepare 测试数据

`ysbench oltp_point_select.lua --mysql-host=xxx --mysql-port=2881 --mysqldb=sysbench --mysql-user=root@sysbench --mysql-password='xxxxxx' --
table_size=2000000 --tables=100 --threads=5 --report-interval=10 --time=60 prepare`

test 启动测试

`sysbench oltp_point_select.lua --mysql-host=xxx --mysql-port=2881 --mysqldb=sysbench --mysql-user=root@sysbench --mysql-password='xxxxxx' --
table_size=2000000 --tables=100 --threads=500 --report-interval=10 --time=60 --db-psmode=disable run`

# 问题定位

1. 网络带来的性能瓶颈

1) 数据库层⾯⽆配置问题，转⽽排查硬件层⾯是否存在瓶颈点。分别排查CPU、磁盘IO、⽹络IO问题（参考下
⾯列出的命令），发现CPU整机负载较低，未到70%的使⽤率；磁盘IO基本没有；主要是⽹络IO达到
117257.40KB/s，接近⽹络带宽（GE⽹⼝）。此处基本能确认性能问题主要是因为⽹络瓶颈导致的。

查看网络IO: sar -n DEV 1 10

2) 发现业务配置使用的网口是电口。电口与光口相比传输速率和传输带宽存在明显差异，且⼀般业务⼝需要配置在光⼝上，因此重新修改数据库业务⼝配置，使其放在光⼝上，重新测试后性能正常。

参考测试数据
以下为Sysbench的在不同并发下的性能测试结果： sar -n DEV 1 10

1. 使⽤电⼝作为业务⼝的数据库集群在并发线程达到100时，⽹⼝达到瓶颈，此后增加并发数也不会带来TPS的
提升；

2. 使⽤光⼝作为业务⼝的数据库集群即使在400并发的情况下，⽹络和TPS均持续增加。且100并发以下，即使电⼝未达到瓶颈，以光⼝作为业务⼝的集群性能仍更优。

2. skew_tick=1导致的性能问题

考虑到SQL 执⾏时延增加，可能是在CPU上的执⾏耗时增加，
所以通过perf top 查询测试时的热点函数。可以看到存在占比44%和11%的热点函数__kernel__gettimeofday和
__kernel_clock_gettime，但是正常情况下是没有占⽐如此⾼的热点函数的，所以主要排查两个函数的引⼊原因。

通过命令cat /proc/cmdline 查询grub启动参数，发现新增了⼀个 skew_tick=1 参数。 skew_tick=1参数会导致内核频繁地调整时钟中断的触发时间，来降低多个 CPU 争⽤ Linux 内核计时器ticks处理程
序中的公共锁的情况，从⽽减少中断响应时间的系统抖动，以此来提升性能。但是更频繁的时钟中断可能会导致更多的时间相关的系统调⽤，如 gettimeofday，引发了该问题的发⽣。

排查skew_tcik=1参数配置的原因，发现此前在优化低时延场景的业务时，修改了⽹络时延模式tuned-adm profile 
network-latency。 该配置会引⼊skew_tcik=1参数配置，引发了该问题。回退后（tuned-adm profile 
throughput-performance），两个热点函数__kernel__gettimeofday和__kernel_clock_gettime占⽐均下降⾄5%
以下，数据库集群性能正常。

本页内容