docker是否可以解决rails中的ruby GIL限制问题？

Question

这只是一个想法，让我知道我是否遗漏了什么，或者它是否是一个好的。

在单个服务器/ VM上运行N个rails进程是很常见的，但由于GIL（全局解释器锁定），它们无法执行。

我可以在一个服务器内运行N个进程，而不是在一个服务器中运行N个进程，每个进程都有一个rails进程（每个进程在不同的端口上运行）。

通过这种方式，我应该可以并行执行更多的rails进程，对吧？

我猜容器增加了开销，但无论如何它可能都有意义。

有什么意见吗？

谢谢

Answer 1

这比运行N个进程效率低得多。这里的一个简单原因是Ruby on Rails的大多数流程管理器都使用“pre-fork”模型，其中在流程被拆分之前加载了大量代码。

两个进程的fork使用非常少的额外内存，第二个进程继承第一个进程的近似精确副本。对此进行的任何更改都会产生更多的内存开销，但是像Rails库和其他gem这样的东西没有改变，基本上是免费的。

如果你有多个独立的进程，每个进程都需要加载，解析和初始化运行Rails所需的每个Ruby类。

这并不是说容器化方法并非没有价值，但它可能需要一种混合方法：N个容器，每个容器都有M个进程。

请记住，如果您真的遇到GIL问题，请使用没有GIL的Jruby。

Answer 2

这根本不会改善并发性：GIL适用于单个进程中的线程。多个进程可以同时执行 - 由于GIL而产生多个rails进程的模式。

正如tadman所说，你也可能增加内存使用量。您可能能够估计它（假设您使用乘客进行部署），因为passenger-memory-stats工具允许您获取RSS以及私有脏RSS（即驻留但不与父进程共享的内存）。如果非共享内存几乎没有，那么你就不会因为非fork模型而浪费任何内容。

容器是很棒的东西，但是你所概述的并不是使用它们的理由。