【 使用环境 】 测试环境
【 OB or 其他组件 】Oceanbase、OBproxy=4.3.1
【 使用版本 】4.3.1
【问题描述】使用sysbench工具压测，分布式事务特别耗时，但是sql执行计划也没有分布式，且SQL响应时间又是很快的。不知道是什么问题
租户配置：26C 100G
Obproxy三节点集群配置：32C 32G * 3
data和redo硬盘配置是PCIE NVME P4510
硬件配置信息：
华为1288v5
CPU：gold 6133 @ 2.5GH * 2 40核80线程
内存: 256G
硬盘: 600G SAS 系统盘
nvme 2T P4510 redo日志盘 * 1
nvme 2T P4510 data数据盘 * 1
网卡：万兆
跟官方文档的压测报告性能差距很大：
官网给的数据是基于阿里云、多云的ECS机器做的测试，不同环境性能差异肯定是有的，跟测试方式、网络环境等都有比较大的影响。不过你上面的数据差距也比较大，可以按照下面的方式给一些信息：
Read Write的场景，性能的关键点有几个：
1）这个场景由于case本身访问的数据量比较大，所以要确保客户端和server端网卡的带宽不能成为瓶颈。检查方式：
sudo ethtool eth0(要写具体的网卡名)；
2）这个case里面有4条SQL涉及到范围查询，如果表创建过程中设置了分区，会存在跨分区的访问，对性能也是有比较大的影响；
3）压测命令，不同的压测命令也很重要，可以贴下，一起看看；
4）表的数量和单表的数据量也可以列下；
5）最后，问题的排查，建议先从单并发来看，如果单并发的延迟对，再看高并发，如果不对，高并发基本不会好。
具体的方法：跑point select这个case，跑10s之后，看单个并发的avg rt，预期物理机下同机房网络延迟在50us左右，单个并发的avg rt，整体的延迟要在200us左右，如果测试出来的值很离谱，先排查网络，部署的问题；
网卡是万兆的，带宽还未到达瓶颈
压测命令是：sysbench oltp_read_write.lua --mysql-host=x.x.x.x --mysql-port=xxxx --mysql-db=test --mysql-user=$user@$tenant --mysql-password=xxx --table_size=1000000 --tables=30 --threads=1024 --report-interval=10 --time=60 --rand-type=uniform --db-ps-mode=disable run
压测命令和网卡带宽都问题不大，跑个单并发的point select看看结果？
有具体的命令参数吗
压测命令是：sysbench oltp_point_select.lua --mysql-host=x.x.x.x --mysql-port=xxxx --mysql-db=test --mysql-user=$user@$tenant --mysql-password=xxx --table_size=1000000 --tables=30 --threads=1024 --report-interval=10 --time=60 --db-ps-mode=disable run
压测首先要保证observer节点cpu跑满：
看起来是客户端给的压力不够，建议直连leader测一下试试。同时检查一下sysbench客户端和observer所在机器的cpu核数：lscpu；网卡队列数量：ethtool -l eth0（改下网卡名字）
leader的IP地址可以通过日志流的位置判断：select * from __all_virtual_ls_info where tenant_id = 1002 and ls_state=‘leader’;
从上面这个图上看的出来，你的压力连到了follower上，导致请求远程执行。
建议你先直连下leader做下压测；
连的是3个obproxy，由obproxy去分配路由的。租户优先级是随机模式，3个节点随机
请问老师这边通过上面介绍的直连测试状况如何
