Ruby：CPU-concurent/multithreaded 任务的负载下降？

Question

序言：我正在开展一个恢复 truecrypt 容器的项目。它以最有可能的随机顺序被切割成超过 3M 的小文件，目标是找到包含加密密钥的容器的开头或结尾。

为此，我编写了一个小 ruby 脚本，该脚本启动许多 truecrypt 进程并发尝试挂载主文件头或恢复备份头文件。通过生成的 PTY 与 truecrypt 交互：

  PTY.spawn(@cmd) do |stdout, stdin, pid|
    @spawn = {stdout: stdout, stdin: stdin, pid: pid}

    if test_type == :forward
      process_truecrypt_forward
    else
      process_truecrypt_backward
    end

    stdin.puts
    pty_expect('Incorrect password')

    Process.kill('INT', pid)
    stdin.close
    stdout.close
    Process.wait(pid)
  end

一切正常，并成功找到了测试容器所需的部分。为了加快速度（我需要处理超过 300 万件），我首先使用了 Ruby MRI 多线程，并在阅读了有关它的问题后切换到 concurent-ruby。

我的实现非常简单：

log 'Starting DB test'
concurrent_db = Concurrent::Array.new(@db)

futures = []

progress_bar = initialize_progress_bar('Running DB test', concurrent_db.size)

MAXIMUM_FUTURES.times do
  log "Started new future, total #{futures.size} futures"

  futures << Concurrent::Future.execute do
    my_piece = nil

    run = 1

    until concurrent_db.empty?
      my_piece = concurrent_db.slice!(0, SLICE_PER_FUTURE)
      break unless my_piece
      log "Run #{run}, sliced #{my_piece.size} pieces, #{concurrent_db.size} left"

      my_piece.each {|a| run_single_test(a)}
      progress_bar.progress += my_piece.size
      run += 1
    end

    log 'Future finished'
  end
end

比起我租了一个有 74 CPU 个核心的大型 AWS 实例，我想："now I gonna proccess it fast"。但问题是，无论我同时启动多少 futures/threads（我的意思是 20 或 1000），我都不会超过 ~50 checks/second。

当我启动 1000 个线程时，CPU 负载仅在 20-30 分钟内保持在 100%，然后下降直到它达到 15% 左右，并且一直如此。 Graph of typical CPU load within such a run。磁盘负载不是问题，我最大达到 3MiB/s，使用 Amazon EBS 存储。

我错过了什么？为什么我不能利用 100% cpu 并获得更好的性能？

Answer 1

很难说为什么您没有看到多线程的好处。但这是我的猜测。

假设您有一个非常密集的 Ruby 方法，调用 do_work 需要 10 秒运行。而且，更糟糕的是，您需要运行此方法 100 次。与其等待 1000 秒，不如尝试对其进行多线程处理。这可以在您的 CPU 核心之间分配工作，将运行时间减半甚至四分之一：

Array.new(100) { Thread.new { do_work } }.each(&:join)

但是不，这可能仍需要 1000 秒才能完成。为什么？

全局 VM 锁定

考虑这个例子：

thread1 = Thread.new { class Foo; end; Foo.new }
thread2 = Thread.new { class Foo; end; Foo.new }

在 Ruby 中创建一个 class 在幕后做了很多事情，例如它必须创建一个实际的 class 对象并将该对象的指针分配给一个全局常量（按某种顺序）。如果线程 1 注册该全局常量，通过创建实际 class 对象获得一半，然后线程 2 启动运行ning，说 "Oh, Foo already exists. Let's go ahead and run Foo.new"，会发生什么。由于 class 尚未完全定义，会发生什么情况？或者，如果 thread1 和 thread2 都创建了一个新的 class 对象，然后都尝试将它们的 class 注册为 Foo 怎么办？哪一个赢了？已创建但现在未注册的 class 对象怎么办？

官方 Ruby 对此的解决方案很简单：实际上不要运行并行执行此代码。相反，有一个名为 "the global VM lock" 的单一大型互斥体可以保护任何修改 Ruby VM 状态的东西（例如创建 class）。因此，虽然上面的两个线程可能以各种方式交错，但 VM 不可能以无效状态结束，因为每个 VM 操作本质上都是原子的。

例子

在我的笔记本电脑上运行大约需要 6 秒：

def do_work
  Array.new(100000000) { |i| i * i }
end

显然这需要大约 18 秒

3.times { do_work }

但是，这也需要大约 18，因为 GVL 阻止了线程实际上运行并行

Array.new(3) { Thread.new { do_work } }.each(&:join)

这也需要 6 秒才能运行

def do_work2
  sleep 6
end

但是现在这个也需要大约6秒才能运行:

Array.new(3) { Thread.new { do_work2 } }.each(&:join)

为什么？如果你深入研究 Ruby 源代码，你会发现 sleep 最终调用了 C 函数 native_sleep 并且在那里我们看到

GVL_UNLOCK_BEGIN(th);
{
    //...
}
GVL_UNLOCK_END(th);

Ruby 开发人员知道 sleep 不会影响 VM 状态，因此他们明确解锁了 GVL 以允许它运行并行。要弄清楚 locks/unlocks GVL 的具体内容以及何时才能看到它的性能优势可能会很棘手。

如何修复代码

我的猜测是您的代码中的某些内容正在达到 GVL，因此虽然您的线程的某些部分正在并行运行（通常任何 subprocess/PTY 东西都会），但它们之间仍然存在争用在 Ruby VM 中导致某些部分序列化。

获得真正并行的 Ruby 代码的最佳选择是将其简化为如下所示：

Array.new(x) { Thread.new { do_work } }

您确定 do_work 是可以解锁 GVL 的简单方法，例如生成子进程。您可以尝试将您的 Truecrypt 代码移动到一个小的 shell 脚本中，这样 Ruby 就不必再与它交互了。

我建议从一个只启动几个子进程的小基准测试开始，并确保它们实际上是运行通过比较串行运行的时间来并行运行。

Ruby：CPU-concurent/multithreaded 任务的负载下降？

Ruby: CPU-Load degradation of concurent/multithreaded task?

ruby

concurrency

multithreading

truecrypt

全局 VM 锁定

例子

如何修复代码