[Bug] Limiting memory does not degrade query latency
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 35/100
- issue の種類
- バグ
- 明瞭さ
- 説明が足りない
- 活発さ
- 停滞
- 領域
- databases, performance
調査の方向性
まず、issue に記載された Docker Compose のメモリ構成を使用して、MulletBench で報告されたワークロードを再現し、クエリのレイテンシとコンテナのメモリ使用量を比較します。各制限値でレイテンシが変わらない原因となっているデータベースの挙動を追跡します。集計、ダウンサンプリング、外れ値フィルタリングのワークロードに対して原因を特定し、修正を検証できれば完了です。
索引モデルが issue の本文から書いたものです。
説明
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!
- 主要言語
- Java
- スター
- 6.4k
- フォーク
- 1.2k
- 平均マージ
- 1日 17時間
- マージ済み PR(30日)
- 152
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
apache/iotdb のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
-
IoTDB Edge: stop-edge.sh does not stop its own process when IOTDB_HOME is set, and reports success オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
-
[Bug] findColumn throws NullPointerException instead of SQLException for an unknown column name オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
HL7/fhir-ig-publisher#1375 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
-
Flaky: a relaunched catch-up replay can still report catching up right after its marker is written オープンbug
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
johanhaleby/occurrent#1134 ·
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
objectionary/jeo-maven-plugin#1811 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100