Hi starrocks team, I have increased the parameter task_runs_concurrency to 10 and everything slowed down, all the queries took much longer even show compute nodes was taking a few seconds , and some latency increased in the front ends nodes.Why? Also the statistics job was failing after a mat view refresh. We are heavily using mat view and we have more than 10k refreshes a day. We have 3 front ends nodes 16gb 8cpu and 5 compute nodes 40gb mem 8cpu I reverted back and set it to 5 and we are back to normal. But we would want to have more than 5 concurrent mat views refresh. Can you please help? Maybe some extra config is required? Using 4.0.1 Thanks Julien-David

Hi @Julien David, I hope the following helps resolve your issue(if you didn't try this way). When task_runs_concurrency is increased, each MV refresh triggers synchronous statistics collection on completion, which blocks the TaskRun thread for up to 30 seconds and consumes additional CN resources. This is a key factor behind the system-wide slowdown you experienced. Based on the https://docs.starrocks.io/docs/using_starrocks/Cost_based_optimizer/#collect-statistics-during-data-loading docs, there are two options to mitigate this: Option 1: Disable statistics collection on first load

ADMIN SET FRONTEND CONFIG ("enable_statistic_collect_on_first_load" = "false");

This completely disables the immediate statistics collection triggered after all data loading — including INSERT INTO (MV refresh), INSERT OVERWRITE, Stream Load, and Broker Load. It eliminates the 30-second synchronous blocking entirely, which is the most effective fix for your case. The trade-off is that statistics for regular tables will also no longer be collected immediately after loading. However, StarRocks has a background Auto Collector (default: every 5 minutes) that will keep all table and MV statistics up to date, so query plan quality should not be affected. Option 2: Reduce the synchronous await timeout

ADMIN SET FRONTEND CONFIG ("semi_sync_collect_statistic_await_seconds" = "5");

This keeps the immediate statistics collection enabled for all load types, but reduces the maximum blocking time from 30 seconds to 5 seconds. Statistics collection still happens on every MV refresh, but the TaskRun thread won't be blocked for as long. If the collection takes longer than 5 seconds, it continues asynchronously in the background, so there's minimal risk. Key difference: Option 1 completely removes the statistics overhead from MV refresh, while Option 2 only reduces the blocking time. For your environment with 10k+ MV refreshes/day, Option 1 would be more effective. Choose Option 2 if you prefer to keep immediate statistics collection for regular INSERT and Stream Load operations. Note that these two options are independent — if you choose Option 1, Option 2 becomes unnecessary since the collection itself is skipped entirely. After applying either option, you can try increasing task_runs_concurrency gradually (5 → 7 → 8) while monitoring FE heap usage and query latency. Thanks.

Thanks that's very helpful. We also found some issues on the slowness related to the me wort swap of the FE nodes. We added some mem_limit to avoid using the full memory. However now we are back to normal I have a 500 queues of mat view refresh and it seems undressing the task_runs_concurrency is not making more mat view refreshing at the same time. I am stuck with one or 2 max. Even though there is no limit on the resource group. Do you know what can cause this @김병주 ? The task_runs table is 10500 rows

Hi @Julien David, One more thing you can try for the 500 queue backlog — lowering

task_runs_max_history_number

from the default 10,000 to around 1,000:

ADMIN SET FRONTEND CONFIG ("task_runs_max_history_number" = "1000");

This reduces FE memory usage and speeds up the scheduling loop, so pending refreshes get picked up a bit faster. It's not a major change but helps with overall queue throughput. The tradeoff is you'll only see the most recent ~1,000 refresh history entries. Thanks.

Good idea thank you