1

我有大量的文本文件。任务是计算这个庞大语料库中所有术语（唯一）的文档频率（包含某个术语的文档数量）。简单地从第一个文件开始并以序列化的方式计算所有内容似乎是一件愚蠢的事情（我承认我这样做只是为了看看它有多么灾难性）。我意识到，如果我以 Map-Reduce 方式进行此计算，这意味着将我的数据聚集成更小的部分并最终聚合结果，我会更快地获得结果。

我的 PC 有 4 个内核，所以我决定将我的数据分成 3 个不同的子集，并将每个子集提供给一个单独的线程，等待所有线程完成它们的工作并将它们的结果传递给另一个方法来聚合所有内容。

我用一组非常小的数据对其进行了测试，效果很好。在我使用实际数据之前，我用更大的数据集对其进行了测试，以便更好地研究它的行为。我启动了 jvisualvm 和 htop 来看看 cpu 和内存是如何工作的。我可以看到 3 个线程正在运行，并且 cpu 内核也很忙。但这些核心的使用率很少超过 50%。这意味着我的应用程序并没有真正使用我 PC 的全部功能。这与我的代码有关，还是应该如此。我的期望是每个线程都使用尽可能多的 cpu 核心资源。

我使用 Ubuntu。

4

4 回答 4

3

听起来你有一个 IO 绑定应用程序。您在各个线程上花费更多时间从磁盘读取数据，然后您实际上是在处理读取的信息。

您可以通过将程序迁移到具有 SSD 的另一个系统来测试这一点，以查看 CPU 性能是否发生变化。您还可以读入所有文件，然后稍后处理它们，看看这是否会在处理期间改变 CPU 曲线。我怀疑会的。

于 2013-01-18T14:58:29.253 回答
2

如前所述，您可能受到磁盘 IO 的限制。尝试将从磁盘读取的代码与处理数据的代码分开，并为每个代码使用单独的线程池。之后，快速扩展线程池以适合您的资源的一种好方法是使用其中一个Executors线程池。

于 2013-01-18T15:03:31.447 回答
1

您在单台机器上遇到此类问题的 IO 绑定，而不是 CPU 绑定。您是否正在积极阅读文件？只有当所有文件都在内存中时，CPU 才会开始饱和。这就是 map-reduce 有效的原因。它比 CPU 扩展了总 IO 吞吐量。

于 2013-01-18T14:58:41.937 回答
0

如果您在 Linux 上并使用 tmpfs 将数据存储在内存中而不是磁盘上，您可能会加快这一速度。

于 2013-01-18T15:12:41.440 回答