hadoop调优之一：概述
hadoop集群性能低下的常見原因
（一）硬件環(huán)境 1、CPU/內存不足，或未充分利用 2、網(wǎng)絡原因 3、磁盤原因（二）map任務原因
1、輸入文件中小文件過多，導致多次啟動和停止JVM進程?？梢栽O置JVM重用。
2、數(shù)據(jù)傾斜：大文件且不可分割，導致處理這些文件的map需要很長時間。
3、數(shù)據(jù)本地化效果差。
（三）reduce任務的原因
1、reduce任務數(shù)量過大或過小 2、數(shù)據(jù)傾斜：一部分key的記錄數(shù)量太大，導致某些reduce執(zhí)行過慢3、緩慢的shuffle和排序
（四）hadoop的配置不當
（五）JAVA代碼及JVM調優(yōu)
一、硬件調優(yōu)
1、CPU/內存使用情況vmstat、top
$ vmstat -S M 5procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----r b swpd free buff cache si so bi bo in cs us sy id wa st0 0 0 566 232 239 0 0 65 824 59 39 4 1 93 1 00 3 0 366 232 432 0 0 0 25929 2638 2776 14 14 43 28 02 1 0 241 232 543 0 0 26 38110 2123 1316 75 11 0 14 03 0 0 78 232 543 0 0 0 11784 1558 1028 80 4 16 0 00 0 0 189 232 543 0 0 0 142 1052 933 70 3 27 1 00 0 0 185 232 543 0 0 0 30 500 589 15 1 84 0 02 0 0 180 232 544 0 0 0 3 502 595 12 1 87 0 00 0 0 508 232 293 0 0 0 74 1161 1036 77 5 18 0 00 0 0 626 233 175 0 0 0 150 385 447 2 1 97 0 0以上各個字段的意思分別是：
好了，命令介紹完畢，現(xiàn)在開始實戰(zhàn)講解每個參數(shù)的意思。
r?表示運行隊列(就是說多少個進程真的分配到CPU)，當這個值超過了CPU數(shù)目，就會出現(xiàn)CPU瓶頸 了。這個也和top的負載有關系，一般負載超過了3就比較高，超過了5就高，超過了10就不正常了，服務器的狀態(tài)很危險。top的負載類似每秒的運行隊 列。如果運行隊列過大，表示你的CPU很繁忙，一般會造成CPU使用率很高。
b?表示阻塞的進程,這個不多說，進程阻塞，大家懂的。
swpd?虛擬內存已使用的大小，如果大于0，表示你的機器物理內存不足了，如果不是程序內存泄露的原因，那么你該升級內存了或者把耗內存的任務遷移到其他機器。
free?? 空閑的物理內存的大小，我的機器內存總共8G，剩余3415M。
buff?? Linux/Unix系統(tǒng)是用來存儲，目錄里面有什么內容，權限等的緩存，我本機大概占用300多M
cache?cache直接用來記憶我們打開的文件,給文件做緩沖，我本機大概占用300多M(這里是Linux/Unix的聰明之處，把空閑的物理內存的一部分拿來做文件和目錄的緩存，是為了提高 程序執(zhí)行的性能，當程序使用內存時，buffer/cached會很快地被使用。)
si??每秒從磁盤讀入虛擬內存的大小，如果這個值大于0，表示物理內存不夠用或者內存泄露了，要查找耗內存進程解決掉。我的機器內存充裕，一切正常。
so??每秒虛擬內存寫入磁盤的大小，如果這個值大于0，同上。
bi??塊設備每秒接收的塊數(shù)量，這里的塊設備是指系統(tǒng)上所有的磁盤和其他塊設備，默認塊大小是1024byte，我本機上沒什么IO操作，所以一直是0，但是我曾在處理拷貝大量數(shù)據(jù)(2-3T)的機器上看過可以達到140000/s，磁盤寫入速度差不多140M每秒
bo?塊設備每秒發(fā)送的塊數(shù)量，例如我們讀取文件，bo就要大于0。bi和bo一般都要接近0，不然就是IO過于頻繁，需要調整。
in?每秒CPU的中斷次數(shù)，包括時間中斷
cs?每秒上下文切換次數(shù)，例如我們調用系統(tǒng)函數(shù)，就要進行上下文切換，線程的切換，也要進程上下文切換，這個值要越小越好，太大了，要考慮調低線程或者進程的 數(shù)目,例如在apache和nginx這種web服務器中，我們一般做性能測試時會進行幾千并發(fā)甚至幾萬并發(fā)的測試，選擇web服務器的進程可以由進程或 者線程的峰值一直下調，壓測，直到cs到一個比較小的值，這個進程和線程數(shù)就是比較合適的值了。系統(tǒng)調用也是，每次調用系統(tǒng)函數(shù)，我們的代碼就會進入內核 空間，導致上下文切換，這個是很耗資源，也要盡量避免頻繁調用系統(tǒng)函數(shù)。上下文切換次數(shù)過多表示你的CPU大部分浪費在上下文切換，導致CPU干正經(jīng)事的 時間少了，CPU沒有充分利用，是不可取的。
us?用戶CPU時間，我曾經(jīng)在一個做加密解密很頻繁的服務器上，可以看到us接近100,r運行隊列達到80(機器在做壓力測試，性能表現(xiàn)不佳)。
sy?系統(tǒng)CPU時間，如果太高，表示系統(tǒng)調用時間長，例如是IO操作頻繁。
id??空閑 CPU時間，一般來說，id + us + sy = 100,一般我認為id是空閑CPU使用率，us是用戶CPU使用率，sy是系統(tǒng)CPU使用率。
wt?等待IO CPU時間。
2、網(wǎng)絡
（1）ethtool：檢查網(wǎng)卡是否工作正常，是否全雙工，速度設置是否合理等。
（2）sar：比較各個網(wǎng)卡的性能
# sar -n DEV 3 2Linux 2.6.32-431.23.3.el6.x86_64 (slave1) 03/13/2015 _x86_64_ (1 CPU)08:41:11 PM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s08:41:14 PM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.0008:41:14 PM eth0 11.71 10.70 1.05 4.47 0.00 0.00 0.0008:41:14 PM eth1 144.48 0.00 5.93 0.00 0.00 0.00 0.0008:41:14 PM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s08:41:17 PM lo 28.04 28.04 3.90 3.90 0.00 0.00 0.0008:41:17 PM eth0 183.45 3765.20 27.06 905.80 0.00 0.00 0.0008:41:17 PM eth1 179.05 31.76 7.48 70.62 0.00 0.00 0.00Average: IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/sAverage: lo 13.95 13.95 1.94 1.94 0.00 0.00 0.00Average: eth0 97.14 1878.49 13.99 452.86 0.00 0.00 0.00Average: eth1 161.68 15.80 6.70 35.13 0.00 0.00 0.00（3）iperf：檢查2臺機器間的網(wǎng)絡帶寬
其中一臺充當服務器：
# iperf -s------------------------------------------------------------Server listening on TCP port 5001TCP window size: 85.3 KByte (default)------------------------------------------------------------[ 4] local 10.171.94.155 port 5001 connected with 10.171.29.191 port 46455------------------------------------------------------------Client connecting to 10.171.29.191, TCP port 5001TCP window size: 143 KByte (default)------------------------------------------------------------[ 6] local 10.171.94.155 port 52215 connected with 10.171.29.191 port 5001[ ID] Interval Transfer Bandwidth[ 6] 0.0-10.0 sec 664 MBytes 557 Mbits/sec[ 4] 0.0-10.0 sec 466 MBytes 390 Mbits/sec另一臺充當客戶端：
# iperf -c 10.171.94.155 -f m -d------------------------------------------------------------Server listening on TCP port 5001TCP window size: 0.08 MByte (default)------------------------------------------------------------------------------------------------------------------------Client connecting to 10.171.94.155, TCP port 5001TCP window size: 0.10 MByte (default)------------------------------------------------------------[ 4] local 10.171.29.191 port 46455 connected with 10.171.94.155 port 5001[ 5] local 10.171.29.191 port 5001 connected with 10.171.94.155 port 52215[ ID] Interval Transfer Bandwidth[ 4] 0.0-10.0 sec 466 MBytes 390 Mbits/sec[ 5] 0.0-10.0 sec 664 MBytes 555 Mbits/sec（4）tcpdump：檢查數(shù)據(jù)包的傳輸情況
# tcpdump port 8649tcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes20:43:11.396729 IP master.38498 > slave1.8649: UDP, length 13620:43:11.396746 IP master.38498 > slave1.8649: UDP, length 6420:43:11.397101 IP master.38498 > slave1.8649: UDP, length 13620:43:11.397105 IP master.38498 > slave1.8649: UDP, length 6420:43:11.397107 IP master.38498 > slave1.8649: UDP, length 13620:43:11.397108 IP master.38498 > slave1.8649: UDP, length 8020:43:11.397109 IP master.38498 > slave1.8649: UDP, length 6420:43:11.397110 IP master.38498 > slave1.8649: UDP, length 14420:43:11.397111 IP master.38498 > slave1.8649: UDP, length 6820:43:11.397112 IP master.38498 > slave1.8649: UDP, length 15620:43:11.397114 IP master.38498 > slave1.8649: UDP, length 18820:43:11.397115 IP master.38498 > slave1.8649: UDP, length 9220:43:11.397116 IP master.38498 > slave1.8649: UDP, length 88還可以使用host等參數(shù)。
3、磁盤健康情況
（1）iostart
# iostatLinux 2.6.32-431.17.1.el6.x86_64 (master) 03/13/2015 _x86_64_ (1 CPU)avg-cpu: %user %nice %system %iowait %steal %idle4.73 0.00 3.07 33.99 0.00 58.22Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtnxvda 206.31 292.48 2301.51 176511452 1388963336xvdb 10.24 69.64 645.59 42029194 389614304[root@master ~]# [root@master ~]# [root@master ~]# iostat -m -x -d 5Linux 2.6.32-431.17.1.el6.x86_64 (master) 03/13/2015 _x86_64_ (1 CPU)Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %utilxvda 0.16 115.94 34.57 171.74 0.14 1.12 12.57 4.92 23.83 1.87 38.49xvdb 0.00 71.55 1.09 9.14 0.03 0.32 69.88 0.89 87.38 0.89 0.91Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %utilxvda 0.00 0.00 0.00 0.81 0.00 0.00 8.00 0.00 4.75 1.75 0.14xvdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00（2）dmesg
輸出詳細的錯誤信息，常見的信息如下：
type=1400 audit(1425645012.364:7): avc: denied { setattr } for pid=1318 comm="rrdtool" name="fontconfig" dev=xvda1 ino=1049117 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:fonts_cache_t:s0 tclass=dir二、map端調優(yōu)
1、輸入文件中小文件過多，導致多次啟動和停止JVM進程。
可以設置JVM重用?；蛘咦鲾?shù)據(jù)預處理，將小文件合并。
2、數(shù)據(jù)傾斜：大文件且不可分割，導致處理這些文件的map需要很長時間。
盡量避免這種情況出現(xiàn)，可以通過預處理解決。
3、數(shù)據(jù)本地化效果差。
將數(shù)據(jù)均衡的分布到集群中：
start-balancer.sh
4、檢查是否某天數(shù)據(jù)量突然暴增
三、reduce端調優(yōu)
1、不使用reduce
map結束后向reduce傳輸結果時需要經(jīng)過shuffle階段及排序，并通過網(wǎng)絡傳輸數(shù)據(jù)，此過程引起較大的損耗，因此，在滿足一定條件的情況下，可以將reduce任務設置為0。
job.setNumReduceTasks(0);
注意必須顯示的定義數(shù)量為0，否則默認情況下，會有一個reduce任務，類為Reduce，此類將輸入KV直接作為輸出KV。
2、過濾和投影
如果一定要有reduce過程，那下一步就是盡量減少map輸出的數(shù)據(jù)量，一方面可以減少網(wǎng)絡傳輸數(shù)據(jù)，另一方面可以減少reduce需要處理的數(shù)據(jù)。
減少map的輸出數(shù)據(jù)量有2種常見的方法：
（1）過濾：將對最終結果無影響的整個記錄刪除。
（2）投影：刪除記錄中某些對最終結果無影響的項。
3、使用combiner
使用combiners可以在map階段通過合并數(shù)據(jù)，從而減少向reduce傳輸數(shù)據(jù)。
4、優(yōu)化比較器
此方法可以提高數(shù)據(jù)排序順序
5、減少傾斜數(shù)據(jù)
由于map的輸出中某個key對應大量的value值，從而導致處理這個key的reduce任務所耗時間遠遠大于其它reduce。
6、reduce的數(shù)量調整
將reduce的數(shù)量調整為比集客reduce slot總數(shù)少一點，這可以保證充分利用集群的性能，又可容忍一定的機器錯誤。
四、hadoop配置不當
充分了解hadoop的配置文件，為集群選擇最佳配置。
參考：http://blog.csdn.net/jediael_lu/article/details/38680013
五、java調優(yōu)
參考：？？
總結
以上是生活随笔為你收集整理的hadoop调优之一：概述的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Injector Job深入分析
- 下一篇： 如何在hadoop中控制map的个数