在bdutil
,減少時隙數是機器和環境變量CORES_PER_REDUCE_TASK
上芯的總數量的函數,內configure_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
看到默認是每減少插槽2芯:
CORES_PER_REDUCE_TASK=2.0
最佳設置可能會因工作量,但大多數情況下,這些默認設置應該罰款。正如您所鏈接的線索中所提到的,您可以遵循的一般方法是在您的實際工作量中設置computation-layer.parallelism
大約等於您擁有的減少插槽的數量。如果您使用的是默認設置,只需將您擁有的機器數量,乘以每機器核心數量,除以2即可知道插槽數量。如果您想要每臺機器減少1個插槽,請設置CORES_PER_REDUCE_TASK
等於每臺機器的核心數。
我說大概是因爲圍繞設置作業中減少任務的數量還有其他高級設置,包括「推測性執行」設置;一個典型的建議是將你的減少並行性設置得少一點,或許是減少插槽數量的0.95倍;這允許一些空間用於失敗或卡住的減少任務。
此外,當您將並行性增加到減少插槽數量之外時,您可能已經看到了一些性能更快的情況,儘管由於需要執行多個「波浪」而導致預期減速,這是由於不同減速任務。在某些高變量的工作負荷中,第二個「波浪」可以與第一個「波浪」的最慢任務同時有效地運行;之前的Hadoop wiki給出了將減少的並行度設置爲可用縮減時隙數量的0.95或1.75倍的經驗法則。這裏有一些關於該主題的further discussion;那裏的海報正確地指出,這些只適用於單租戶集羣。
如果您實際上想與大量用戶同時共享大型集羣,這些經驗法則不適用,因爲您應該根據工作負載的大小和特徵純粹分配並行性,因爲您不會希望佔用100%的羣集資源。但是,雲環境中推薦的方法的確擁有多個較小的單租戶羣集,因爲您可以專門針對所需的工作負載調整每個羣集,並且無需擔心許多不同用途之間的資源打包問題案例。