是時(shí)候把去年早期MapReduce調(diào)優(yōu)工作的結(jié)果放出來(lái)了，丟在Google Doc里太長(zhǎng)時(shí)間，都落了一身的灰

Benchmark: 對(duì)1G數(shù)據(jù)做wordcount
部分內(nèi)容:
*********************************
硬件級(jí)別
提高磁盤IO的性能
noatime? 我為兩臺(tái)slaves server設(shè)置了noatime. vi /etc/fstab.map task的平均執(zhí)行時(shí)間減少兩秒,這影響硬盤IO的性能,shuffle的時(shí)間也相應(yīng)地減少了1分鐘,不影響reduce的執(zhí)行時(shí)間



client端設(shè)置
map與reduce task數(shù)量
map task的數(shù)量由split的數(shù)量決定,split的數(shù)據(jù)越小,每個(gè)map task執(zhí)行的時(shí)間就越短,但相應(yīng)地, job的執(zhí)行時(shí)間就拉長(zhǎng)了, 因?yàn)閮?nèi)部調(diào)度的時(shí)間更長(zhǎng)了
benchmark:
之前是67個(gè)map task,平均執(zhí)行時(shí)間是16秒, job完成時(shí)間接近7分鐘
后來(lái)map task變成265個(gè), 平均每個(gè)map task執(zhí)行8秒,但job完成時(shí)間差不多12分鐘

reduce task的數(shù)量由client來(lái)設(shè)置
我測(cè)試的結(jié)果client設(shè)置result task略大于或等于集群reduce slot, 當(dāng)然這是整個(gè)集群只有一個(gè)job在執(zhí)行的情況下,當(dāng)有多個(gè)job執(zhí)行時(shí), 網(wǎng)上的建議是少于集群reduce slots總量
集群reduce slots數(shù)量是4,我設(shè)置reduce數(shù)量成8的時(shí)候,每個(gè)reduce執(zhí)行的很快,shuffle過(guò)程也短,最終job完成時(shí)間差不多是7分鐘,而設(shè) 置為2時(shí),shuffle時(shí)間很長(zhǎng),job完成時(shí)間為12分鐘.當(dāng)我再設(shè)置為4個(gè)reduce task時(shí), 執(zhí)行時(shí)間差不多8分鐘

后來(lái)我又做了三個(gè)長(zhǎng)時(shí)間job并發(fā)運(yùn)行的測(cè)試,結(jié)果顯示縱使有很多個(gè)map slot在運(yùn)行, 兩臺(tái)slaves的CPU與內(nèi)存利用率不是很離譜, 但不同的場(chǎng)景應(yīng)該有不同的設(shè)置,主要還是根據(jù)slave的負(fù)載來(lái)決定. 查看slave機(jī)器的負(fù)載可使用top命令
*********************************

橙色： 正常的調(diào)優(yōu)點(diǎn)，試驗(yàn)后有正常的反應(yīng)
紅色： 不可理喻的地方，與正常的想法相違背
黃色： 可有可無(wú)的地方，只是試驗(yàn)了，不推薦使用

調(diào)優(yōu)是基于Hadoop 0.21版本。

轉(zhuǎn)載于:https://www.cnblogs.com/captain_ccc/articles/4107807.html

總結(jié)

以上是生活随笔為你收集整理的MapReduce:Job性能调优总结的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。