【 使用环境 】生产环境
【 OB or 其他组件 】
【 使用版本 】
【问题描述】通过sysbench进行测试一直出现timeout问题。
目前在做OceanBase在vm下和k8s 容器下性能对比测试。
【复现路径】问题出现前后相关操作
【附件及日志】
请提供一下系统的资源配置，可以的话把 observer 的日志也作为附件上传一下吧
vm 创建租户：
pod创建租户：
CREATE RESOURCE UNIT tpch_unit max_cpu 13, memory_size ‘9g’;
CREATE RESOURCE POOL tpch_pool unit = ‘tpch_unit’, unit_num = 1, zone_list=(‘zone1’,‘zone2’,‘zone3’);
CREATE TENANT tpch_mysql resource_pool_list=(‘tpch_pool’), zone_list(‘zone1’, ‘zone2’, ‘zone3’), primary_zone=RANDOM, locality=‘F@zone1,F@zone2,F@zone3’ set variables ob_compatibility_mode=‘mysql’, ob_tcp_invited_nodes=’%’,secure_file_priv = ‘’;
感谢咨询，你的问题已反馈研发同学分析，有结果会及时回复你。
手动连接下集群，执行下建表语句，看下会超时吗。看下是不是client->proxy->observer的网络延迟太大了。在测试租户下把这两个参数调大点试试
set global ob_query_timeout=36000000000;
set global ob_trx_timeout=36000000000;
这两个参数已经配置很大了。在租户下配置了这些参数：
SET GLOBAL ob_sql_work_area_percentage = 80;
SET GLOBAL ob_query_timeout = 36000000000;
SET GLOBAL ob_trx_timeout = 36000000000;
SET GLOBAL max_allowed_packet = 67108864;
parallel_servers_target = max_cpu * server_num * 8
SET GLOBAL parallel_servers_target = 624;
用mysql命令行连接下，手动执行下报错的语句，报错后执行select last_trace_id(); 根据返回的trace id在observer的日志搜搜报错的日志
在命令行执行该sql然后再select last_trace_id();
