Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

[Bug] Limiting memory does not degrade query latency

Đang mở
  • Có gì không ổn?
#17,070 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
35/100
Loại issue
Lỗi
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Đình trệ
Công nghệ
docker, java, sql
Lĩnh vực
databases, performance

Hướng nghiên cứu

Bắt đầu bằng cách tái hiện workload được báo cáo từ MulletBench bằng các cấu hình bộ nhớ Docker Compose được mô tả trong issue, rồi so sánh độ trễ truy vấn với mức sử dụng bộ nhớ của container. Truy vết hành vi của cơ sở dữ liệu chịu trách nhiệm cho việc độ trễ không thay đổi giữa các giới hạn; công việc được xem là hoàn tất khi đã xác định được nguyên nhân và xác thực một bản sửa lỗi trên các workload tổng hợp, downsampling và lọc ngoại lệ.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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!
Ngôn ngữ chính
Java
Star
6.4k
Fork
1.2k
Merge trung bình
1 ngày 17 giờ
Pull request đã merge (30 ngày)
152

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của apache/iotdb

Tất cả issue của apache/iotdb

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.