Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#57,530 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Tranquilo
Stack tecnológico
scala
Área
distributed-systems, performance

Línea de trabajo

Empieza por UnifiedMemoryManager y la ruta de spill existente de MemoryConsumer; después revisa las lecturas de cgroup v1/v2 del prototipo y las suposiciones sobre el presupuesto de JVM/native. Un resultado útil sería una dirección aprobada por los maintainers —configuración de executor-overhead, un límite o advertencia al iniciar, o feedback en tiempo de ejecución— seguida de un reproducer y pruebas enfocados.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Scala
Estrellas
44.2k
Forks
29.5k
Merge medio
8 h 43 min
PR fusionados (30 d)
1

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de apache/spark

Todos los issues de apache/spark

Issues similares

Más issues de Scala

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.