ruby-on-rails - 如何管理造成停机的旅客过时 worker

Question

我有一个在ubuntu 14.04机器上运行的Rails应用程序，它由Nginx和passenger提供服务。有时应用程序关闭会出现以下错误

[ agents/LoggingAgent/Main.cpp:338 ]: Signal received. Gracefully shutting down... (send signal 2 more time(s) to force shutdown)
[ agents/LoggingAgent/Main.cpp:400 ]: Received command to shutdown gracefully. Waiting until all clients have disconnected...
[ ServerKit/Server.h:453 ]: [LoggerAdminServer] Shutdown finished
[ agents/LoggingAgent/Main.cpp:425 ]: PassengerAgent logger shutdown finished
[ ServerKit/Server.h:453 ]: [ServerThr.1] Shutdown finished
[ ServerKit/Server.h:453 ]: [ServerThr.2] Shutdown finished
[ ServerKit/Server.h:453 ]: [AdminServer] Shutdown finished
[ agents/HelperAgent/Main.cpp:724 ]: Disconnecting long-running connections for process 19431, application /public#default
[ agents/HelperAgent/Main.cpp:724 ]: Disconnecting long-running connections for process 19440, application /public#default
[ agents/Watchdog/Main.cpp:1255 ]: Starting PassengerAgent watchdog...
[ agents/HelperAgent/Main.cpp:883 ]: Starting PassengerAgent server...
[ agents/HelperAgent/Main.cpp:232 ]: PassengerAgent server running in multi-application mode.
[ agents/HelperAgent/Main.cpp:637 ]: PassengerAgent server online, PID 19637
[ agents/LoggingAgent/Main.cpp:431 ]: Starting PassengerAgent logger...
[ agents/LoggingAgent/Main.cpp:312 ]: PassengerAgent logger online, PID 19645
[ agents/HelperAgent/Main.cpp:868 ]: PassengerAgent server shutdown finished

除非重新启动 Nginx，否则该应用程序仍处于关闭状态。这可能是由于过时的工作人员不再服务并且正在消耗内存(如果我错了，请纠正我)。

我将旅客的 max pool size设置为 6，因为我的应用程序实例使用 150-200 Mb占用了内存的 2GB RAM。

我正在考虑编写一个脚本，该脚本会定期检查过时的工作程序，如果发现该脚本，请重新启动 Nginx或执行 touch tmp/restart.txt。我还想知道如何检查陈旧的工作程序，或者 passenger是否未按预期工作。

我认为的另一种解决方案是定期重新启动 Nginx或在一个固定的时间间隔(例如一小时)后执行 touch tmp/restart.txt。

我还阅读了有关重新启动应用程序的三种方式的乘客文档

passenger-config restart-app

restart.txt

重新启动Nginx

前两种情况在重新启动应用程序时不会丢弃任何请求，但在重新启动应用程序时停机时间可能为零，因为重新启动应用程序可能需要一些时间，具体取决于应用程序。

我想知道哪种方法是个好方法，还是有其他方法可以解决这个问题。

Answer 1

首先，您应该真正检查passenger configuration options。其次，您应该真正弄清楚实际上是什么导致您的乘务员上吊。为此，有一个旅客记录参数(您可以监视)，因为似乎您不确定这些过程中发生了什么。 :)

现在关于手头的第一个问题-您希望强制工作人员重新启动-如果实际上是由于流程挂起而无所事事:您可以合并

passenger_min_instances
passenger_max_instances

和

passenger_pool_idle_time / passenger_max_requests

在给定的链接上阅读一些有关这些命令的信息，它会更加详细。