閱讀http://gbif.blogspot.com/2011/01/setting-up-hadoop-cluster-part-1-manual.html後，我們得出結論，我們的6節點的Hadoop集羣可以使用一些調整，並io.sort.factor似乎是一個不錯的選擇，因爲它控制的一個重要權衡。我們正在計劃進行調整和測試，但是提前計劃並且知道期望什麼以及要注意什麼似乎是合理的。我怎麼知道我的hadoop配置參數io.sort.factor是太小還是太大？
這是目前10我們怎麼知道它引起了我們太多的合併？當我們提出這個問題時，我們怎麼知道它會導致打開太多的文件？
需要注意的是，因爲它的更新CDH3b2，我們正在對CDH3u2工作，他們已經改變了我們不能直接按照博客日誌提取物...
，需要考慮幾個權衡。
合併文件時正在進行的查找次數。如果增加合併因子太高，那麼磁盤上的搜尋成本將超過並行合併所節省的成本（請注意，操作系統緩存可能會緩解這一點）。
增加排序因數減小數據的每個分區中的量。我相信這個數字是io.sort.mb/io.sort.factor，用於排序數據的每個分區。我相信一般的經驗法則是有io.sort.mb = 10 * io.sort.factor（這是基於傳輸速度的磁盤尋道延遲，我相信。我敢肯定，這可以被調整如果讓它們保持一致，那麼合併的查找開銷應該最小化
如果增加io.sort.mb，則會增加集羣上的內存壓力， 。可工作任務較少的內存內存使用情況排序是映射器的任務* io.sort.mb - 所以你會發現自己將導致額外的選區，如果這是太高
從本質上講，
如果你發現自己交換巨資，再有就是你設置的排序因素太高的好機會。
如果io.sort.mb和io.sort.factor之間的比例不正確，那麼您可能需要更改io.sort.mb（如果有內存）或降低排序因子。
如果你發現你在你的映射器比你的減速花更多的時間，那麼你可能需要增加的地圖任務的數量，減少了排序因子（假設有內存壓力）。