Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#57,530 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
静か
技術スタック
scala
領域
distributed-systems, performance

調査の方向性

UnifiedMemoryManager と既存の MemoryConsumer の spill パスから始め、続いてプロトタイプの cgroup v1/v2 の読み取り値と JVM/native の予算に関する前提を確認します。有用な成果は、maintainer に承認された方向性（executor-overhead の設定、起動時の上限または警告、あるいはランタイムフィードバック）を定め、その後に焦点を絞った reproducer とテストを用意することです。

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
Scala
スター
44.3k
フォーク
29.5k
平均マージ
8時間 43分
マージ済み PR（30日）
1

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

apache/spark のほかの issue

apache/spark の issue をすべて見る

似ている issue

Scala の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。