Spark Worker demandant des quantités absurdes de mémoire virtuelle

Question

Je suis en train d'exécuter un travail d'étincelle sur un cluster de fils à 2 nœuds. Mon dataset n'est pas grand (< 100MB) juste pour tester et le travailleur est tué car il demande trop de mémoire virtuelle. Les montants ici sont absurdes. 2 Go sur 11 Go de mémoire physique utilisée, 300 Go de mémoire virtuelle utilisée.

16/02/12 05:49:43 WARN scheduler.TaskSetManager: Lost tâche 0.0 à l'étape 2.1 (TID 22, ip-172-31-6-141.ec2.internal): ExecutorLostFailure (exécuteur testamentaire 2 sortie provoquée par l'une des tâches en cours d'exécution) Raison: Le conteneur est marqué comme ayant échoué: container_1455246675722_0023_01_000003 sur l'hôte: ip-172-31-6-141.ec2.internal. Statut de sortie: 143. Diagnostics: Container [pid = 23206, containerID = container_1455246675722_0023_01_000003] dépasse les limites de la mémoire virtuelle. Utilisation actuelle: 2,1 Go de mémoire physique de 11 Go utilisée; 305,3 Go de mémoire virtuelle de 23,1 Go utilisée. Tuer le récipient. vidage du processus arbre pour container_1455246675722_0023_01_000003: | - PID PPID pgrpid SESSID nom_cmd USER_MODE_TIME (MILLIS) system_time (MILLIS) VMEM_USAGE (OCTETS) RSSMEM_USAGE (PAGES) FULL_CMD_LINE | - 23292 23213 23292 23206 (python) 15 3 101298176 5514 python -m pyspark.daemon | - 23206 1659 23206 23206 (bash) 0 0 11431936 352/bin/bash -c/usr/lib/jvm/java-7-openjdk-amd64/bin/java -server -XX: OnOutOfMemoryError = 'kill% p' -Xms10240m -Xmx10240m -Djava.io.tmpdir =/tmp/racine-hadoop/nm-répertoire-local/usercache/root/appcache/application_1455246675722_0023/container_1455246675722_0023_01_000003/tmp '-Dspark.driver.port = 37386' -Dspark.yarn.app.container.log.dir =/mnt/yarn/logs/application_1455246675722_0023/conteneur_1455246675722_0023_01_000003 -XX: MaxPermSize = 256 m org.apache.spark.executor.CoarseGrainedExecutorBackend --driver-url spark: //CoarseGrainedScheduler@172.31 .0.92: 37386 --executor-id 2 --hostname ip-172-31-6-141.ec2.internal --cores 8 --app-id application_1455246675722_0023 - fichier de chemin d'accès à la classe d'utilisateurs:/tmp/hadoop- racine/nm-locale-dir/usercache/root/AppCache/application_1455246675722_0023/container_1455246675722_0023_01_000003/application jar 1>/mnt/fil/logs/application_1455246675722_0023/container_1455246675722_0023_01_000003/sortie standard 2>/mnt/fil/logs/application_1455246675722_0023/container_1455246675722_0023_01_000003/stderr | - 23292 23292 23206 23341 (python) 87 8 39464374272 23281 python -m pyspark.daemon | - 23292 23292 23206 23350 (python) 86 7 39463976960 24680 python -m pyspark.daemon | - 23292 23292 23206 23329 (python) 90 6 39464521728 23281 python -m pyspark.daemon | - 23213 23206 23206 23206 (java) 1168 61 11967115264 359820/usr/lib/jvm/java-7-openjdk-am d64/bin/java -server -XX: OnOutOfMemoryError = tuez% p -Xms10240m -Xmx10240m -Djava.io.tmpdir =/tmp/racine-hadoop/nm-répertoire-local/usercache/root/appcache/application_1455246675722_0023/container_1455246675722_0023_01_000003/tmp -Dspark.driver.port = 37386 -Dspark.yarn.app.container.log.dir =/mnt/yarn/logs/application_1455246675722_0023/conteneur_1455246675722_0023_01_000003 -XX: MaxPermSize = 256 m org.apache.spark.executor.CoarseGrainedExecutorBackend --driver- url spark: //CoarseGrainedScheduler@172.31.0.92: 37386 --executor-id 2 --hostname ip-172-31-6-141.ec2.internal --cours 8 --app-id application_1455246675722_0023 --user-class- chemin du fichier:/tmp/Hadoop-root/nm local dir/usercache/root/AppCache/application_1455246675722_0023/container_1455246675722_0023_01_000003/app .jar | - 23347 23292 23292 23206 (python) 87 10 39464783872 23393 python -m pyspark. daemon | - 23335 23292 23292 23 206 (python) 83 9 39464112128 23216 python -m pyspark.daemon | - 23338 23292 23292 23206 (python) 81 9 39463714816 24614 python -m pyspark.daemon | - 23332 23292 23292 23206 (python) 86 6 39464374272 24812 python - m pyspark.daemon | - 23344 23292 23292 23206 (python) 85 30 39464374272 23281 python -m pyspark.daemon Conteneur tué sur demande. Le code de sortie est 143

Est-ce que quelqu'un sait pourquoi cela pourrait se produire?J'ai essayé de modifier différentes configurations de fils et d'étincelles, mais je sais que quelque chose ne va vraiment pas dans ce sens.

Answer 1

La commande que je courais était

spark-submit --executor-cores 8 ... 

Il se trouve le drapeau exécuteur-cœurs ne fait pas ce que je pensais qu'il fait. Il fait 8 copies du processus pyspark.daemon, exécutant 8 copies du processus de travail pour exécuter des tâches. Chaque processus utilisait 38 Go de mémoire virtuelle, ce qui est inutilement grand, mais 8 * 38 ~ 300, ce qui explique cela.

C'est en fait un drapeau très mal nommé. Si je mets les executor-cores à 1, cela fait un démon, mais le démon utilisera plusieurs cœurs, comme vu via htop.