<@U033QQE20BY> Hello, we encountered an issue in p...
# questions-and-troubleshootinge
elon chen
10/31/2025, 8:51 AM@Murphy Hello, we encountered an issue in production. The query SELECT count(1) FROM task_runs WHERE CREATE_TIME > NOW() - INTERVAL 1 HOUR; causes the FE memory to spike until OOM. Could you please take a look? Thank you very much. A large number of objects are being created here.
elon chen
10/31/2025, 8:54 AMversion: sr-3.4.0
m
Murphy
11/01/2025, 1:52 AMupgrade to latest 3.4.x, it’s been fixed.
e
elon chen
11/03/2025, 2:36 AM@Murphy thank you
🙌 1
elon chen
11/03/2025, 9:36 AM@Murphy Since we made some modifications ourselves, it’s not convenient to directly upgrade to the latest version of 3.4.x, so we’re thinking of merging the related PRs #57404 and #59161. Is that sufficient?
Additionally, there’s a question: When adding this code else if (Config.task_runs_max_history_number > 0) { sql += ” ORDER BY create_time DESC LIMIT ” + Config.task_runs_max_history_number; }, how does this limit n get pushed down to BE? BE retrieves the limit parameter from _param->limit.
m
Murphy
11/03/2025, 10:32 AM1. yes
2. the flow of schema query is: FE -> BE -> FE -> BE, the problem of this case is that FE tries to fetch all records into memory