在阅读http://gbif.blogspot.com/2011/01/setting-up-hadoop-cluster-part-1-manual.html后,我们得出结论,我们的6节点hadoop集群可以使用一些调整,并且io. sort.factor似乎是一个很好的候选者,因为它控制着一个重要的权衡.我们正计划进行调整和测试,但提前规划并了解预期和观察内容似乎是合理的.
它目前在10.我们怎么知道它导致我们太多的合并？当我们提出它时,我们怎么知道它导致太多文件被打开？
请注意,我们无法直接关注博客日志提取,因为它已更新为CDH3b2,我们正在处理CDH3u2,它们已经更改......
小智 10
需要考虑一些权衡因素.
合并文件时的搜索次数.如果将合并因子增加得太高,那么磁盘上的搜索成本将超过并行合并所节省的成本(请注意,OS缓存可能会稍微减轻这种影响).
增加排序因子会减少每个分区中的数据量.我相信对于排序数据的每个分区,该数字是io.sort.mb/io.sort.factor.我相信一般的经验法则是让io.sort.mb = 10*io.sort.factor(这是基于磁盘在传输速度上的寻道延迟,我相信.我相信这可以调整如果它是你的瓶颈,那就更好了.如果你让它们保持一致,那么合并时的搜索开销应该最小化
如果增加io.sort.mb,则会增加群集上的内存压力,从而减少可用于作业任务的内存.排序的内存使用是映射器任务*io.sort.mb - 所以你可能会发现自己造成额外的GC,如果这个太高了
实质上,
如果您发现自己交换频繁,那么很有可能您将排序因子设置得太高.
如果io.sort.mb和io.sort.factor之间的比率不正确,那么您可能需要更改io.sort.mb(如果您有内存)或降低排序因子.
如果您发现在映射器中花费的时间多于在缩减器中的时间,那么您可能希望增加映射任务的数量并减少排序因子(假设存在内存压力).
| 归档时间： |
|
| 查看次数： |
5559 次 |
| 最近记录： |