2015-04-01 42 views
1

我正在Google Compute Engine的Hadoop集羣上測試一些MapReduce作業的縮放比例,並發現一些意外的結果。簡而言之,我被告知這種行爲可能是由Hadoop集羣中每個工作節點擁有多個reducer插槽來解釋的。GCE Hadoop工作節點上的減速機插槽數量是多少?

有人可以確認GCE Hadoop集羣上MapReduce作業的每個工作節點(worker VM)的reducer插槽數量嗎?我正在使用hadoop2_env.sh部署。

https://groups.google.com/a/cloudera.org/forum/#!topic/oryx-user/AFIU2PE2g8o提供了關於我所經歷的行爲的背景討論的鏈接,如果需要其他細節。

謝謝!

回答

1

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%的羣集資源。但是,雲環境中推薦的方法的確擁有多個較小的單租戶羣集,因爲您可以專門針對所需的工作負載調整每個羣集,並且無需擔心許多不同用途之間的資源打包問題案例。

相關問題