线上， 监控面板 be状态有时候会获取不到状态
发现是metric接口超时导致的，然后测试了下，有一种情况是是当streamload数据量比较大，并发稍微多点8-9个就行，就会发现metric接口时间变长。
但这里cpu，内存什么的都不怎么高。这里的配置也差不多只有个webserver_port， 但默认值显然大于远远大于streamload的请求个数。 但我改下代码，独立出一个metirc 的httpserver，就不存在类似问题。
于是我看了看最后只能怀疑brpc，然后没搞过这方面东西┭┮﹏┭┮，不晓得怎么排查。 盲猜和那个on_chunk方法处理数据传输，占用了监听线程导致？？？
您使用stream load是连FE还是直接连BE的？
卡住时, 可以用gdb attach到进程上, set pagination off 后thread apply all bt看一下http线程都在做什么. 可以发出来看看.
可以打个pstack 看看，可能是与主键模型导入有关系，最近我们修复过类似问题。
连接的是Fe，转发到be
和主键模型没有关系，我就是用ssb的数据做导入（节点1个， 数据量10G），然后监测metric接口的响应时间。
看上去有10个线程卡在starrocks::StreamLoadAction::_handle这儿了, 调整过be_http_num_workers这个参数吗?
这个就是streamload的处理线程呀，be_http_num_workers这个默认48个，所以上面有39个（其中一个是我加的httpserver）还是空闲的。
还有空闲的http server线程, 按说metrics不应该卡, 可以手动发起一个GET :8040/metrics, 卡住时, pstack看一下处理/metrics的线程在哪儿卡住了.
头疼，我上面的pstack信息就是卡主的时候搞的。我上面的描述是有啥问题吗，感觉没看明白的样子。
你描述的没有问题, 按现在pstack上的信息, 38个线程idle, 10个在做streamload, 没看到metrics HTTP请求去到哪儿了, 所以可能没有捕捉到metrics卡住的现场
我能说我抓了好多次都是这样吗？ 而且本来就只有10个并发的streamload请求，远小于be_http_num_workers定义的， 那么必然不是在http处理线程，而是在前面的socket的监听线程之类的上把。虽然我还是没找到，然后从抓包看，http请求已经到了这个节点。。。。确实就是返回慢，
卡住的同时, 看一下cpu load, 网络io, tcp socket SendQ/RecvQ长度, 感觉您自己快到定位到问题根因了.
能详述一下你的集群配置吗？几个BE，BE的CPU/MEM，使用的BE版本，stream load重现的步骤. 帮助我们自己重现这个问题，谢谢
重现步骤很简单，版本我用的2.5.3， 一台机器，fe be混部，8c 32G的样子，然后官网ssb测试的步骤导入10G的数据（当然改了下表的副本数1）并发应该默认就是10。 然后导入过程，就每隔秒发起metric请求，就 能复现了。
好的, 谢谢! 我这边尝试复现一下
请问您测试时的网络拓扑是什么样的? 看上面截图里, 一个在10.x段, 一个在172.x段
172 的是我的客户端的postman，没关系吧，只是发个metrics请求而已。数据是在befe的混布节点上发起的，也就是10。
