Puma 停止在使用 Nginx 的 EC2 实例上运行 Rails 应用程序（使用 Capistrano/Capistrano Puma）

Question

我的首要问题是，我怎样才能让 Puma 停止失败。但这实际上是由许多小问题组成的。我将对它们中的每一个进行编号并加粗，以尝试使这个问题可以回答。

我在一个 t2.nano 的 EC2 实例上托管 Rails 应用程序。诚然，这是一个非常小的盒子——但我不希望我的网站获得任何流量。我使用 Capistrano 和 Capistrano Puma 成功地配置了 Nginx 和 Puma 的所有内容。一切都很好，直到有一天我去我的网站看到了 Nginx 504 消息。

打开Nginx错误日志，发现无法连接Puma：

connect() to unix:/home/deploy/myapp/shared/tmp/sockets/puma.sock failed (111: Connection refused) while connecting to upstream, client: xxx.xxx.xxx.xxx, server: localhost, request: "GET / HTTP/1.0", upstream: "http://unix:/home/deploy/myapp/shared/tmp/sockets/puma.sock:/500.html", host: "myapp.com"

调试这个，我得知 Puma 已经停止运行。这就是 Nginx 无法连接到它的原因。我认为这里有两个问题：第一，彪马不应该停止奔跑。服务器很小，但没有流量。第二，当 Puma 确实失败时，它应该优雅地重新启动。但是，我现在只关注第一个问题。因为如果 Puma 不断地重新启动，有时它会以严厉的方式终止进程似乎是合理的。

为了调试它，我打开了 htop。果然，机器在没有任何可用内存的情况下运行。这是有道理的——我在一台微型机器上运行数据库、rails 应用程序、网络服务器和内存缓存。它不断耗尽内存并杀死 Puma。

我查看了使用 Capistrano 设置的 Puma 配置。在 config/deploy.rb 我有这些行--

set :puma_threads, [0, 8]
set :puma_workers, 0

我阅读了有关 puma_workers 和 puma_threads 的所有信息。我还了解到 Nginx 有自己的工人。 Puma 工艺非常昂贵。 Puma 的酷之处在于它是适当的多线程——所以独立的进程非常棒。听起来每个工作人员都有自己的一组线程——所以如果有 4 个工作人员和 8 个线程，那么将有 32 个进程。但就我而言，我想使用很少的内存。 2个过程对我来说听起来不错。 1。我对工作线程和线程的理解正确吗？

我更新了我的 config/deploy.rb 文件并部署了 0 个 puma_workers 和 min=0, max=2 个线程。

似乎 Nginx 的配置位于：/etc/nginx/nginx.conf。 Puma 的配置位于：/home/deploy/myapp/shared/puma.rb。我本来希望我在 config/deploy.rb 中的更新让 Capistano 编辑配置文件。不走运——我的最小、最大线程仍然设置为 0,8。 2。使用 Capistano 时尝试通过 config/deploy.rb 更新这些值是否正确？

另外——我打开了 nginx.conf 看到了worker_processes 4;。 3。是我安装 Nginx 时设置为四个还是 Capistano 设置了这个默认值？

我打开了 htop，果然我有很多 Puma 进程。因此，我手动编辑了我的配置文件并重新启动了 Puma 和 Nginx。

我将 Nginx 工作人员的数量从 4 个更改为 1 个。查看 htop，这很有效。我现在只有 1 个 Nginx 工作人员。然而，Nginx 工作线程从来都不是很昂贵（与 Puma 线程相比）。所以我认为这并不重要。

但是，仍然有超过 2 个 Puma 线程 - 有 6 个。在云雀中，我将最小线程数从 0 更改为 1 - 认为 0 不是一个可能的数字，所以它可能正在设置默认值.这将 Puma 进程数增加到 9。出于同样的原因，我还尝试将 puma_workers 数更改为 1，并且进程数增加了。 4。拥有 0 个线程和/或工作线程是什么意思？

然后我尝试手动终止其中一个 puma 进程 (sudo kill xxxxx)，然后 所有 个 Puma 进程都死了。

5.我需要做什么才能只有 2 个 puma 进程？

