【问题标题】:GNU Parallel -- How to understand "block-size" setting, and guess what to set it to?GNU Parallel——如何理解“块大小”设置,并猜猜设置它是什么?
【发布时间】:2019-12-27 00:02:10
【问题描述】:

如何在具有多个内核的单台机器上使用 GNU 并行运行 grep 时设置块大小参数,基于“large_file”文件大小、“small_file”文件大小和我使用的机器以获得尽可能快的性能(或者如果我在这里缺少其他东西,请纠正我)?将其设置得太高或太低时会遇到哪些性能问题/速度瓶颈?我了解 what block-size 的作用,因为它以块的形式阻止了 large_file,并将这些块发送到每个作业,但我仍然错过了如何以及为什么会影响速度的可能性执行。

有问题的命令:

parallel --pipepart --block 100M --jobs 10 -a large_file.csv grep -f small_file.csv

其中 large_file.csv 的位置:

123456    1
234567    2
345667    22

和 small_file.csv 在哪里:

    1$
    2$

等等……

谢谢!

【问题讨论】:

  • 我建议在这里查看阿姆达尔定律:cs.uky.edu/~jzhang/CS621/chapter7.pdf。在这个问题中需要考虑到从硬盘读取不是并行的,因为一次只能读取一个线程。
  • 谢谢!我审查了它——很好的材料,谢谢你把它寄给我。我知道我受到硬盘固有的串行读取的限制,但问题源于以下观察,这使我相信其他参数可能会有所帮助:从一次运行到下一次使用类似大小的运行时,我得到了截然不同的运行时间小文件和大文件。我希望 block_size 是一种可以提供帮助的杠杆,但我不确定......
  • 请记住,时间变化可能是由于操作系统当前拥有的资源的变化。要进行更“纯”的测试,请关闭所有可以关闭的程序,甚至在 Linux 内核模式下执行测试。

标签: grep gnu-parallel


【解决方案1】:
parallel --pipepart --block -1 --jobs 10 -a large_file.csv grep -f small_file.csv

--block -1 会将 large_file.csv 拆分为每个作业槽一个块(此处为 10 个块)。拆分将即时完成,因此不会将其读入 RAM 进行拆分。

如果每行花费的时间大致相同,则拆分为 n 个大小均匀的块(其中 n = 并行运行的作业数)通常是有意义的。如果它变化很大(例如,某些行的处理时间比其他行长 100 倍),那么切割成更多位可能更有意义。例如。 --block -10 将分成 --block -1 的 10 倍的块。

很少能提前猜到最佳值,因为它也可能取决于您的磁盘速度。所以尝试不同的值并确定瓶颈在哪里。它通常是磁盘 I/O、CPU、RAM、命令启动时间之一。

【讨论】:

  • 此设置 (-1) 是否假定可用 RAM 超过 large_file.csv 的大小?
  • 相反的--pipe --pipepart 不缓存在 RAM 中并且速度更快。不过,它只适用于文件。
  • 谢谢!抱歉,如果您不介意最后跟进:是什么让 --block -1 成为最佳设置?试图在这里理解一个(可能对其他人来说很明显的)概念。我可以大胆猜测:如果你把它拆分得更小,你实际上是在创建一个文件大小/(块大小)元素的队列——这是一个正确的理解吗?
猜你喜欢
  • 2011-03-18
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2020-05-03
  • 2019-09-09
  • 1970-01-01
  • 1970-01-01
  • 2020-06-26
相关资源
最近更新 更多