问DFS环境中的并行Regex匹配
EN

Stack Overflow用户

提问于 2010-11-22 17:11:49

回答 1查看 333关注 0票数 0

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

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

我试过：

：一个大的、单一的文件，跨多个OST文件。每个线程读取与条带大小相同的数据块(例如条带大小/ ==线程读取大小)。我的意图是，每个线程从不同的OST读取数据(除了重叠/边框cases).
Multiple，较小的文件外，每个线程都被条带化到自己的OST中)。每个线程读取一个完整的文件，但是每个文件位于不同的OST.

上。

如果没有加速的话，每个病例都能提供很少的信息。我希望得到一个合理的加速(最多2倍的整体应该是好的)。

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

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

有办法实现可伸缩的并行grep/regex匹配器吗？

concurrency

pthreads

mpi

regex

回答 1

Stack Overflow用户

发布于 2010-11-23 02:04:20

这与其说是回答，不如说是延伸的评论.

您是试图编写并行grep，还是试图编写运行在不同数据并行上的grep？我可以读到你的问题，表明你正在考虑其中一个或两者。如果我是对的(请注意，当我试图解释问题时，我通常是错的)我建议你把这两个问题分开，先处理其中一个，然后再加上另一个。

如果您的场景是在许多小文件上运行grep，那么这将非常容易并行化，您只需要某种类型的调度程序将工作打包成大致相等的块。

如果您的场景是在一个(或几个)大文件上使用grep，那么我可以看到以块形式读取文件的好处，每个进程一个块(或)。我看到的问题是，一些匹配的分辨率将跨块。我觉得这是个有趣的问题，但你是一个能接触最新文献的大学生，所以你会比我了解得更多。

如果您的场景是编写并行grep，即在执行时使用多个处理器核的程序，那么这可能是一个更有趣(即困难)的问题。因为grep是通过构造FA来工作的，而且由于FAs通常被建模为图，而且由于图可以(如果满足某些标准)被分解为子图，这可能是可行的--您只需并行化FA的构造，为子图生成线程，并收集结果。我想负载平衡会很困难。

我对并行文件系统没有深入的了解，但我认为我的建议是正确的，即只有当集群中的不同节点读取DFS上的文件的不同部分时，才能获得好处。如果您使用的是线程，这意味着您的线程必须位于集群中不同的节点上？

对你的问题给出一些糟糕的答案。

，我该担心I/O瓶颈吗？-当然。您将在足够精细的级别上度量grep的性能，以确定在其各个阶段(包括构造FA、读取输入文件等)花费了多少时间。grep是一个非常成熟的产品，它已经花费了大量的优化努力，所以你已经为自己设定了一个艰难的目标。您还将测量集群文件系统的特性和线程间通信时间，诸如此类。
在编写C代码时如何利用DFS？-无法帮助您，但我认为文件系统API提供了必要的功能；你似乎试图直接解决磁盘硬件问题。
有办法实现一个可伸缩的并行grep/regex匹配器吗？

票数 0

页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持

原文链接：

https://stackoverflow.com/questions/4251823

复制

mysql -- 清空表中数据

ide

注 : truncate操作中的table可以省略，delete操作中的*可以省略

互联网-小阿宇

2022/11/21

5.1K0

mysql — 清空表中数据