看完http://gbif.blogspot.com/2011/01/setting-up-hadoop-cluster-part-1-manual.html我们得出结论，我们的 6 节点 hadoop 集群可以使用一些调整，而 io.sort.factor 似乎是一个很好的选择，因为它控制着一个重要的权衡。我们正计划进行调整和测试，但提前计划并知道会发生什么和要注意什么似乎是合理的。
目前是 10。我们怎么知道它导致我们合并太多？当我们提出它时，我们怎么知道它导致打开太多文件？
请注意，我们无法直接关注博客日志摘录，因为它已更新为 CDH3b2，我们正在研究 CDH3u2，并且它们已更改...
最佳答案
有一些权衡需要考虑。
合并文件时进行的搜索次数。如果您将合并因子增加得太高，那么磁盘上的寻道成本将超过执行并行合并所节省的成本(请注意，操作系统缓存可能会在一定程度上减轻这种情况)。
增加排序因子会减少每个分区中的数据量。我相信每个排序数据分区的数字是 io.sort.mb/io.sort.factor 。我相信一般的经验法则是 io.sort.mb = 10 * io.sort.factor(这是基于磁盘在传输速度上的寻道延迟，我相信。我相信这可以调整如果这是你的瓶颈，那就更好了。如果你让它们彼此保持一致，那么合并的查找开销应该最小化
如果增加 io.sort.mb，则会增加集群的内存压力，从而为作业任务留出更少的内存。用于排序的内存使用量是 mapper tasks * io.sort.mb——所以如果这个值太高，您可能会发现自己导致额外的 GC
本质上，
如果您发现自己进行大量交换，那么很有可能您将排序因子设置得太高了。
如果 io.sort.mb 和 io.sort.factor 之间的比率不正确，那么您可能需要更改 io.sort.mb(如果您有内存)或降低排序因子。
如果您发现在 mapper 上花费的时间比在 reducer 上花费的时间多，那么您可能希望增加 map 任务的数量并减少排序因子(假设存在内存压力)。
关于hadoop - 我如何判断我的 hadoop 配置参数 io.sort.factor 是太小还是太大？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8642566/