【问题标题】:Issue with passenger乘客问题
【发布时间】:2011-03-23 16:39:17
【问题描述】:

最近我们的 ruby​​ on rails 应用程序升级到了 2.3.8。我们还在升级期间用 Phusion Passenger 替换了 Mongrel/Mongrel 集群。

每当我们尝试部署我们的应用程序时,它最初似乎响应速度更快,但响应时间逐渐增加。我们还注意到数据库盒上的 CPU 使用率飙升至 400%,并且大量请求在全局队列中等待。这似乎只发生在我们的生产环境中。

谁能告诉我应该如何调试这个问题?

我们是否可以限制乘客和 DB 之间的连接数量?

还有一种方法可以在乘客中设置连接池吗?

谢谢,
西瓦库玛。

【问题讨论】:

    标签: ruby-on-rails passenger


    【解决方案1】:

    我认为问题不在于乘客。如果您的 DB 盒 CPU 出现较大的峰值,您的问题可能就在那里。如果没有关于您的数据库的更多信息,很难为您提供具体信息,但您可以尝试以下一些方法:

    1. 运行top 并检查mysqld 或其他数据库进程消耗的总内存量。如果这个数量不高,那么您可能需要调整 MySQL 设置以利用 DB 盒上的 RAM。
    2. 使用mytop 命令分析您正在运行的数据库查询。您可能有一些查询会占用您的所有系统资源或导致大量交换。
    3. 查看您的 MySQL 慢日志,看看您是否有运行时间超过 1 秒的查询。
    4. 检查您的数据库引擎。你在使用 MISAM 和/或 InnoDB 吗?您可能需要以不同方式调整数据库,以便为每个引擎分配适当数量的内存和资源。
    5. 咨询 DBA。他们将能够查看您的使用情况和应用程序,并更明确地告诉您问题是否出在您的数据库或应用程序上。

    P.S:我建议升级到Passenter 3,它的性能比Passenter 2 好。

    【讨论】:

    • 我第二次升级到乘客 3.0.x。
    • 我们已经在使用乘客 3。我们在六台机器上运行应用程序,每台机器有 45 个乘客实例。所以我猜总共有 270 个连接被 MySQL 打开。这可能是mysql占用CPU的原因吗?无论如何限制使用mysql的连接数会有帮助吗?
    • 我不能肯定地说,但我建议先检查我在回答中概述的步骤。 45 次载客对一台机器来说似乎很多,但如果他们能处理它,你的力量就越大。您可以尝试限制已打开的乘客守护程序。
    猜你喜欢
    • 2011-04-29
    • 1970-01-01
    • 1970-01-01
    • 2011-01-07
    • 2014-06-16
    • 2011-09-13
    • 2011-03-29
    • 2012-02-14
    • 2015-06-27
    相关资源
    最近更新 更多