使用了幾個月的hadoopmr，對遇到過的效能問題做點筆記，這裡只涉及job的效能優化，沒有接觸到
hadoop集群，作業系統，任務排程策略這些方面的問題。
hadoop mr在做大資料量分析時候有限的計算資源情況下只能不斷的優化程式。
優化可以從兩個方面進行：
1.hadoop配置
2.程式**
程式**包括的方面很多：job設計，演算法，資料結構，**編寫。
處理流程和引數意義可以看這個帖子，說的比較詳細
hadoop mr 引數意義。
這裡再補充幾個配置：
這個配置項定義了在hdfs上每個block的大小，它的值是以位元組為單位。
可以在配置檔案hadoop-site.xml(hadoop 0.20 以前版本)定義，
也可以在jobconf裡定義。hdfs中block size定義是以檔案為粒度的。
會嚴重降低計算效能。但是如果輸入檔案都是小檔案，就算blocksize再大，每個
是沒用的。命令列設定塊大小可以加引數，0.20以後的用
hadoop fs -d dfs.block.size=134217728 -put local_name remote_location
之前的可以用fs.local.block.size引數
輸入塊大小，比如當前輸入塊128m，設定了最大分割size為64，則原先乙個塊被切分
fileinputformat.setmaxinputsplitsize(job, size)
fileinputformat.setmininputsplitsize(job, size)
mapred.min.split.size這個引數也可以起到同樣效果
mapred.map.tasks.speculative.execution 和
mapred.reduce.tasks.speculative.execution
這兩個選項是設定推測執行的任務，當所有task都開始執行之後，job tracker會統計所有任務的平均進度，
如果某個task所在的task node機器配置比較低或者cpu load很高（原因很多），導致任務執行比總體任務的平均執行要慢，
此時job tracker會啟動乙個新的任務（duplicate task），這個新任務就是推測任務，原有任務和新任務哪個先執行完就把另外乙個kill掉，
這也是我們經常在job tracker頁面看到任務執行成功，但是總有些任務被kill，就是這個原因。推測任務也是要占用計算資源，
因此計算資源緊張，任務執行本身很耗資源情況下可以考慮設定成false，禁止執行。
io.sort.mb
以mb為單位，預設100m，通常來看，這個值太小了，這個選項定義了map輸出結果在記憶體占用buffer的大小，當buffer達到一定閾值，
會啟動乙個後台執行緒來對buffer的內容進行排序，然後寫入本地磁碟(乙個spill檔案)。可以觀察hadoop的日誌，如果spill次數比較多說明
根據map輸出資料量的大小，可以適當的調整buffer的大小，注意是適當的調整，不是越大越好，假設記憶體無限大，io.sort.mb=1024(1g),
和io.sort.mb=300 (300m)，前者未必比後者快，因為1g的資料排序一次和排序3次，每次300mb，一定是後者快(分而治之的思想)。
io.sort.spill.percent
這個值就是上述buffer的閾值，預設是0.8，既80%，當buffer中的資料達到這個閾值，後台執行緒會起來對buffer中已有的資料進行排序，
然後寫入磁碟，此時map輸出的資料繼續往剩餘的20% buffer寫資料，如果buffer的剩餘20%寫滿，排序還沒結束，map task被block等待。
如果你確認map輸出的資料基本有序(很少見)，排序時間很短，可以將這個閾值適當調高，更理想的，如果你的map輸出是有序的資料（基本不可能吧？），
那麼可以把buffer設的更大，閾值設定為1.
io.sort.factor
同時開啟磁碟spill進行並行合併的檔案數，預設是10。
當乙個map task執行完之後，本地磁碟上(mapred.local.dir)有若干個spill檔案，map task最後做的一件事就是執行merge sort，
把這些spill檔案合成乙個檔案（partition），有時候我們會自定義partition函式，就是在這個時候被呼叫的。
執行merge sort的時候，每次同時開啟多少個spill檔案，就是由io.sort.factor決定的。開啟的檔案越多，不一定merge sort就越快，所以也要根據資料情況適當的調整。
補充：merge排序的結果是兩個檔案，乙個是index，另乙個是資料檔案，index檔案記錄了每個不同的key在資料檔案中的偏移量（這就是partition）
有空再寫
各種配置
1.map邏輯處理後資料被展開，寫磁碟次數劇增，可以觀察日誌中的spill次數，調整各個引數
3.distribute cache中載入的資料能不用hashmap就盡量不要用，hashmap會使得記憶體佔用量是原資料的5-10倍，其中
引用佔了大量空間
5.觀察gc的情況，有時候是因為記憶體佔用量高，頻繁gc，嚴重影響處理速度
hadoop JOB的效能優化實踐
使用了幾個月的hadoopmr，對遇到過的效能問題做點筆記，這裡只涉及job的效能優化，沒有接觸到 hadoop集群，作業系統，任務排程策略這些方面的問題。hadoop mr在做大資料量分析時候有限的計算資源情況下只能不斷的優化程式。優化可以從兩個方面進行 1.hadoop配置 2.程式 程式 包括...
hadoop job 日誌的檢視
一般有幾個地方可以檢視 1 通過本地日誌目錄檢視對應container日誌檔案，預設在hadoop的安裝目錄下的 logs userlogs 直接用檢視檔案命令檢視即可 該地方的應用執行日誌不一定最全,因為任務執行日誌由每乙個nm產生在本地，然後再給聚合到檔案系統中 配置聚合日誌功能 log內容省略...
mysql的效能優化 mysql效能優化
檢視安裝指令碼 select version 非互動式超時時間，如jdbc show global variables like wait timeout 互動式超時時間，如資料庫工具 show global variables like interactive timeout show sessi...