Configuração
| Configuração | Valor padrão | Significado |
|---|---|---|
spark.driver.cores |
1 | Número de núcleos a serem usados para o processo do driver, apenas no modo cluster. O número de núcleos do processo do driver no modo cluster , porque am e driver estão realmente integrados no modo alterado, então é também o número de núcleos de am. |
spark.yarn.am.cores |
1 | Número de núcleos a serem usados para o YARN Application Master no modo cliente. No modo cluster, use em spark.driver.coresvez disso. No modo cliente yarn, o número de núcleos de am, driver e am são separados neste modo, portanto, não há tal número de driver núcleos neste momento Um conceitual |
Código fonte
private val amCores = if (isClusterMode) {
sparkConf.get(DRIVER_CORES)
} else {
sparkConf.get(AM_CORES)
}
Para obter detalhes, consulte yarn.Client.scala # L87 , que é usado para ler os parâmetros e definir o número do núcleo correspondente do ApplicationMaster.
val capability = Records.newRecord(classOf[Resource])
capability.setMemory(amMemory + amMemoryOverhead)
capability.setVirtualCores(amCores)
sparkConf.get(AM_NODE_LABEL_EXPRESSION) match {
case Some(expr) =>
try {
val amRequest = Records.newRecord(classOf[ResourceRequest])
amRequest.setResourceName(ResourceRequest.ANY)
amRequest.setPriority(Priority.newInstance(0))
amRequest.setCapability(capability)
...
Para obter detalhes, consulte yarn.Client.scala # L251 . Aqui, ele é encapsulado na mensagem de solicitação am e enviado ao Yarn. Após uma série de operações, é finalmente entregue ao NodeManager para gerar um contêiner ApplicationMaster, que é um JVM processar.
análise
Sabemos que quando jogamos JVM, podemos definir vários parâmetros de memória, como Xmx, Xss, etc., e também podemos definir o número de threads de GC, como -XX: ParallelGCThreads, etc. configuração de quantos parâmetros de Thread a JVM usa. Veja,
java -XX:+PrintFlagsInitial | grep "Thread" | grep -v "bool"
intx CompilerThreadPriority = -1 {product}
intx CompilerThreadStackSize = 0 {pd product}
uintx ConcGCThreads = 0 {product}
intx DefaultThreadPriority = -1 {product}
uintx G1ConcRefinementThreads = 0 {product}
uintx HeapSizePerGCThread = 87241520 {product}
uintx NewSizeThreadIncrease = 5320 {pd product}
uintx ParallelGCThreads = 0 {product}
intx ThreadPriorityPolicy = 0 {product}
uintx ThreadSafetyMargin = 52428800 {product}
intx ThreadStackSize = 1024 {pd product}
intx VMThreadPriority = -1 {product}
intx VMThreadStackSize = 1024 {pd product}
Então, de que adianta definir esse número de auditoria? Melhorar a simultaneidade do ApplicationMaster? MAS COMO?
Comparado
Em comparação, spark.executor.coresé muito mais fácil de entender. Este parâmetro é usado para definir o número de núcleos do executor. É um valor simples. Por exemplo, se definirmos para 4, o driver aloca tarefas de acordo com o número atual de núcleos ociosos dos executores, e aloca ocioso.O número de núcleos é -1, e a mensagem de que a tarefa foi concluída é +1, que é livre para o driver alocar a tarefa, e é isso.
Mas olhando para o código-fonte do ApplicationMaster, não existe esse tipo de operação controlada.
um erro
18/02/04 06:27:52 ERROR yarn.ApplicationMaster: Exception from Reporter thread.
org.apache.hadoop.yarn.exceptions.ApplicationAttemptNotFoundException: Application attempt appattempt_1515478669260_917050_000001 doesn't exist in ApplicationMasterService cache.
at org.apache.hadoop.yarn.server.resourcemanager.ApplicationMasterService.allocate(ApplicationMasterService.java:439)
at org.apache.hadoop.yarn.api.impl.pb.service.ApplicationMasterProtocolPBServiceImpl.allocate(ApplicationMasterProtocolPBServiceImpl.java:60)
at org.apache.hadoop.yarn.proto.ApplicationMasterProtocol$ApplicationMasterProtocolService$2.callBlockingMethod(ApplicationMasterProtocol.java:99)
at org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:616)
at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:982)
at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2049)
at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2045)
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:1698)
at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2045)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at org.apache.hadoop.yarn.ipc.RPCUtil.instantiateException(RPCUtil.java:53)
at org.apache.hadoop.yarn.ipc.RPCUtil.unwrapAndThrowException(RPCUtil.java:101)
at org.apache.hadoop.yarn.api.impl.pb.client.ApplicationMasterProtocolPBClientImpl.allocate(ApplicationMasterProtocolPBClientImpl.java:79)
at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:191)
at org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:102)
at com.sun.proxy.$Proxy24.allocate(Unknown Source)
at org.apache.hadoop.yarn.client.api.impl.AMRMClientImpl.allocate(AMRMClientImpl.java:277)
at org.apache.spark.deploy.yarn.YarnAllocator.allocateResources(YarnAllocator.scala:260)
at org.apache.spark.deploy.yarn.ApplicationMaster$$anon$1.run(ApplicationMaster.scala:458)
Caused by: org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.yarn.exceptions.ApplicationAttemptNotFoundException): Application attempt appattempt_1515478669260_917050_000001 doesn't exist in ApplicationMasterService cache.
at org.apache.hadoop.yarn.server.resourcemanager.ApplicationMasterService.allocate(ApplicationMasterService.java:439)
at org.apache.hadoop.yarn.api.impl.pb.service.ApplicationMasterProtocolPBServiceImpl.allocate(ApplicationMasterProtocolPBServiceImpl.java:60)
at org.apache.hadoop.yarn.proto.ApplicationMasterProtocol$ApplicationMasterProtocolService$2.callBlockingMethod(ApplicationMasterProtocol.java:99)
at org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:616)
at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:982)
at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2049)
at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2045)
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:1698)
at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2045)
at org.apache.hadoop.ipc.Client.call(Client.java:1475)
at org.apache.hadoop.ipc.Client.call(Client.java:1412)
at org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:229)
at com.sun.proxy.$Proxy23.allocate(Unknown Source)
at org.apache.hadoop.yarn.api.impl.pb.client.ApplicationMasterProtocolPBClientImpl.allocate(ApplicationMasterProtocolPBClientImpl.java:77)
... 9 more
18/02/04 06:27:52 INFO yarn.ApplicationMaster: Final app status: FAILED, exitCode: 12, (reason: Application attempt appattempt_1515478669260_917050_000001 doesn't exist in ApplicationMasterService cache.
at org.apache.hadoop.yarn.server.resourcemanager.ApplicationMasterService.allocate(ApplicationMasterService.java:439)
at org.apache.hadoop.yarn.api.impl.pb.service.ApplicationMasterProtocolPBServiceImpl.allocate(ApplicationMasterProtocolPBServiceImpl.java:60)
at org.apache.hadoop.yarn.proto.ApplicationMasterProtocol$ApplicationMasterProtocolService$2.callBlockingMethod(ApplicationMasterProtocol.java:99)
at org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:616)
at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:982)
at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2049)
at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2045)
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:1698)
at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2045)
)
18/02/04 06:27:52 INFO streaming.StreamingContext: Invoking stop(stopGracefully=true) from shutdown hook
O erro é que quando o ApplicationMaster, como cliente, solicita ao ResourceManager que aloque um Container, ele descobre que o mesmo não é mais reconhecido pelo ResourceManager e está com amnésia? Se o ApplicationMaster não cancelou o registro do ResourceManager, deve ter ficado muito tempo sem contato e o relacionamento foi rompido.
Veja o código-fonte do ApplicationMaster
private def launchReporterThread(): Thread = {
// The number of failures in a row until Reporter thread give up
val reporterMaxFailures = sparkConf.get(MAX_REPORTER_THREAD_FAILURES)
val t = new Thread {
override def run() {
var failureCount = 0
while (!finished) {
try {
if (allocator.getNumExecutorsFailed >= maxNumExecutorFailures) {
finish(FinalApplicationStatus.FAILED,
ApplicationMaster.EXIT_MAX_EXECUTOR_FAILURES,
s"Max number of executor failures ($maxNumExecutorFailures) reached")
} else {
logDebug("Sending progress")
allocator.allocateResources()
}
failureCount = 0
} catch {
case i: InterruptedException =>
case e: Throwable =>
failureCount += 1
// this exception was introduced in hadoop 2.4 and this code would not compile
// with earlier versions if we refer it directly.
if ("org.apache.hadoop.yarn.exceptions.ApplicationAttemptNotFoundException" ==
e.getClass().getName()) {
logError("Exception from Reporter thread.", e)
finish(FinalApplicationStatus.FAILED, ApplicationMaster.EXIT_REPORTER_FAILURE,
e.getMessage)
} else if (!NonFatal(e) || failureCount >= reporterMaxFailures) {
finish(FinalApplicationStatus.FAILED,
ApplicationMaster.EXIT_REPORTER_FAILURE, "Exception was thrown " +
s"$failureCount time(s) from Reporter thread.")
} else {
logWarning(s"Reporter thread fails $failureCount time(s) in a row.", e)
}
}
.....
O código é muito simples. O ApplicationMaster iniciará um thread aqui. Se não houver exceção, ele será executado periodicamente (spark.yarn.scheduler.heartbeat.interval-ms 3 segundos) allocator.allocateResources(). Se algum executor travar e não for suficiente para o número que solicitamos, basta criar alguns aplicativos e continuar a executar este código se não houver falta. Estima-se que seja equivalente à pulsação entre ApplicationMaster e ResourceManager.
Falando nisso, observamos que os dois parâmetros são um pouco atraentes, embora o número de threads em java não seja diretamente equivalente ao número de threads na CPU, ele essencialmente participa da competição da fração de tempo da CPU. A compreensão do número de núcleos no nível Yarn é relativamente simples. Primeiro obtemos o número de CPUs * o número de núcleos lógicos de uma única CPU para obter o número total de threads em uma determinada máquina e, em seguida, NodeManager conclui a alocação de contêineres com base neste valor, incluindo nós. Para o ApplicationMaster e o Spark Executor, se um for alocado, o número de núcleos desse contêiner é subtraído. Quanto maior o número de núcleos de um único contêiner, menor será o número total de contêineres participantes na competição de CPU. Para o modo cluster, Driver e ApplicationMaster existem em um processo separado. Os threads estão mais ocupados do que no modo cliente. Ao encontrar problemas semelhantes ao GC, é muito provável que nós e o thread de pulsação do ResourceManager não possamos obter oportunidades de execução, excedendo o hora em que pensa. perdi o contato Então spark.driver.coresvem a significância da nossa configuração . Se aumentarmos este valor, é possível reduzir a alocação de outros Containers no nó do computador, e os recursos físicos não serão tão apertados, e a probabilidade de ocorrência deste cenário será reduzida adequadamente.
Resumindo
spark.driver.coresEm um ambiente de produção, ele pode ser ajustado para um tamanho maior dentro de uma faixa razoável e deve ser útil para melhorar sua capacidade de processamento executando em outros. . Caso contrário, não consigo pensar no uso desses dois parâmetros. .
pós-escrito
Consultei os colegas do yarn no próximo grupo e disse que o papel desses parâmetros deveria ser mais óbvio e claro depois que o cgroup for habilitado.