Configuración
| Configuración | Valor por defecto | Sentido |
|---|---|---|
spark.driver.cores |
1 | Número de núcleos que se usarán para el proceso del controlador, solo en el modo de clúster. El número de núcleos del proceso del controlador en el modo de clúster , porque am y el controlador están realmente integrados en el modo cambiado, por lo que también es el número de núcleos de am. |
spark.yarn.am.cores |
1 | Número de núcleos que se utilizarán para el maestro de aplicaciones YARN en modo cliente. En modo de clúster, utilizar spark.driver.coresen su lugar. En modo cliente de hilo, el número de núcleos de am, driver y am se separan en este modo, por lo que no existe tal número de driver núcleos en este momento Un conceptual |
Código fuente
private val amCores = if (isClusterMode) {
sparkConf.get(DRIVER_CORES)
} else {
sparkConf.get(AM_CORES)
}
Para obtener más información, consulte yarn.Client.scala # L87 , que se utiliza para leer los parámetros y establecer el número de núcleo correspondiente de 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 obtener más detalles, consulte yarn.Client.scala # L251 . Aquí se encapsula en un mensaje de solicitud y se envía a Yarn. Después de una serie de operaciones, finalmente se entrega a NodeManager para generar un ApplicationMaster Container, que es una JVM proceso.
análisis
Sabemos que cuando jugamos JVM, podemos establecer varios parámetros de memoria, como Xmx, Xss, etc., y también podemos establecer el número de subprocesos GC, como -XX: ParallelGCThreads, etc. Parece que no hay ningún configuración de cuántos parámetros de subproceso utiliza la JVM. Consulte,
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}
Entonces, ¿de qué sirve establecer este número de auditoría? ¿Mejorar la concurrencia de ApplicationMaster? ¿PERO CÓMO?
Comparado
En comparación, spark.executor.coreses mucho más fácil de entender. Este parámetro se usa para establecer el número de núcleos ejecutores. Es un valor simple. Por ejemplo, si lo configuramos en 4, el controlador asigna tareas de acuerdo con el número actual de núcleos inactivos de los ejecutores, y asigna inactivo. El número de núcleos es -1, y el mensaje de que la tarea se completó es +1, que es libre para que el controlador asigne la tarea, y eso es todo.
Pero mirando el código fuente de ApplicationMaster, no existe tal tipo de operación controlada.
un error
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
El error es en el sentido de que cuando ApplicationMaster, como cliente, solicita al ResourceManager que asigne un Contenedor, descubre que el ResourceManager ya no lo reconoce y tiene amnesia. Si ApplicationMaster no se anuló del ResourceManager, debe haber pasado demasiado tiempo sin contacto y haber roto la relación.
Mira el código fuente de 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)
}
}
.....
El código es muy simple. ApplicationMaster iniciará un hilo aquí. Si no hay excepción, se ejecutará periódicamente (spark.yarn.scheduler.heartbeat.interval-ms 3 segundos) allocator.allocateResources(). Si algún ejecutor cuelga y no es suficiente para el número que solicitamos, solo invente algunas aplicaciones y continúe ejecutando este código si no hay escasez. Se estima que es equivalente al latido entre ApplicationMaster y ResourceManager.
Hablando de esto, miramos hacia atrás en los dos parámetros que son un poco llamativos, aunque la cantidad de subprocesos en java no es directamente equivalente a la cantidad de subprocesos en la CPU, esencialmente participa en la competencia del segmento de tiempo de la CPU. La comprensión de la cantidad de núcleos a nivel de Yarn es relativamente simple. Primero obtenemos la cantidad de CPU * la cantidad de núcleos lógicos de una sola CPU para obtener la cantidad total de subprocesos en una determinada máquina, y luego NodeManager completa la asignación de Contenedores en función de este valor, incluyéndonos a nosotros Para ApplicationMaster y Spark Executor, si se asigna uno, se resta el número de núcleos de este Contenedor. Cuanto mayor sea el número de núcleos de un solo Contenedor, menor será el número total de Contenedores participantes en competencia de CPU. Para el modo de clúster, Driver y ApplicationMaster existen en un proceso separado. Los subprocesos están más ocupados que en el modo de cliente. Cuando se encuentran problemas similares a GC, es muy probable que nosotros y el subproceso de latido de ResourceManager no podamos obtener oportunidades de ejecución, superando el tiempo que piensa. Estoy perdido el contacto. Entonces spark.driver.coresviene la importancia de nuestra configuración . Si aumentamos este valor, es posible reducir la asignación de otros Contenedores en el nodo de la computadora, y los recursos físicos no serán tan ajustados, y la probabilidad de ocurrencia de este escenario se reducirá. respectivamente.
para resumir
spark.driver.coresEn un entorno de producción, se puede ajustar a un tamaño mayor dentro de un rango razonable, y debería ser útil para mejorar su capacidad de procesamiento ejecutándose en otros. . De lo contrario, no puedo pensar en el uso de estos dos parámetros. .
posdata
Consulté a los colegas de hilo en el siguiente grupo y dije que el papel de estos parámetros debería ser más obvio y claro después de que se habilita el cgroup.