我有一段非常有趣的日志：
173 <190>1 2014-08-10T16:27:04.714496+00:00 d.b94e55d3-c99e-4547-865d-708591bea1ee app web.2 - - Started POST "/mandrill_inbound" for 54.184.37.188 at 2014-08-10 16:27:04 +0000
128 <45>1 2014-08-10T16:27:04.928835+00:00 d.b94e55d3-c99e-4547-865d-708591bea1ee heroku web.2 - - Process running mem=665M(130.0%)
129 <45>1 2014-08-10T16:27:04.929061+00:00 d.b94e55d3-c99e-4547-865d-708591bea1ee heroku web.2 - - Error R14 (Memory quota exceeded)
摘要为Process running mem=665M(130.0%)
相关位：
2014-08-10T16:27:04.745084+00:00 d.b94e55d3-c99e-4547-865d-708591bea1ee heroku router - - at=info method=POST path="/mandrill_inbound" host=www.myproject.com request_id=cfde9bb3-2cd8-4045-b3f1-235c0d4c91c3 fwd="54.184.37.188" dyno=web.2 connect=2ms service=202ms status=200 bytes=408
现在我可以使用此请求ID request_id=cfde9bb3-2cd8-4045-b3f1-235c0d4c91c3来确定在此帖子请求中发送了哪些参数。
或者还有另一种方法可以解决这个问题吗？
如果没有办法重播这里发生的事情，那么最谨慎的策略是什么呢？因为这个记忆问题本身并没有消失。
答案 0 :(得分：0)
不幸的是，你可以回顾性地做很多事情。
您应该做的第一件事是启用Heroku's runtime metrics，它会将您的dynos的资源使用情况记录到应用程序的日志中。
一些Heroku插件（例如Librato插件）可以解析这些消息并使用它们来构建内存使用情况的图表。如果您已拥有Librato帐户，或者宁愿使用pay as you go pricing，则可以manually add Librato as a Heroku drain。这可以让您了解您的dyno内存使用情况如何随时间变化，并且您可以使用Librato的警报工具让您知道内存是否频繁出现。
为了跟踪有问题的请求，您可以使用oink gem将内存/活动记录使用信息按请求放入日志中。 Here's a blog post that shows how to use oink正在制作中。