2014-11-20 20 views
13

Ho un cluster Spark con 10 nodi, e sto ottenendo questa eccezione dopo aver utilizzato il contesto Spark per la prima volta:intermittente Timeout Eccezione usando Spark

14/11/20 11:15:13 ERROR UserGroupInformation: PriviledgedActionException as:iuberdata (auth:SIMPLE) cause:java.util.concurrent.TimeoutException: Futures timed out after [120 seconds] 
Exception in thread "main" java.lang.reflect.UndeclaredThrowableException: Unknown exception in doAs 
    at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1421) 
    at org.apache.spark.deploy.SparkHadoopUtil.runAsSparkUser(SparkHadoopUtil.scala:52) 
    at org.apache.spark.executor.CoarseGrainedExecutorBackend$.run(CoarseGrainedExecutorBackend.scala:113) 
    at org.apache.spark.executor.CoarseGrainedExecutorBackend$.main(CoarseGrainedExecutorBackend.scala:156) 
    at org.apache.spark.executor.CoarseGrainedExecutorBackend.main(CoarseGrainedExecutorBackend.scala) 
Caused by: java.security.PrivilegedActionException: java.util.concurrent.TimeoutException: Futures timed out after [120 seconds] 
    at java.security.AccessController.doPrivileged(Native Method) 
    at javax.security.auth.Subject.doAs(Subject.java:415) 
    at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1408) 
    ... 4 more 

Questa guy hanno avuto un problema simile, ma Ho già provato la sua soluzione e non ha funzionato.

La stessa eccezione si verifica anche con here ma il problema non è lo stesso qui in quanto sto utilizzando la versione 1.1.0 della scintilla sia nel master che nello slave e nel client.

Ho provato ad aumentare il timeout a 120s ma ancora non risolve il problema.

Sto caricando l'ambiente attraverso gli script e sto utilizzando context.addJar per includere il mio codice nel classpath. Questo problema è intermittente, e non ho alcuna idea su come tenere traccia del perché sta accadendo. Qualcuno ha affrontato questo problema durante la configurazione di un cluster di scintilla sapere come risolverlo?

+1

Poiché questa è la migliore risposta in google, per riferimento futuro, il timeout di rpc può verificarsi senza configurazione firewall/rete, se il lavoro si blocca per periodo configurato, ovvero 120 secondi in spark 2.0. Ho questo problema ora e alla ricerca di una soluzione diversa dall'aumento del timeout. – halil

risposta

5

Il firewall non era configurato e, in alcuni casi, non consentiva agli slave di connettersi al cluster. Questo ha generato il problema di timeout, poiché gli slave non potevano connettersi al server. Se si è di fronte a questo timeout, controllare le configurazioni del firewall.

+1

Ciao, so che è passato un po 'di tempo da questo post, ma sto affrontando lo stesso problema. Potresti fornire ulteriori suggerimenti su come verificare le impostazioni del firewall che causano questo problema? –

+1

Ciao @OlegShirokikh, dove stai distribuendo? È una distribuzione locale?Dovrai controllare se i server del tuo cluster possono accedere l'un l'altro. Qui gli slc non avevano il permesso di accedere al master e questo ha causato questo problema. – dirceusemighini

0

Ho riscontrato un problema simile e sono riuscito a risolverlo utilizzando la modalità di distribuzione cluster quando submitting the application to Spark.

(Perché anche permettendo tutto il traffico in entrata sia per il mio padrone e il singolo slave non mi ha permesso di utilizzare la modalità client deploy. Prima di loro ho dovuto cambiare gruppo di protezione predefinito del firewall) impostazioni AWS (istituiti dalla Spark EC2 scripts da Spark 1.2.0).

8

Abbiamo avuto un problema simile che era piuttosto difficile eseguire il debug e l'isolamento. Per farla breve - Spark usa Akka che è molto schizzinoso sui nomi di host FQDN che risolvono gli indirizzi IP. Anche se si specifica l'indirizzo IP in tutti i punti, non è sufficiente. La risposta here ci ha aiutato a isolare il problema.

Un test utile da eseguire è eseguito su netcat -l <port> sul master ed esegue nc -vz <host> <port> sul worker per testare la connettività. Esegui il test con un indirizzo IP e con il FQDN. È possibile ottenere il nome che Spark sta utilizzando dal messaggio WARN dal frammento di registro qui sotto. Per noi era host032s4.staging.companynameremoved.info. Il test dell'indirizzo IP per noi è stato superato e il test FQDN non è riuscito poiché il nostro DNS non è stato configurato correttamente.

INFO 2015-07-24 10:33:45 Remoting: Remoting started; listening on addresses :[akka.tcp://[email protected]:35455] 
INFO 2015-07-24 10:33:45 Remoting: Remoting now listens on addresses: [akka.tcp://[email protected]:35455] 
INFO 2015-07-24 10:33:45 org.apache.spark.util.Utils: Successfully started service 'driverPropsFetcher' on port 35455. 
WARN 2015-07-24 10:33:45 Remoting: Tried to associate with unreachable remote address [akka.tcp://[email protected]:50855]. Address is now gated for 60000 ms, all messages to this address will be delivered to dead letters. 
ERROR 2015-07-24 10:34:15 org.apache.hadoop.security.UserGroupInformation: PriviledgedActionException as:skumar cause:java.util.concurrent.TimeoutException: Futures timed out after [30 seconds] 

Un'altra cosa che abbiamo dovuto fare era di specificare le spark.driver.host e spark.driver.port immobili a presentare la scintilla script. Questo perché avevamo macchine con due indirizzi IP e il nome di dominio completo risolto all'indirizzo IP sbagliato.

Assicurarsi che la rete e le voci DNS siano corrette !!

Problemi correlati