-
[OPIK-6519] [BE] perf: replace FINAL with LIMIT 1 BY in trace threads closing candidate query (#6748)
frostbyte_neo 发布于
2026-05-18 16:34:32 +00:00 - [OPIK-6519] [BE] perf: replace FINAL with LIMIT 1 BY in trace threads closing candidate query
The TraceThreadsClosingJob runs FIND_PENDING_CLOSURE_THREADS_SQL every 15s, and
on large self-hosted deployments (Uber: 132M rows, 36+ parts on trace_threads)
the FROM trace_threads FINAL + GROUP BY exceeds the 30s reactor timeout. Under
high-volume ingestion the reactor cancels but the underlying ClickHouse query
keeps running, R2DBC buffers accumulate, and the JVM crashes with OutOfMemoryError.Replaces the FINAL+GROUP BY dedup with the same LIMIT 1 BY reverse-order pattern
introduced in OPIK-4828 for the thread-view query. Measured on opik_prod
(16.37M rows, 10 parts), median wall time drops from ~2.9s to ~0.28s (~10x),
data read from 2.68 GiB to 76 MiB (~36x), memory from 130 MiB to 36 MiB (~4x),
with the identical result set verified on the same now() snapshot and on 997
threads with active/inactive transitions in the last 24h (100% agreement on
latest status between FINAL and LIMIT 1 BY).- chore(threads): add log_comment to pending-closure query
Routes FIND_PENDING_CLOSURE_THREADS_SQL through getSTWithLogComment so the
ClickHouse log_comment placeholder is populated, matching the rest of the
DAO. Addresses baz-reviewer feedback on PR #6748.下载附件