pstack.txt (406.7 KB)
今天下午也有这种情况，重启前采集了下pstack
这个pstack已经能说明问题了, 谢谢!
好的，如果确认是什么问题还请告知我们
导入频率太高, 已经出现’too many versions’积压错误, 可以尝试降低导入频率.
Fail to open fragment, instance_id=58471a6d-b6e4-208d-d8b3-afb714545495, status=Service unavailable: Too many versions. tablet_id: 10050156, version_count: 1001, limit: 1000
是因为导入频率太高导致的be异常？之前任务导入异常，也没有be出现问题丫。
看上去是这样的, 对应的导入是不是先异常了, 然后BE异常, 再FE异常.
确认了一下，这个任务数据量很少的，并发也不高，pstack信息能看出啥不？
pstack里BE的线程池被stream load的请求打满了.
可以尝试通过停止导入数据, 看看FE/BE是否能自愈, 来验证这个rootcause.
好的，那应该就是存在写阻塞的问题
我们这边还有问题需要帮忙回答的是，读写线程是一起的吗？理论上应该是分开才对？
你好，BE线程池有指标可以监控吗？哪个参数可以设置这个线程池上限？
stream load也需要FE做一个Execution Plan, 跟query一样, 这个execution plan使用同样的线程池, execution plan分发下去后, 后面写数据就用单独的IO线程了.
根据是否开启pipeline engine, 使用的线程池是不一样的.
Pipeline engine是开启的。我们想看下增加了这个线程池数量是否可以缓解这个问题
有没有这方面的详细的介绍呢？
pipeline_prepare_thread_pool_thread_num
be.conf里尝试调整一下这个参数，默认是BE的cpu core数。
调整前确认出问题时BE的CPU负载不高。我们后续会加上队列长度监控埋点，可以通过监控看到该线程池的排队和调度延迟。
好的，感谢！我们调整下看看
我们会议了下这两次出现问题前使用方是有频繁触发资源组限制的，第一次是触发了扫描行数限制。
第二次，是并发限制，不知道跟这个issuses有没有关系。。
pipeline_exec_thread_pool_thread_num
只找到be有这个参数。。代码里面也没有搜索到prepare相关的。
参数在2.4版本引入 https://github.com/StarRocks/starrocks/commit/995ca5d77dd16de1d37b8a903607c5074fa7c6bd
如果你的版本更早, 没有支持pipeline, 则这个参数不管用.