Optimización de parámetros de hilo (versión Fair Scheduler)

HILO

Desde hadoop2.0, podemos usar apache yarn para administrar los recursos del clúster. Yarn puede dividir y aislar recursos (memoria, CPU) en forma de contenedores. YARN administrará los recursos informáticos disponibles de todas las máquinas del clúster. En función de estos recursos, YARN programará las solicitudes de recursos de las aplicaciones (como MapReduce), y luego YARN asignará los contenedores para proporcionar capacidades de procesamiento a cada aplicación. El contenedor es YARN La unidad básica de potencia de procesamiento es el paquete (contenedor) de memoria, CPU, etc.

ResourceManager: en lo sucesivo, RM. El módulo de control central de YARN es responsable de la planificación unificada del uso de recursos.
NodeManager: en lo sucesivo denominado NM. El módulo de nodo de recursos de YARN es responsable de iniciar el contenedor de gestión.
ApplicationMaster: en lo sucesivo, AM. Cada aplicación en YARN iniciará un AM, que es responsable de solicitar recursos de RM, solicitar a NM que inicie el contenedor y decirle al contenedor qué hacer.
Contenedor: contenedor de recursos. Todas las aplicaciones de YARN se ejecutan en el contenedor. AM también se ejecuta en el contenedor, pero RM solicita el contenedor AM.

Después de comprender los conceptos básicos anteriores, puede comenzar a optimizar la configuración del clúster.

Configurar los recursos registrados de NM

<property>
<name>yarn.nodemanager.resource.cpu-vcores</name>
<value>30</value>
<discription>每个nodemanager可分配的cpu总核数</discription>
</property>
<property>
<name>yarn.nodemanager.resource.memory-mb</name>
<value>122880</value>
<discription>每个nodemanager可分配的内存总量</discription>
</property>

Sugerencias de optimización:
1. El número de núcleos de CPU = el número de núcleos lógicos-el número de otras aplicaciones (datanode? Work? Zk? Etc.)

cat /proc/cpuinfo | grep "processor" | wc -l

Puede verificar la cantidad de núcleos lógicos en el clúster.
2. Se recomienda que la memoria sea un múltiplo entero de la CPU, y se reserva suficiente memoria para el sistema

Configuración de ApplicationMaster

<property>
<name>yarn.app.mapreduce.am.resource.cpu-vcores</name>
<value>1</value>
</property>
<property>
<name>yarn.app.mapreduce.am.resource.mb</name>
<value>4096</value>
<discription>ApplicationMaster的占用的内存大小</discription>
</property>


Sugerencia de optimización
1. La proporción de CPU y memoria es consistente con la proporción de asignación de nm

Optimización de la configuración de contenedores

<property>
<name>yarn.scheduler.maximum-allocation-mb</name>
<value>16384</value>
<discription>单个任务可申请最大内存,默认8192MB</discription>
</property>
<property>
<name>yarn.scheduler.maximum-allocation-vcores</name>
<value>4</value>
<discription>单个任务可申请的最多虚拟CPU个数</discription>
</property>
<property>
<name>yarn.scheduler.minimum-allocation-vcores</name>
<value>1</value>
<discription>单个任务可申请的最小虚拟CPU个数</discription>
</property>
<property>
<name>yarn.scheduler.minimum-allocation-mb</name>
<value>4096</value>
<discription>container最小可申请的内存</discription>
</property>

Sugerencia de optimización
1. En el programador, muchas partes del cálculo de recursos se convertirán en N veces el valor mínimo para el cálculo. Por lo tanto, al configurar la memoria asignable y otros recursos, es mejor ser solo un múltiplo de este valor mínimo.
2. La relación cpu / memoria sigue siendo la misma
. 3. YARN usa la supervisión de subprocesos para determinar si la tarea está sobreutilizando la memoria. Cantidad , mátalo directamente. Debido a la falta de flexibilidad en el control de la memoria por parte de Cgroups (es decir, la tarea no puede exceder el límite superior de memoria en ningún momento, si lo excede, se eliminará directamente o se informará como OOM), y el proceso de Java se duplicará la memoria en el momento de la creación, y luego cae al valor normal. En este caso, el método de monitoreo de subprocesos es más flexible (cuando se encuentra que la memoria del árbol de procesos instantáneamente duplica y excede el valor establecido, puede ser se considera un fenómeno normal y la tarea no se eliminará), por lo que YARN no proporciona un mecanismo de aislamiento de memoria de Cgroups para controlar el contenedor.

