我有一个非常有趣的日志:
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来查找在这个post请求中发送了哪些参数。
或者还有其他方法可以弄清真相吗?
如果这里发生的事情没有办法重演，那么最谨慎的策略是什么?因为这个记忆问题不会自己消失。
遗憾的是，你没有多少办法追溯过去。
你应该做的第一件事是启用Heroku的运行时指标，它将记录你的动态服务器的资源使用情况到应用程序的日志。
一些Heroku插件(如Librato插件)可以解析这些消息，并使用它们来构建随时间变化的内存使用情况图。如果你已经有了一个Librato账户，或者更愿意使用他们的即用即付定价，你可以手动添加Librato作为Heroku的消耗。这应该让你知道你的dyno的内存使用是如何随时间变化的，你可以使用Librato的警报工具来让你知道内存是否经常达到最大值。为了跟踪有问题的请求，你可以使用oink gem，它将内存/活动记录使用信息放在每个请求的日志中。这是一篇展示如何在生产环境中使用链接的博客文章。