在 bdutil ，reduce slot的数量是机器上内核总数和环境变量的函数 CORES_PER_REDUCE_TASK ，应用于configure\u hadoop.sh中：

export NUM_CORES="$(grep -c processor /proc/cpuinfo)"
export MAP_SLOTS=$(python -c "print int(${NUM_CORES} // \
    ${CORES_PER_MAP_TASK})")
export REDUCE_SLOTS=$(python -c "print int(${NUM_CORES} // \
    ${CORES_PER_REDUCE_TASK})")

<...>

# MapReduce v2 (and YARN) Configuration

if [[ -x configure_mrv2_mem.py ]]; then
  TEMP_ENV_FILE=$(mktemp /tmp/mrv2_XXX_tmp_env.sh)
  ./configure_mrv2_mem.py \
      --output_file ${TEMP_ENV_FILE} \
      --total_memory ${TOTAL_MEM} \
      --available_memory_ratio ${NODEMANAGER_MEMORY_FRACTION} \
      --total_cores ${NUM_CORES} \
      --cores_per_map ${CORES_PER_MAP_TASK} \
      --cores_per_reduce ${CORES_PER_REDUCE_TASK} \
      --cores_per_app_master ${CORES_PER_APP_MASTER}
  source ${TEMP_ENV_FILE}
  # Leave TMP_ENV_FILE around for debugging purposes.
fi

你可以看到 hadoop2_env.sh 默认值为每个reduce插槽2个内核：

CORES_PER_REDUCE_TASK=2.0

最佳设置可能因工作负载而异，但在大多数情况下，这些默认设置应该可以。正如您链接的线程中提到的，您可以遵循的一般方法是在实际工作负载中设置 computation-layer.parallelism 大约等于您拥有的reduce插槽的数量。如果您使用的是默认设置，只需将您拥有的机器数乘以每台机器的核心数除以2即可知道插槽数。如果您希望每台机器减少1个插槽，请设置 CORES_PER_REDUCE_TASK 等于每台机器的芯数。
我之所以说大约是因为在设置作业中reduce任务的数量时有其他高级设置，包括“推测执行”设置；一个典型的建议是将reduce并行度设置为稍微少一点，可能是reduce插槽数量的0.95倍；这为失败或卡住的reduce任务提供了一点空间。
此外，当您将并行度增加到reduce槽的数量之外时，您可能已经看到了一些性能更快的情况，尽管由于需要执行多个“wave”而导致预期的速度减慢，这是由于不同reduce任务的速度差异很大。在某些变化较大的工作负载中，第二个“wave”可以有效地与第一个“wave”中最慢的任务同时运行；以前hadoopwiki提供了一个经验法则，将reduce并行度设置为可用reduce插槽数量的0.95或1.75倍。下面是关于这个主题的进一步讨论；那里的海报正确地指出，这些仅适用于单租户集群。
如果您真的想与许多用户同时共享一个大型集群，那么这些经验法则就不适用了，因为您应该纯粹根据工作负载的大小和特征来分配并行性，因为您不想占用100%的集群资源。然而，在云环境中，推荐的方法确实是拥有多个较小的单租户集群，因为这样您就可以针对所需的工作负载专门调整每个集群，而无需担心大量不同用例之间的资源打包问题。