docker是一个可能的解决scheme，以rubyGIL限制在轨道？

这只是一个想法，让我知道如果我错过了什么，或者如果它可以是一个好的。

在单个服务器/虚拟机上运行N个rails进程是很常见的，但由于GIL（Global Interpreter Lock，全局解释器锁），最多不能执行。

而不是在单个服务器内部运行N个进程，我可以用一个单独的rails进程（每个运行在不同的端口上）运行N个容器。

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

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

有什么意见？

谢谢

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

两个进程的fork使用很less的附加内存，第二个进程inheritance了第一个进程的精确副本。对此做任何更改都会导致更多的内存开销，但是像Rails库和其他gem这样的东西没有改变，基本上是免费的。

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

这并不是说容器化的方法不是没有优点，但它可能需要一个混合的方法：每个容器有M个进程。

请记住，如果你真的遇到了GIL的麻烦，那么就使用没有的Jruby 。

这根本不会提高并发性：GIL适用于单个进程内的线程。多个进程可以同时执行 – 由于GIL，会出现多个进程进程的模式。

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

容器是美好的事物，但你所描述的不是使用它们的理由。