Mongrel 几个小时后挂起
我在 Rails 应用程序中遇到问题。 几个小时后，应用程序似乎开始挂起，我无法找到问题出在哪里。 日志文件中没有任何相关内容，但是当我尝试从浏览器获取 url 时，什么也没发生（就像 mongrel 接受请求但无法响应）。
您认为我可以测试什么来了解问题出在哪里？
I'm running into a problem in a Rails application.
After some hours, the application seems to start hanging, and I wasn't able to find where the problem was. There was nothing relevant in the log files, but when I tried to get the url from a browser nothing happened (like mongrel accept the request but wasn't able to respond).
What do you think I can test to understand where the problem is?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我可能会因为回避这个问题而被否决，但我最近从 nginx + mongrel 迁移到 mod_rails，并且给我留下了深刻的印象。 转向更简单的设置无疑会让我在未来省去很多麻烦。
这是一个非常简单的过渡，我强烈推荐它。
I might get voted down for dodging the question, but I recently moved from nginx + mongrel to mod_rails and have been really impressed. Moving to a much simpler setup will undoubtedly save me headaches in the future.
It was a really easy transition, I'd highly recommend it.
您确定问题是由 Mongrel 引起的吗？ 您是否尝试过在 WEBrick 下运行您的应用程序？
Are you sure the problem is caused by Mongrel? Have you tried running your application under WEBrick?
有一些你可以检查的事情，但既然你说里面什么也没有日志来指示错误，听起来您在使用 Logger 类的日志轮换功能时可能会遇到错误。 它会导致杂种锁定。 不要依赖
Logger来轮换日志，而是考虑使用logrotate或其他外部日志轮换服务。There are a few things you can check, but since you say there's nothing in the logs to indicate error, it sounds like you might be running into a bug when using the log rotation feature of the
Loggerclass. It causes mongrel to lock up. Instead of relying onLoggerto rotate your logs, consider usinglogrotateor some other external log rotation service.这种情况每次都会在设定的小时/天数内发生吗？ 你有多少内存？
Does this happen at a set number of hours/days every time? How much RAM do you have?
我也有同样的问题。 我将范围缩小到的几个选项与 MySQL 适配器相关。 我在 Red Hat Enterprise Linux 4（或 5）上运行，应用程序将在给定的空闲时间后挂起。
一种建议的解决方案是编译本机 MySQL 绑定，我一直使用纯 Ruby 绑定。
另一种方法是将 MySQL 适配器上的超时设置为高于连接空闲时的超时值。 （我没有记录具体的配置，但我记得它在environment.rb中，并且它是mysql适配器中的某个类变量。）
我不记得这些解决方案中的任何一个是否修复了它，我们转移到了Ubuntu此后不久，此后就再也没有出现过问题。
I had this same problem. The couple options I had narrowed it down to were MySQL adapter related. I was running on Red Hat Enterprise Linux 4 (or 5) and the app would hang after a given amount of idle time.
One suggested solution was to compile native MySQL bindings, I had been using the pure Ruby one.
The other was to set the timeout on the MySQL adapter higher than what the connection would idle out on. (I don't have the specific configuration recorded, but as I recall it was in environment.rb and it was some class variable in the mysql adapter.)
I don't recall if either of those solutions fixed it, we moved to Ubuntu shortly after that and hadn't had a problem since.
检查杂种常见问题解答：
http://mongrel.rubyforge.org/wiki/FAQ
根据我的经验， mongrel 在以下情况下挂起：
您必须通过将以下内容添加到您的environment.rb来更改MySQL驱动程序的超时设置：
ActiveRecord::Base.verification_timeout = 14400（这在常见问题解答的部署部分中有进一步解释）
Check the Mongrel FAQ:
http://mongrel.rubyforge.org/wiki/FAQ
From my experience, mongrel hangs when:
you have to change the timeout settings of your MySQL driver by adding this to your environment.rb:
ActiveRecord::Base.verification_timeout = 14400(this is further explained in the deployment section of the FAQ)
不幸的是，Rails（以及 Mongrel）随着时间的推移消耗了太多内存，并且崩溃是一个已知问题（50K+ Google 条目“Ruby、rails、崩溃、内存”）。 当前的 ruby 解释器有一个属性，它有时根本无法完全将内存返回给系统 - 它可能会重用它拥有的内存，但不会放弃它。
在生产环境中监控、终止和重启 Mongrel 实例的方案有很多 - 例如：（随机选择） 导轨监视器。 在更果断地解决问题之前，其中之一可能是您最好的选择。
Unfortunately, Rails (and thereby Mongrel) using up too much memory over time and crashing is a known problem (50K+ Google entries for "Ruby, rails, crashing, memory"). The current ruby interpreter has the property that it sometimes simply fails entirely to give memory back to the system - it may reuse the memory it has but it won't give it up.
There are numerous schemes for monitoring, killing and restarting Mongrel instances in a production environment - for example: (choosing at random) rails monitor . Until the problem is fixed more decisively, one of these may be your best bet.
我们也遇到过同样的问题。 首先，安装 mongrel_proctitle gem
http://github.com/rtomayko/mongrel_proctitle/tree/master
这个 gem/插件将允许您通过“ps”查看 Mongrel 进程，并且您可以查看 Mongrel 是否挂起。 我们在 Mongrel 中看到的一个问题是，它会愉快地接受连接并将它们排入队列，然后楔入自身。 该插件将帮助您查看 Mongrel 何时被楔入，但随后您必须使用另一个监控应用程序来实际重新启动楔入的 Mongrel，例如 Monit 或 God
您可能还需要考虑在前面放置一个更平衡的反向代理你的 Mongrels 的东西，HAproxy，而不是 nginx、Apache 或 Lighttpd。 通过在 HAproxy 中设置“maxconn 1”，您可以确保队列由 HAproxy 维护，而不是由 Mongrel 维护。 其他反向代理（nginx、Apache、Lighttpd）仅进行循环，这意味着它们可能会无意中加载您的 Mongrel 队列。
我个人选择上帝，因为它更灵活。
tl;dr 安装这个 gem 插件并留意你的 Mongrels。 尝试 Apache+Phusion Passenger。
We have experienced this same issue. First off, install the mongrel_proctitle gem
http://github.com/rtomayko/mongrel_proctitle/tree/master
This gem/plugin will allow you to view the mongrel processes via "ps" and you can see if a Mongrel is hung. An issue we have seen with Mongrel is that it will happily accept connections and enqueue them, then wedge itself. This plugin will help you see when a Mongrel has been wedged but then you must use another monitoring app to actually restart a a wedged Mongrel, something like Monit or God
You might also want to consider putting a more balanced reverse proxy in front of your Mongrels, something HAproxy, instead of nginx, Apache or Lighttpd. With a setting of "maxconn 1" in HAproxy you can assure that the queue is being maintained by HAproxy versus Mongrel. The other reverse proxies (nginx, Apache, Lighttpd) only do round-robin which means that they can load up your Mongrel queue, inadvertently.
My personal choice is God as it is much more flexible.
tl;dr Install this gem plugin and keep an eye on your Mongrels. Try Apache+Phusion Passenger.