是時候把去年早期MapReduce調優工作的結果放出來了，丟在Google Doc裏太長時間，都落了一身的灰
Benchmark: 對1G數據做wordcount
部分內容:
*********************************
硬件級別
提高磁盤IO的性能
noatime 我爲兩臺slaves server設置了noatime. vi /etc/fstab.map task的平均執行時間減少兩秒,這影響硬盤IO的性能,shuffle的時間也相應地減少了1分鐘,不影響reduce的執行時間
client端設置
map與reduce task數量
map task的數量由split的數量決定,split的數據越小,每個map task執行的時間就越短,但相應地, job的執行時間就拉長了, 因爲內部調度的時間更長了
benchmark:
之前是67個map task,平均執行時間是16秒, job完成時間接近7分鐘
後來map task變成265個, 平均每個map task執行8秒,但job完成時間差不多12分鐘
reduce task的數量由client來設置
我測試的結果client設置result task略大於或等於集羣reduce slot, 當然這是整個集羣只有一個job在執行的情況下,當有多個job執行時, 網上的建議是少於集羣reduce slots總量
集羣reduce slots數量是4,我設置reduce數量成8的時候,每個reduce執行的很快,shuffle過程也短,最終job完成時間差不多是7分鐘,而設置爲2時,shuffle時間很長,job完成時間爲12分鐘.當我再設置爲4個reduce task時, 執行時間差不多8分鐘
後來我又做了三個長時間job併發運行的測試,結果顯示縱使有很多個map slot在運行, 兩臺slaves的CPU與內存利用率不是很離譜, 但不同的場景應該有不同的設置,主要還是根據slave的負載來決定. 查看slave機器的負載可使用top命令
*********************************
橙色： 正常的調優點，試驗後有正常的反應
紅色： 不可理喻的地方，與正常的想法相違背
黃色： 可有可無的地方，只是試驗了，不推薦使用
調優是基於Hadoop 0.21版本。不再過多解釋了，看過後如有不認同且有爭議的調優點，請與我討論，謝謝