Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

ClickHouse: Cold runs preload data into memory before the timer

Aperta
  • Qualcosa non va?
#941 1 commento 5 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
shell, sql
Ambito
databases, performance

Direzione di ricerca

Leggi prima la definizione di true-cold in README.md e i commenti di startup di ClickHouse/install. Traccia come il caricamento all'avvio e la cancellazione della cache sono rappresentati nel flusso del benchmark. Il lavoro è concluso quando la policy dei cold-run è decisa esplicitamente e il comportamento del benchmark e la documentazione sono coerenti.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Commit 7c1f7a3291521738a7731af38c994debb1ea3b1e enables preloading of the primary key on ClickHouse startup.

Quoting clickhouse/install:

# Force synchronous startup loading so the cold timer doesn't catch
# work that should have been amortized into ./start.
#
# Two independent layers of laziness contribute to the cold-query floor:
#
# 1. async_load_databases (server-level): with the default 1, the server
#    binds its listen port and answers SELECT 1 before user databases
#    have finished loading. ./check passes, then the first query stalls
#    waiting for the part loader.
#
# 2. primary_key_lazy_load and columns_and_secondary_indices_sizes_lazy_calculation
#    (MergeTree-level): even after parts are loaded, the in-memory
#    primary key and the per-column .size streams are populated lazily
#    on first query. With ~25 parts × ~80 columns × multiple metadata
#    files per column that's >1.8k file opens on the first query path,
#    contributing several hundred ms even on local NVMe.
#
# Both are eager-load toggles, not caching shortcuts: the same I/O
# happens either way, just before query timing instead of during it.
# Together they brought Q40 cold from ~3 s to ~1.5 s on c6a.4xlarge.

README.md defines true cold runs differently:

2.a) True cold runs. Before each first run of each query, all [...] database caches (e.g. buffer pools) are cleared.

In the current configuration, ClickHouse pre-warms the primary key data at startup, which defeats the clearing of all database caches. The measured cold runs times aren't truly cold anymore. While size-calculations might be considered metadata, primary key data is definitively data that's also queried by the benchmark queries.

I'm not sure there's a good definition which data is fine to be cached for a true cold run and which not.
Two of my suggestions below:

  1. Include startup times in "true cold" runs. This effectively prevents cheating by preloading data at startup.
  2. Drop the cold run altogether. "Cold" is clearly different for different systems and does not compare performance apples-to-apples
Lingua principale
Shell
Stelle
1.1k
Fork
321
Merge medio
3h 57m
PR unite (30g)
607

Preparare l'ambiente

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ClickHouse/ClickBench

Tutte le issue di ClickHouse/ClickBench

Issue simili

Altre issue su Shell/Bash

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.