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

[Improvement]: Implement heap-based flush mechanism for SortedPosDeleteWriter to prevent OOM

Đang mở
  • Có gì không ổn?
#4,166 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 2 ngày

@slfan1989 đang làm issue này rồi.

Từ ngày 19/7/2026.

  • #4167 của @slfan1989 — đã đóng, không merge
  • #4276 của @slfan1989 — đang mở

Đá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
52/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
java
Lĩnh vực
data-engineering, databases

Hướng nghiên cứu

Bắt đầu từ SortedPosDeleteWriter và TODO liên quan đến điều kiện flush theo số lượng bản ghi của nó; lần theo các constructor và cách xử lý thuộc tính bảng. Định nghĩa HeapUsageProvider và policy dựa trên heap bên cạnh ngưỡng bản ghi hiện có, sau đó xác minh bằng các test rằng các kiểm tra về số bản ghi tối thiểu và tỷ lệ không hợp lệ, tính tương thích của constructor và việc giám sát không ép buộc GC đều được bao phủ.

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

Mô tả

stale type:improvement
Search before asking
  • I have searched in the issues and found no similar issues.
What would you like to be improved?

Currently, SortedPosDeleteWriter only flushes buffered position deletes based on a record count threshold. There is a TODO comment in the code indicating the need for a heap memory-based flush policy:

// TODO Flush buffer based on the policy that checking whether whole heap memory size exceed the
// threshold.
if (records >= recordsNumThreshold) {
  flushDeletes();
}

Problem: When processing large-scale position deletes, the in-memory buffer in SortedPosDeleteWriter can grow unbounded (if record threshold is set very high or to Long.MAX_VALUE), potentially causing OutOfMemoryError (OOM) issues, especially in memory-constrained environments.

Current behavior:

  • Only flushes when record count reaches recordsNumThreshold
  • No protection against heap memory pressure
  • Can lead to OOM when processing large delete operations
How should we improve?

Implement a heap memory-based flush mechanism with the following features:

1. New table properties:
  • pos-delete.flush.heap.ratio (default: 0.8) - Heap usage ratio threshold to trigger flush
  • pos-delete.flush.records (default: Long.MAX_VALUE) - Record count threshold
  • pos-delete.flush.heap.min-records (default: 1000) - Minimum records before heap-based flush kicks in
2. Implementation details:
  • Add HeapUsageProvider interface to monitor JVM heap usage
  • Implement shouldFlushByHeap() method to check if heap usage exceeds threshold
  • Modify flush logic to: if (records >= recordsNumThreshold || shouldFlushByHeap())
  • Ensure backward compatibility through constructor overloads
3. Safety guards:
  • Prevent frequent small flushes with minimum record count
  • Allow disabling heap-based flush by setting invalid ratio (≤0 or ≥1)
  • Non-intrusive monitoring (no forced GC)
Are you willing to submit PR?
  • Yes I am willing to submit a PR!
Subtasks

No response

Code of Conduct
Ngôn ngữ chính
Java
Star
1.2k
Fork
398
Merge trung bình
1 ngày 14 giờ
Pull request đã merge (30 ngày)
19

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/amoro

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

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.