mapreduce la configuración de los parámetros

<property>
<name>mapreduce.map.memory.mb</name>
<value>4096</value>
<discription>map的内存大小</discription>
</property>
<property>
<name>mapreduce.map.java.opts</name>
<value>-Xmx3072M</value>
<discription>用户设定的map/reduce阶段申请的container的JVM参数。最大堆设定要比申请的内存少一些,用于JVM的非堆部分使用0.80-0.85建议</discription>
</property>
<property>
<name>mapreduce.reduce.memory.mb</name>
<value>8192</value>
</property>
<property>
<name>mapreduce.reduce.java.opts</name>
<value>-Xmx6144M</value>
</property>


Referencia de optimización
1. Si el clúster utiliza principalmente mr para el cálculo, se recomienda que la memoria del mapa y el mínimo de la CPU y el contenedor sean iguales.
2. ¿Cuántos mapas se pueden ejecutar en un contenedor como máximo? yarn.scheduler.maximum-deployment-mb / mapreduce.map.memory.mb = 4

La pregunta es
¿cómo controlar la cantidad de contenedores en un administrador de nodos?

<property>
<name>yarn.scheduler.fair.assignmultiple</name>
<value>true</value>
<discription>是否允许NodeManager一次分配多个容器</discription>
</property>
<property>
<name>yarn.scheduler.fair.max.assign</name>
<value>20</value>
<discription>如果允许一次分配多个,一次最多可分配多少个,这里按照一个最小分配yarn.scheduler.minimum-allocation-mb4gb来计算总共内存120/4=30给20即可</discription>
</property>

Ejemplo de configuración de Fari Scheduler

24 nodos, 120 GB de memoria por nodo, 30 CPU lógicas

<?xml version="1.0"?>
<allocations>
<queue name="mapreduce">
<minResources>368640 mb,90 vcores</minResources><!--3 nodes-->
<maxResources>2334720 mb,570 vcores</maxResources><!--19 nodes-->
<maxRunningApps>70</maxRunningApps>
<weight>5</weight>
<queue name="vipquery">
<minResources>122880 mb,30 vcores</minResources><!--1 nodes-->
<maxResources>1966080 mb,480 vcores</maxResources><!--16 nodes-->
<maxRunningApps>20</maxRunningApps>
<weight>8</weight>
</queue>
<queue name="hive">
<minResources>122880 mb,30 vcores</minResources><!--1 nodes-->
<maxResources>1966080 mb,480 vcores</maxResources><!--16 nodes-->
<maxRunningApps>20</maxRunningApps>
<weight>7</weight>
</queue>
<queue name="hadoop">
<minResources>122880 mb,30 vcores</minResources><!--1 nodes-->
<maxResources>1966080 mb,480 vcores</maxResources><!--16 nodes-->
<maxRunningApps>30</maxRunningApps>
<weight>6</weight>
</queue>
</queue>
<queue name="default">
<minResources>122880 mb,30 vcores</minResources><!--1 nodes-->
<maxResources>614400 mb,150 vcores</maxResources><!--5 nodes-->
<maxRunningApps>20</maxRunningApps>
<weight>1</weight>
</queue>
</allocations>

para resumir

El hilo se puede controlar de forma eficaz mediante una configuración razonable, la apropiación de recursos y problemas de máxima concurrencia.

Supongo que te gusta

Origin blog.csdn.net/qq_32445015/article/details/109894650
Recomendado
Clasificación