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

[DISCUSS][CORE] Should managed off-heap memory take the container limit into account?

Đang mở
  • Có gì không ổn?
#57,530 0 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

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

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Ít trao đổi
Công nghệ
scala
Lĩnh vực
distributed-systems, performance

Hướng nghiên cứu

Bắt đầu với UnifiedMemoryManager và đường dẫn spill hiện có của MemoryConsumer, sau đó xem xét các giá trị đọc cgroup v1/v2 của prototype và các giả định về ngân sách JVM/native. Một kết quả hữu ích là một hướng đi được maintainer phê duyệt — cấu hình executor-overhead, giới hạn hoặc cảnh báo khi khởi động, hoặc phản hồi trong thời gian chạy — tiếp theo là một reproducer tập trung và các bài kiểm thử.

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

Mô tả

I have been looking at how Spark managed off-heap memory behaves in a memory-limited container.
One thing that seems easy to misconfigure is that these three limits are independent:

container limit:                 1500 MiB
JVM max heap:                    1024 MiB
spark.memory.offHeap.size:       2048 MiB

spark.memory.offHeap.size is only an upper bound used by Spark's memory manager, so the example
above does not fail immediately. The problem is that UnifiedMemoryManager does not know about the
1500 MiB process limit. If heap, managed off-heap memory, direct buffers, thread stacks, and other
native allocations grow at the same time, the container can kill the executor before Spark gets a
chance to spill.

In that case there may be no useful Java OOM. From outside the container it can just look like:

exit code 137
OOMKilled=true

Using JVM heap occupancy as the feedback signal does not seem right here. It cannot see off-heap
or other native memory, and it moves with GC. The cgroup usage and limit describe the boundary that
actually kills the process.

I made a small prototype that reads cgroup v1/v2 values and uses them to put a lower admission
limit on Spark-managed off-heap memory. At startup the rough budget is:

cgroup limit - JVM max heap - native reserve

The admission limit can then be reduced when total cgroup usage is high. This still relies on the
existing MemoryConsumer and spill code; it does not add another eviction mechanism.

There are some non-obvious details. In particular, setting the limit to zero is not safe because a
task may fail to allocate its first sorter page and throw SparkOutOfMemoryError instead of
spilling. Also, a fixed native reserve is probably too simplistic across different collectors,
core counts, and deployment modes.

Before spending more time on the prototype, I would like to check the expected direction:

  1. Should Spark use the container limit when admitting managed off-heap allocations, or is this
    expected to be handled entirely by executor memory-overhead configuration?
  2. If Spark should handle it, would a startup warning/static cap be preferable to runtime
    cgroup-pressure feedback?

If this belongs in Spark Core, I can follow up with a focused reproducer and tests for the approach
maintainers prefer.

Ngôn ngữ chính
Scala
Star
44.2k
Fork
29.5k
Merge trung bình
8 giờ 43 phút
Pull request đã merge (30 ngày)
1

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

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

Issue tương tự

Thêm issue về Scala

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.