[Bug] Limiting memory does not degrade query latency
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 35/100
- Tipo di issue
- Bug
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Ambito
- databases, performance
Direzione di ricerca
Inizia riproducendo il workload segnalato di MulletBench utilizzando le configurazioni di memoria di Docker Compose descritte nell’issue e confronta la latenza delle query con l’utilizzo di memoria del container. Traccia il comportamento del database responsabile della latenza invariata tra i limiti; il lavoro è concluso quando la causa è stata identificata e una correzione è stata convalidata sui workload di aggregazione, downsampling e filtro degli outlier.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Search before asking
- I searched in the issues and found nothing similar.
Version
1.1.3 and 1.3.4 (tested with standalone Docker image)
Describe the bug and provide the minimal reproduce step
While testing IoTDB under limited memory configurations, using docker for that effect, it was found that the database's performance won't drop until the threshold of 4GB of memory is hit, despite it always using the maximum amount of memory allocated for the container.
It was expected that progressively constraining the database's available memory would lead to gradual performance degradation, but instead IoTDB maintains virtually identical query latency across the tested memory limits, despite always consuming the maximum amount of memory available to the container.
Minimal reprodution steps:
- Launch IoTDB in standalone mode with constrained memory using Docker Compose
- Preload data before executing queries
- Execue a query workload, using the same for every memory configuration
The queries follow the following templates:
-- Aggregation
select agg_func(field) from path where time >= start and time <= end
-- Downsampling
select field from path group by ([start, end), step)
-- Outlier-filter
select field from path where time >= start and time <= end and field [>,>=,<,<=] threshold
What did you expect to see?
Either performance degradation as memory limits get increasingly smaller, or the container not using all the memory available to it, if it is able to maintain performance with less memory usage.
What did you see instead?
Performance didn't degrade until the 4GB memory limit, remaining similar regardless of the limit used, despite the database always using the maximum memory allocated to it.
Anything else?
The tests were run using MulletBench, as well as plot generation.
Are you willing to submit a PR?
- I'm willing to submit a PR!
- Lingua principale
- Java
- Stelle
- 6.4k
- Fork
- 1.2k
- Merge medio
- 1g 17h
- PR unite (30g)
- 152
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di apache/iotdb
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
-
IoTDB Edge: stop-edge.sh does not stop its own process when IOTDB_HOME is set, and reports success Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
-
[Bug] findColumn throws NullPointerException instead of SQLException for an unknown column name Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
Tutte le issue di apache/iotdb
Issue simili
-
area-deployment area-integrations triage:bot-seen
Difficoltà 2/5 Mezza giornata Idoneità per principianti 86/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
apache/flink-agents#1156 ·
-
[source-shopify] FAILED bulk operation without partialDataUrl is silently treated as successful Apertaarea/connectors autoteam community connectors/source/shopify needs-triage team/use type/bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 85/100