yarn中container、mr内存的配置,控制container个数

  最近项目在用kylin,在搭建开发环境和测试环境后,然后在kylin上建cube,kylin建cube实际就是调用集群的MR跑任务(也可以调用spark作为引擎),在数据量小或者维度(kylin里面的一个概念)少的时候没问题,后来数据量大或维度多了,就经常出现OOM的问题。
  其实一开始就知道是并行度过高的问题,也尝试过在kylin里面调试,但并没有用。后来通过jps查看yarnchild个数,再到了解containers概念,再到nodemanager资源配置,最后终于知道问题点就在控制containers个数,然后就开始研究到这几个配置项了,这几个配置项影响着每个计算节点上container的个数(Vcore也会影响,本文先不说,就先当vcore是充足的),毕竟这段时间看日志报的都是OOM。


一、nodemanager/ratio

 yarn.nodemanager.resource.memory-mb

  • 集群中某个计算节点分配给nodemanager的最大可用内存,这个最大可用内存不是该节点最大内存,而是该节点最大内存划分出来的给nodemanager使用的内存,
  • 该配置项在集群启动后,无法动态改变。
  • 比如一个节点最大内存为128G,计划给nodemanager80%的内存资源,则设置yarn.nodemanager.resource.memory-mb为103G,其余25G用作该节点其他资源调配,保证这个计算节点正常运行。
  • 这个配置默认是8G,集群并不会主动检测这个可用内存,如果节点内存资源少于8G,需要将这个配置项设置成实际的资源,如果不配置,集群会按照8G的资源调配,这样会导致可能同时创建过多的container而OOM。
  • 我们这次的主要问题就是这里,因为开
### 控制 YARNContainer 大小和数量的关键参数 在 Hadoop YARN 中,`Container` 是计算资源的抽象单位,其大小和数量由多个配置参数共同决定。以下是影响 `Container` 大小和数量的主要参数及其作用: #### 1. 节点管理器资源配置 - **`yarn.nodemanager.resource.memory-mb`**: 定义单个节点可用的最大物理内存总量(以 MB 为单位)。这是每个节点能够分配给所有 `Container` 的总内存上限[^2]。 - **`yarn.nodemanager.resource.cpu-vcores`**: 定义单个节点可用的虚拟 CPU 核心数。这是每个节点能够分配给所有 `Container` 的总 CPU 上限[^1]。 这些参数决定了整个节点上的资源池大小,从而间接限制了该节点上可能运行的 `Container` 数量。 --- #### 2. 资源调度器配置 - **`yarn.scheduler.minimum-allocation-mb`**: 单个 `Container` 可申请的最小内存资源(以 MB 为单位)。如果应用程序请求的内存低于此值,则会按照此值进行分配。 - **`yarn.scheduler.maximum-allocation-mb`**: 单个 `Container` 可申请的最大内存资源(以 MB 为单位)。这防止了某个应用占用过多内存资源。 对于 CPU 配置: - **`yarn.scheduler.minimum-allocation-vcores`**: 单个 `Container` 可申请的最小 CPU 核心数。默认通常设置为 1。 - **`yarn.scheduler.maximum-allocation-vcores`**: 单个 `Container` 可申请的最大 CPU 核心数。这同样用于限制单个 `Container` 对 CPU 资源的需求。 通过调整上述参数,可以精确控制每个 `Container` 所能使用的资源范围。 --- #### 3. 应用程序级别的资源配置 - **`mapreduce.map.memory.mb` 和 `mapreduce.reduce.memory.mb`**: Map 和 Reduce 任务所需的内存大小。这两个参数直接影响到 MR 作业提交时所创建的 `Container` 的大小。 - **`mapreduce.map.cpu.vcores` 和 `mapreduce.reduce.cpu.vcores`**: Map 和 Reduce 任务所需的核心数。它们定义了每个任务对 CPU 资源的具体需求。 当应用程序向 YARN 提交任务时,它会基于以上两个参数请求特定大小的 `Container`。 --- #### 计算公式与逻辑关系 假设某节点上有以下配置: - `yarn.nodemanager.resource.memory-mb = 64GB` - `yarn.scheduler.minimum-allocation-mb = 2048MB` 那么理论上,在不考虑其他约束的情况下,该节点最多可以启动 \( \frac{64}{2} = 32 \) 个 `Container`。然而实际数量还会受到 `CPU vCores` 的限制以及具体任务需求的影响。 --- ```python # 假设我们有一个集群节点,尝试计算最大Container数量 node_memory_mb = 64 * 1024 # 总内存64GB转换成MB min_allocation_mb = 2048 # 每个Container最少需要2GB max_container_count = node_memory_mb / min_allocation_mb print(f"理论最大Container数量: {int(max_container_count)}") ``` --- ### 经验推荐值 根据硬件条件的不同,建议如下经验配置: | 总内存/节点 | 推荐最小Container大小 | |-------------|-----------------------| | 少于 4GB | 256MB | | 4GB 至 8GB | 512MB | | 8GB 至 24GB | 1024MB | | 超过 24GB | 2048MB | 这种配置方式有助于平衡资源利用率和任务执行效率。 ---
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值