对于500k文件，您需要花费大量时间遍历树来查找所有这些文件，然后需要将这些文件分配到inputsplits列表（getsplits的结果）。
正如thomas在他的回答中指出的那样，如果执行作业提交的机器分配给jvm的内存量很低，那么您将看到jvm执行垃圾收集的问题，以尝试找到为这些500k文件建立分割所需的内存。
更糟糕的是，如果这500k文件是可拆分的，并且大于单个块大小，那么您将获得更多的输入拆分来处理文件（一个大小为1gb的文件，块大小为256mb，默认情况下您将获得4个Map任务来处理此文件，假设输入格式和文件压缩支持拆分文件）。如果这适用于您的作业（查看为您的作业生成的Map任务的数量，是否超过500k？），则可以通过修改 mapred.min.split.size 属性设置为大于当前块大小的大小（在上一个示例中，将其设置为1gb意味着您将获得一个Map器来处理文件，而不是4个）。这将有助于getsplits方法的性能getsplits的结果列表将更小，需要更少的内存。
问题的第二个症状是将输入拆分序列化到文件（客户端）所需的时间，然后是作业跟踪器端的反序列化时间。500k+的拆分需要时间，如果jobtracker有较低的jvm内存限制，那么它也会有类似的gc问题。

这在很大程度上取决于提交服务器（或笔记本电脑客户端）的“强大程度”，可能需要升级ram和cpu以加快getsplits调用。
我相信你在那里遇到了交换问题，计算时间比平时长了好几倍。