【详述】并发测试结束后无操作半小时左右, 用mysql client 连接就会很慢(大概2分钟左右)但不会失败, 之日中报错 “onceTalkTimeout”, 后续的所有查询都会超时并报这个错误, 持续10分钟左右, 后面就会正常, 但是一旦中间无操作半小时左右又会重复刚才的问题
【背景】连接数没问题, be 连接没问题
【业务影响】
【StarRocks版本】2.4.2
【集群规模】1fe+3be
【机器信息】8+32
【联系方式】社区群6-小刘(radioliu92@163.com)
【附件】
FE出现这个问题时麻烦打一下jstack发给我们
jstack -l $pid > jstack.log
日志会提交给研发同学，需要恢复重启fe即可
好的，查到原因或者修复了，回复下
后续的所有查询都会超时并报这个错误
麻烦确认一下fe.audit.log里面这些超时查询的query_id能否在be.INFO上能找到吗？
就像以下的日志那样
I0121 18:14:33.902791 4525 fragment_executor.cpp:148] Prepare(): query_id=66b642f9-9974-11ed-9dc1-1ee0e5254c19 fragment_instance_id=66b642f9-9974-11ed-9dc1-1ee0e5254c1b backend_num=0
I0121 18:14:33.914991 4607 fragment_executor.cpp:148] Prepare(): query_id=66b642f9-9974-11ed-9dc1-1ee0e5254c19 fragment_instance_id=66b642f9-9974-11ed-9dc1-1ee0e5254c1a backend_num=1
[fe.audit.log]
2023-01-22 10:52:09,474 [query] |Client=10.10.60.21:46686|User=root|AuthorizedUser=‘root’@’%’|ResourceGroup=|Catalog=default_catalog|Db=|State=ERR|ErrorCode=|Time=120158|ScanBytes=0|ScanRows=0|ReturnRows=0|StmtId=1290|QueryId=7bec57b9-99ff-11ed-90b4-005056895915|IsQuery=true|feIp=10.10.20.108|Stmt=select @@version_comment limit 1|Digest=|PlanCpuCost=0.0|PlanMemCost=0.0
2023-01-22 10:52:09,474 [slow_query] |Client=10.10.60.21:46686|User=root|AuthorizedUser=‘root’@’%’|ResourceGroup=|Catalog=default_catalog|Db=|State=ERR|ErrorCode=|Time=120158|ScanBytes=0|ScanRows=0|ReturnRows=0|StmtId=1290|QueryId=7bec57b9-99ff-11ed-90b4-005056895915|IsQuery=true|feIp=10.10.20.108|Stmt=select @@version_comment limit 1|Digest=|PlanCpuCost=0.0|PlanMemCost=0.0
2023-01-22 10:54:23,773 [query] |Client=10.10.60.21:46686|User=root|AuthorizedUser=‘root’@’%’|ResourceGroup=|Catalog=default_catalog|Db=|State=ERR|ErrorCode=|Time=120139|ScanBytes=0|ScanRows=0|ReturnRows=0|StmtId=1291|QueryId=cbfbcbac-99ff-11ed-90b4-005056895915|IsQuery=true|feIp=10.10.20.108|Stmt=SELECT DATABASE()|Digest=|PlanCpuCost=0.0|PlanMemCost=0.0
2023-01-22 10:54:23,773 [slow_query] |Client=10.10.60.21:46686|User=root|AuthorizedUser=‘root’@’%’|ResourceGroup=|Catalog=default_catalog|Db=|State=ERR|ErrorCode=|Time=120139|ScanBytes=0|ScanRows=0|ReturnRows=0|StmtId=1291|QueryId=cbfbcbac-99ff-11ed-90b4-005056895915|IsQuery=true|feIp=10.10.20.108|Stmt=SELECT DATABASE()|Digest=|PlanCpuCost=0.0|PlanMemCost=0.0
2023-01-22 10:54:23,777 [query] |Client=10.10.60.21:46686|User=root|AuthorizedUser=‘root’@’%’|ResourceGroup=|Catalog=default_catalog|Db=tpch|State=EOF|ErrorCode=|Time=0|ScanBytes=0|ScanRows=0|ReturnRows=3|StmtId=1292|QueryId=1398299e-9a00-11ed-90b4-005056895915|IsQuery=false|feIp=10.10.20.108|Stmt=show databases|Digest=
2023-01-22 10:54:23,779 [query] |Client=10.10.60.21:46686|User=root|AuthorizedUser=‘root’@’%’|ResourceGroup=|Catalog=default_catalog|Db=tpch|State=EOF|ErrorCode=|Time=1|ScanBytes=0|ScanRows=0|ReturnRows=9|StmtId=1293|QueryId=139850af-9a00-11ed-90b4-005056895915|IsQuery=false|feIp=10.10.20.108|Stmt=show tables|Digest=
2023-01-22 10:56:05,073 [query] |Client=10.10.60.21:46686|User=root|AuthorizedUser=‘root’@’%’|ResourceGroup=|Catalog=default_catalog|Db=tpch|State=ERR|ErrorCode=|Time=60036|ScanBytes=0|ScanRows=0|ReturnRows=0|StmtId=1294|QueryId=2c2ff061-9a00-11ed-90b4-005056895915|IsQuery=true|feIp=10.10.20.108|Stmt=select count(1) from lineitem|Digest=|PlanCpuCost=8.0|PlanMemCost=8.0
2023-01-22 10:56:05,073 [slow_query] |Client=10.10.60.21:46686|User=root|AuthorizedUser=‘root’@’%’|ResourceGroup=|Catalog=default_catalog|Db=tpch|State=ERR|ErrorCode=|Time=60036|ScanBytes=0|ScanRows=0|ReturnRows=0|StmtId=1294|QueryId=2c2ff061-9a00-11ed-90b4-005056895915|IsQuery=true|feIp=10.10.20.108|Stmt=select count(1) from lineitem|Digest=|PlanCpuCost=8.0|PlanMemCost=8.0
[be.INFO]
没有这些 query_id
新年快乐 [凑个8字符]
新年快乐！
就是超时的查询的query_id 都没有在be.INFO上找到，是吗？
是的，没找到 query_id
但是前面两个没有报错就是需要2分钟左右，最后一个查询超时，前面两个，一个是连接，一个是use database
有点像是通讯的问题
出现这个问题的时候ping过没问题
看下be.out，应该是be挂了，dmesg -T 看是否有OOM记录
无, 关键过个几分钟就会恢复或者重启fe就立即恢复
可以检查下10.10.20.88这个机器和别的机器的端口是否都是互通的。
出现问题的时候 看了下 通信没问题
已查出原因，是路由器的硬件放火墙有问题，会定时Kill空闲Tcp链接
十分感谢，抽出时间找原因
您好 这个问题怎么解决呀
