Spark java.lang.OutOfMemoryError: espacio del montón de Java

Tengo algunas sugerencias:

• Si sus nodos están configurados para tener un máximo de 6 g para Spark (y están dejando un poco para otros procesos), utilice 6 g en lugar de 4 g spark.executor.memory=6g. Asegúrate de estar usando la mayor cantidad de memoria posible verificando la interfaz de usuario (dirá cuánta memoria estás usando)
• Intente usar más particiones, debería tener de 2 a 4 por CPU. Aumentar el número de particiones con IME suele ser la forma más sencilla de hacer que un programa sea más estable (y, a menudo, más rápido). Para grandes cantidades de datos, es posible que necesites más de 4 por CPU. ¡He tenido que usar 8000 particiones en algunos casos!
• Disminuya la fracción de memoria reservada para el almacenamiento en caché mediante spark.storage.memoryFraction. Si no usa cache()o persisten su código, esto también podría ser 0. El valor predeterminado es 0.6, lo que significa que solo obtiene 0.4 * 4 g de memoria para su montón. La reducción de IME en la fractura de memoria a menudo hace que los OOM desaparezcan. ACTUALIZACIÓN: A partir de Spark 1.6 aparentemente ya no necesitaremos jugar con estos valores, Spark los determinará automáticamente.
• Similar al anterior pero con fracción de memoria aleatoria . Si su trabajo no necesita mucha memoria aleatoria, configúrelo en un valor más bajo (esto podría hacer que la reproducción aleatoria se derrame en el disco, lo que puede tener un impacto catastrófico en la velocidad). A veces, cuando se trata de una operación aleatoria que es OOM, necesitas hacer lo contrario, es decir, configurarla en algo grande, como 0.8, o asegurarte de permitir que tus operaciones aleatorias se derramen en el disco (es el valor predeterminado desde 1.0.0).
• Tenga cuidado con las pérdidas de memoria , que a menudo se deben al cierre accidental de objetos que no necesita en sus lambdas. La forma de diagnosticar es buscar la "tarea serializada como XXX bytes" en los registros; si XXX es mayor que unos pocos k o más de un MB, es posible que tenga una pérdida de memoria. Ver https://stackoverflow.com/a/25270600/1586965
• Relacionado con lo anterior; use variables de transmisión si realmente necesita objetos grandes.
• Si está almacenando en caché RDD grandes y puede sacrificar algo de tiempo de acceso, considere serializar el RDD http://spark.apache.org/docs/latest/tuning.html#serialized-rdd-storage . O incluso almacenarlos en caché en el disco (lo que a veces no es tan malo si se usan SSD).
• ( Avanzado ) En relación con lo anterior, evite Stringestructuras muy anidadas (como Mapclases de casos anidadas). Si es posible, intente utilizar únicamente tipos primitivos e indexar todos los no primitivos, especialmente si espera muchos duplicados. Elija WrappedArrayestructuras anidadas siempre que sea posible. O incluso implemente su propia serialización: USTED tendrá la mayor información sobre cómo realizar una copia de seguridad de sus datos en bytes de manera eficiente. ¡ ÚSALO !
• ( un poco hacky ) Nuevamente, al almacenar en caché, considere usar a Datasetpara almacenar en caché su estructura, ya que utilizará una serialización más eficiente. Esto debe considerarse como un truco en comparación con el punto anterior. Incorporar el conocimiento de su dominio en su algoritmo/serialización puede minimizar la memoria/espacio de caché en 100x o 1000x, mientras que todo lo que Datasetprobablemente dará es 2x - 5x en memoria y 10x comprimido (parquet) en disco.

http://spark.apache.org/docs/1.2.1/configuration.html

EDITAR : (Para poder buscar en Google más fácilmente) Lo siguiente también es indicativo de este problema:

java.lang.OutOfMemoryError : GC overhead limit exceeded

Mar 30 '2014 10:03 samthebest