使用pthreads在DFS环境中进行并行化正则表达式匹配

Question

我正在尝试为大学项目并行化grep。我假设在实际的正则表达式匹配中抛出更多的线程是低效的：它们处理数据的速度比从磁盘读取的速度快。但是，我正在使用Lustre DFS系统的MPI集群，它允许我在多个存储池中划分数据。

我希望通过利用多个磁盘以某种方式利用它，从而减少硬盘I / O造成的瓶颈。经过一些初步测试后，我无法找到最大化DFS的解决方案。

我试过了：

1. 一个大的单个文件，跨多个OST条带化。每个线程读取条带大小大小的数据块（例如条带大小/ OST ==线程读取大小）。我的意图是每个线程从不同的OST读取数据（重叠/边界情况除外）。
2. 多个较小的文件，每个文件都有自己的OST条带。每个线程都读取一个完整的文件，但每个文件都位于不同的OST上。

如果没有加速，每个案例都很少提供。我希望获得合理的加速（总体上最多可以达到2倍）。

我应该担心I / O瓶颈吗？

在编写C代码时如何利用DFS？我试图从与条带大小匹配的偏移量以及位于不同OST和（我假设）不同磁盘上的文件中读取数据。

有没有办法实现可扩展的并行grep / regex匹配器？

Answer 1

这更像是一个扩展的评论而不是一个答案......

您是否正在尝试编写并行grep，或者您是否正在尝试编写一个对不同数据并行运行的grep？我可以阅读你的问题，建议你考虑其中一个或两个。如果我是对的（请注意，当我试图解释问题时，我通常是错的）我建议你将这两个问题分开并先解决一个，然后加入另一个。

如果您的方案是在许多小文件上运行grep，那么这将很容易并行化，您只需要某种调度程序就能以大致相等的块来分配工作。

如果您的方案是在一个（或几个）大文件上使用grep，那么我可以看到以块的形式读取文件的好处，每个进程（或）一个块。我看到的问题是，一些匹配的解决方案将跨越块。这对我来说是一个有趣的问题，但你是大学生，可以访问最新的文献，所以我会比我更了解。

如果您的方案是编写并行grep，这是一个在执行时使用多个处理器核心的程序，那可能是一个更有趣（即困难）的问题。因为grep通过构造FA来工作，并且因为FA通常被建模为图形，并且因为图形可以（如果它们满足某些标准）被分解成子图，这可能是可行的 - 你只需要并行构建FA，为子图生成线程，并收集结果。我认为负载平衡会很困难。

我对并行文件系统知之甚少，但我认为我建议只有在群集上的不同节点读取DFS上文件的不同部分时才能获得好处。如果您使用线程，这意味着您的线程必须位于群集上的不同节点上？

现在对你的问题给出一些不好的答案。

• 我应该担心I / O. 瓶颈？ - 当然好。您已经在足够精确的水平上测量了grep的性能，以确定在各个阶段花费了多少比例的挂钟时间，包括构建FA，读取输入文件等等。 grep是一个非常成熟的产品，它已经花费了大量的优化工作，所以你已经为自己设定了一个艰难的目标。您还将测量群集文件系统的特征和线程间通信时间，等等。
• 在编写C代码时如何利用DFS？ - 无法帮助你，但我认为文件系统API提供了必要的功能;你似乎试图直接解决磁盘硬件问题。
• 有没有办法实现可扩展的并行grep / regex匹配器？ - 我确定有，但你是学生，在开始这个项目之前，你没有检查出可能性和陷阱吗？

Answer 2

您对如何并行化此问题的直觉似乎是正确的，但我猜您的实现中有一些意外序列化您的磁盘访问。 Grep将受I / O限制，如果让集群中的每个系统都运行其本地数据，您应该会看到大量的加速。

您将不得不通过Lustre系统查看有关如何通过MPI访问文件的详细信息。听起来软件堆栈实际上是序列化所有磁盘访问，因此您无法利用分布式FS。或者，您的客户端可能正在访问他们所在节点的错误文件片段。

  

在编写C代码时如何利用DFS？

如果您正在使用标准POSIX文件操作，那么运气不好。他们没有公开足够的信息来简化这项任务。这就是分布式文件存储和处理系统编写为

的原因