我在 Rails 应用程序中遇到问题。 几个小时后，应用程序似乎开始挂起，我无法找到问题所在。日志文件中没有任何相关内容，但是当我尝试从浏览器获取 url 时没有任何反应（比如 mongrel 接受请求但无法响应）。
您认为我可以通过什么测试来了解问题所在？
【问题讨论】：
标签： ruby-on-rails ruby mongrel
我可能会因为回避这个问题而被否决，但我最近从 nginx + mongrel 转到了 mod_rails 并且印象深刻。转向更简单的设置无疑会在未来让我头疼。
这是一个非常简单的过渡，我强烈推荐它。
【讨论】：
您确定问题是由 Mongrel 引起的吗？您是否尝试过在 WEBrick 下运行您的应用程序？
【讨论】：
有a few things you can check，但由于您说日志中没有任何内容指示错误，听起来您在使用Logger 类的日志轮换功能时可能会遇到错误。它会导致杂种被锁定。与其依赖 Logger 来轮换日志，不如考虑使用 logrotate 或其他一些外部日志轮换服务。
【讨论】：
这种情况是否每次都在固定的小时数/天数内发生？你有多少内存？
【讨论】：
我遇到了同样的问题。我缩小范围的几个选项与 MySQL 适配器相关。我在 Red Hat Enterprise Linux 4（或 5）上运行，应用程序会在给定的空闲时间后挂起。
一个建议的解决方案是编译原生 MySQL 绑定，我一直在使用纯 Ruby 绑定。
另一个是将 MySQL 适配器上的超时设置为高于连接空闲的时间。 （我没有记录具体的配置，但我记得它在 environment.rb 中，它是 mysql 适配器中的一些类变量。）
我不记得这些解决方案中的任何一个是否解决了它，在那之后不久我们就搬到了 Ubuntu 并且从那以后没有遇到任何问题。
【讨论】：
查看 Mongrel 常见问题解答： http://mongrel.rubyforge.org/wiki/FAQ
根据我的经验，mongrel 在以下情况下挂起：
ActiveRecord::Base.verification_timeout = 14400
（这在常见问题解答的部署部分中有进一步解释）【讨论】：
不幸的是，Rails（以及 Mongrel）随着时间的推移消耗过多内存并崩溃是一个已知问题（“Ruby, rails, crashing, memory”的 Google 条目超过 50K）。当前的 ruby 解释器具有 sometimes simply fails entirely to give memory back to the system 的属性 - 它可以重用它拥有的内存，但它不会放弃它。
在生产环境中有许多监控、杀死和重启 Mongrel 实例的方案 - 例如：（随机选择）rails monitor。在更果断地解决问题之前，其中之一可能是您最好的选择。
【讨论】：
我们也遇到过同样的问题。首先，安装 mongrel_proctitle gem
http://github.com/rtomayko/mongrel_proctitle/tree/master
这个 gem/plugin 将允许您通过“ps”查看 mongrel 进程，您可以查看 Mongrel 是否挂起。我们在 Mongrel 中看到的一个问题是它会很高兴地接受连接并将它们排入队列，然后将自身楔入。此插件将帮助您查看 Mongrel 何时被楔入，但您必须使用另一个监控应用程序才能真正重新启动楔入的 Mongrel，例如 Monit 或 God
您可能还想考虑在您的 Mongrel 前面放置一个更平衡的反向代理，即 HAproxy，而不是 nginx、Apache 或 Lighttpd。通过在 HAproxy 中设置“maxconn 1”，您可以确保队列由 HAproxy 与 Mongrel 维护。其他反向代理（nginx、Apache、Lighttpd）只做循环，这意味着它们可以在不经意间加载你的 Mongrel 队列。
我个人的选择是上帝，因为它更灵活。
tl;dr 安装这个 gem 插件并留意你的 Mongrels。试试 Apache+Phusion Passenger。
【讨论】：