Problemi di prestazione per la scintilla su YARN

Question

Stiamo provando a far funzionare il nostro cluster di scintilla su filato. Stiamo riscontrando alcuni problemi di prestazioni, in particolare rispetto alla modalità standalone.

Abbiamo un cluster di 5 nodi con ciascuno con 16 GB di RAM e 8 core ciascuno. Abbiamo configurato la dimensione minima del contenitore di 3 GB e quella massima di 14 GB in yarn-site.xml. Quando si invia il lavoro a filato-cluster, forniamo il numero di executor = 10, memoria dell'esecutore = 14 GB. Secondo la mia comprensione il nostro lavoro dovrebbe essere assegnato 4 contenitori di 14 GB. Ma l'interfaccia utente della scintilla mostra solo 3 contenitori da 7,2 GB ciascuno.

Non siamo in grado di garantire il numero del contenitore e le risorse ad esso assegnate. Ciò causa prestazioni dannose rispetto alla modalità standalone.

È possibile rilasciare qualsiasi puntatore su come ottimizzare le prestazioni del filo?

Questo è il comando che uso per la presentazione del lavoro:

$SPARK_HOME/bin/spark-submit --class "MyApp" --master yarn-cluster --num-executors 10 --executor-memory 14g target/scala-2.10/my-application_2.10-1.0.jar 

A seguito della discussione ho cambiato il mio file filo-site.xml e anche il comando scintilla presentare.

Ecco il nuovo codice filo-site.xml:

<property> 
<name>yarn.resourcemanager.hostname</name> 
<value>hm41</value> 
</property> 

<property> 
<name>yarn.nodemanager.resource.memory-mb</name> 
<value>14336</value> 
</property> 

<property> 
<name>yarn.scheduler.minimum-allocation-mb</name> 
<value>2560</value> 
</property> 

<property> 
<name>yarn.scheduler.maximum-allocation-mb</name> 
<value>13312</value> 
</property> 

E il nuovo comando scintilla presentare è

$SPARK_HOME/bin/spark-submit --class "MyApp" --master yarn-cluster --num-executors 4 --executor-memory 10g --executor-cores 6 target/scala-2.10/my-application_2.10-1.0.jar 

Con questo sono in grado di ottenere 6 core su ogni macchina, ma l'utilizzo della memoria di ciascun nodo è ancora intorno a 5G. Ho allegato la schermata di SPARKUI e htop.

Answer 1

1. withing arrivo filato-site.xml yarn.nodemanager.resource.memory-mb è impostato nel modo giusto. Nella mia comprensione del tuo cluster dovrebbe essere impostato su 14 GB. Questa impostazione è responsabile di comunicare a YARN la quantità di memoria che può utilizzare su questo nodo specifico
2. Se si dispone di questo set corretto e si dispone di 5 server in esecuzione su NodeManager YARN, il comando di invio lavoro è errato. Innanzitutto, --num-executors è il numero di contenitori YARN che verranno avviati per l'esecuzione nel cluster. Puoi specificare 10 contenitori con 14 GB di RAM ciascuno, ma non hai molte risorse sul tuo cluster! In secondo luogo, si specifica --master yarn-cluster, il che significa che Spark Driver verrebbe eseguito all'interno del master dell'applicazione YARN che richiederebbe un contenitore separato.
3. A mio parere mostra 3 contenitori perché su 5 nodi nel cluster ne hai solo 4 in esecuzione. YARN NodeManager + richiede di allocare 14 GB per ciascuno dei contenitori, quindi YARN prima avvia Application Master e quindi esegue il polling del NM per le risorse disponibili e vedere che può avviare solo 3 contenitori. Per quanto riguarda le dimensioni dell'heap vedi, dopo aver avviato Spark a trovare i suoi contenitori JVM e vedere i parametri del loro avvio - dovresti avere molti -Xmx flags in una singola riga - uno corretto e uno sbagliato, dovresti trovare la sua origine nei file di configurazione (Hadoop o Spark)
4. Prima di presentare domanda al cluster, avviare la scintilla-shell con le stesse impostazioni (sostituire yarn-cluster con yarn-client) e verificare come viene avviato, controllare WebUI e JVM iniziato

Answer 2

memoria (7,2 GB) che vedi in SparkUI è spark.storage.memoryFraction, che per impostazione predefinita è 0.6. Per quanto riguarda gli executor mancanti, è necessario consultare i log del gestore risorse YARN.

Answer 3

Solo perché YARN "pensa" ha 70 GB (14 GBx5), non significa che in fase di esecuzione sono disponibili 70 GB sul cluster. Potresti eseguire altri componenti Hadoop (hive, HBase, flume, solr o la tua app, ecc.) Che consumano memoria. Pertanto, la decisione di runtime YARN è basata su ciò che è attualmente disponibile e ha a disposizione solo 52 GB (3x14 GB). A proposito, i numeri GB sono approssimativi perché sono calcolati in realtà come 1024 MB per GB ... quindi vedrai i decimali.

Utilizzare nmon o superiore per vedere cos'altro utilizza la memoria su ciascun nodo.