如你所见，我对 Puma 的理解不是很好，Puma vs Nginx vs Capistano 之间的界限也不清楚。任何帮助是极大的赞赏。我无法找到有关此问题的大量资源。

Answer 1

这是我学到的——

• 如果 Puma 停止工作，请确保您有足够的内存来处理您指定的工作线程和线程数。每个 Puma 流程都非常昂贵。
• 如果设置 0 个worker，Puma 将不会在集群模式下运行。建议使用集群模式运行 MRI。
• 线程是按集群设置的。如果您有 2 个作品和 0.8 个线程，这意味着您将有两个作品，每个作品将有 1 到 8 个线程。
• Puma 使用除线程之外的进程。 Puma 有一个父进程的 PID。如果您使用集群模式，它有一个 PID 来管理集群。如果您使用集群模式，它还为每个集群提供一个 PID。然后，有固定数量的 PID 来运行其他任务（每个集群）。如果没有集群模式，则有 5 个固定 PID。在集群模式下，有 7 个固定 PID。
• 这就是全部 - 如果您看到的进程比您预期的要多，这就是原因。另外——当你添加一个新的工人时，你会添加大量昂贵的流程。确保你有空间。 我有一个小应用程序，1 个工作人员和 min=1, max=4 个线程似乎工作得很好。拥有最多 8 个线程似乎是我一直在杀死 puma 的原因。

回答我最初的问题--

1. 是的，上面对worker和threads的解释是正确的。
2. capistrano-puma 似乎只在第一次部署时设置 puma 配置。
3. 我认为 nginx 配置是在安装 nginx 时创建的。
4. 0 workers 表示你在没有集群模式的情况下运行 puma。不可能有 0 个线程。我相信 0,8 和 1,8 是一样的。
5. Puma 需要运行除了您请求的线程之外的进程。仅使用 2 或 3 个 PID 来运行 puma 是不可能的。这些进程运行附加任务。

Answer 2

彪马的嫌疑人被绞死

Puma 是唯一一个鼓励在 MRI Ruby 中使用线程的主流项目（好吧，无论如何，Heroku 鼓励这样做）。

这就是为什么我们有时会看到 Puma 工作人员的声明，即人们如何认为 Puma 存在各种问题，而问题在其他地方，它确实存在，而且只影响 Puma：P

“我们”在过去发现并修复了一些非常怪异和令人讨厌的 Ruby GC 问题，这些问题是在 Ruby MRI 中大量使用线程以及一些怪异的极端情况（记住http://blog.skylight.io/hunting-for-leaks-in-ruby/），谁说这不是人们将这些怪异问题归咎于 Puma 的最后一个？

尝试禁用线程一段时间，看看效果如何，然后告诉我们，也许兔子又躺在那里

解释线程、集群模式和工作者的文档

• 线程池文档：https://github.com/puma/puma#thread-pool
• 集群模式文档：https://github.com/puma/puma#clustered-mode
• puma.rb 选项：https://github.com/puma/puma/blob/master/examples/config.rb

在Thread pool 下，文档解释了如何设置工作线程的数量。请记住，Puma 主要是/曾经是 JRuby 的东西，MRI 支持和分叉是后来才添加的，文档中配置条目的顺序（如何在如何设置分叉之前设置线程）是由此产生的结果。

文档状态：

Puma 使用您可以修改的动态线程池。您可以使用 -t（或 --threads）标志设置池中可用的最小和最大线程数：

Puma 2 提供集群模式，除了已经提供的线程外，您还可以使用分叉进程同时处理多个传入请求。

意思是，Puma 总是线程，它就是这样做的，如果你告诉它做 0/1 线程，它会做 1 个线程以便它可以服务请求。

此外，如果您将工人（进程）的数量设置为 > 1，Puma 将以“集群模式”运行，这意味着它将分叉并且每个分叉都会线程化，

即-w 3 -t4:4 将产生 3 个进程，每个进程运行 4 个线程，允许您同时处理 12 个请求。

Puma 文档没有具体说明 Puma 将使用哪些进程以及多少个进程用于其内部，但只是有根据的猜测是，它至少需要运行所有工作人员 + 1 个主进程来管理它们、传递数据给他们，启动他们，停止他们，引导他们的日志等。