Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

[Bug] Limiting memory does not degrade query latency

Offen
  • Stimmt etwas nicht?
#17,070 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
35/100
Issue-Typ
Bug
Klarheit
Muss geklärt werden
Aktivitätsstatus
Veraltet
Tech-Stack
docker, java, sql
Bereich
databases, performance

Rechercherichtung

Beginne damit, die gemeldete Workload aus MulletBench mithilfe der in der Issue beschriebenen Docker-Compose-Speicherkonfigurationen zu reproduzieren, und vergleiche die Abfragelatenz mit der Speichernutzung des Containers. Verfolge das Datenbankverhalten, das für die unveränderte Latenz über die Limits hinweg verantwortlich ist; als abgeschlossen gilt die Arbeit, wenn die Ursache identifiziert und eine Korrektur anhand der Workloads für Aggregation, Downsampling und Ausreißerfilter validiert wurde.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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:

  1. Launch IoTDB in standalone mode with constrained memory using Docker Compose
  2. Preload data before executing queries
  3. 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
Image Image
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!
Vorherrschende Sprache
Java
Sterne
6.4k
Forks
1.2k
Ø Merge
1 T. 17 Std.
Gemergte PRs (30 T.)
152

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus apache/iotdb

Alle Issues in apache/iotdb

Ähnliche Issues

Weitere Issues zu Java

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.