一次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% 以下，数据库集群性能正常。
