所以我有一个cloudera集群，有7个工作节点。
30gb内存
4个VCPU
以下是我的一些配置，我发现这些配置对调整集群的性能很重要（来自google）。我在跑步： yarn.nodemanager.resource.cpu-vcores => 4 yarn.nodemanager.resource.memory-mb =>17gb（其余为操作系统和其他进程保留） mapreduce.map.memory.mb =>2gb mapreduce.reduce.memory.mb =>2gb
跑步 nproc =>4（可用处理单元数）
现在我关心的是，当我看着 ResourceManager ，我看到可用内存为 119 GB 这很好。但当我跑了一个沉重的 sqoop 作业和我的群集正处于它仅使用的峰值 ~59 GB 回忆，离开 ~60 GB 内存未使用。
我所看到的一种解决未使用内存问题的方法正在增加 map|reduce.memory 到4 gb，这样每个节点最多可以使用16 gb。
另一种方法是增加容器的数量，我不知道如何增加。
4个核心x 7个节点=28个可能的容器。3被其他进程使用，目前只有5个进程可用于sqoop作业。
在这种情况下，正确的配置应该是什么来提高集群性能。我可以增加容器的数量吗，比如说每个核心2个容器。有人推荐吗？
如果您对集群配置有任何帮助或建议，我们将不胜感激。谢谢。
1条答案
按热度按时间9q78igpj1#
如果您的输入数据是在26个分裂，Yarn将创建26个Map器来处理这些分裂平行。
如果您有7个节点，其中有26个拆分的2 gbMap器，则重新分区应类似于：
节点1:4个Map器=>8 gb
节点2:4个Map器=>8 gb
节点3:4个Map器=>8 gb
节点4:4个Map器=>8 gb
节点5:4个Map器=>8 gb
节点6:3个Map器=>6 gb
节点7:3个Map器=>6 gb
总计：26个Map器=>52 gb
因此，如果所有Map程序同时运行，则map reduce作业中使用的总内存将为26x2=52 gb。如果您通过reducer（s）和applicationmaster容器添加内存用户，您可能会在某个时候达到59GB，如您所说。。
如果这是你正在目睹的行为，而这项工作在那26名Map绘制者之后完成，那么就没有什么错。您只需要60 gb左右就可以通过将任务分布到所有节点来完成任务，而无需等待容器插槽释放自己。另一个免费的60GB只是在等待，因为你不需要它们。仅仅为了使用所有内存而增加堆大小并不一定会提高性能。
编辑时间：
但是，如果仍有许多Map器等待调度，那么可能是因为您的安装配置为使用vCore计算容器分配。这不是apache hadoop中的默认值，但可以配置为：
yarn.scheduler.capacity.resource-calculator：用于比较计划程序中的资源的resourcecalculator实现。默认值，即org.apache.hadoop.yarn.util.resource.DefaultResourceCalculator仅使用内存，而dominantresourcecalculator使用主资源来比较多维资源，如内存、cpu等。需要java resourcecalculator类名。因为你定义了
yarn.nodemanager.resource.cpu-vcores由于默认情况下每个Map器使用1个vcore，因此一次只能为每个节点运行4个Map器。那样的话，你的价值可以翻倍
yarn.nodemanager.resource.cpu-vcores到8。它只是一个任意值，它应该是Map器数量的两倍。