Question

正在对我的1个heroku dyno和dev数据库进行一些拉伸（ab）测试，其中包含20个连接限制。

在调用期间（使用squeryl访问数据库时，堆分配正在增加导致R14（内存超过512MB））

我似乎无法重现问题（至少在本地水平）。

有没有办法让heroku堆转储并分析它以获得一些线索？

play2，scala，squeryl和heroku内存泄漏是否存在任何已知问题？

更新

如果我在控制器的末尾做了System.gc，那么一切似乎都很好而且速度较慢...我在那次调用时创建了很多对象但是不应该使用heroku的JVM来处理gc吗？另外如果我定期调度gc调用不释放内存

Answer 1

有一篇很棒的文章可以解决Heroku上的内存问题： https://devcenter.heroku.com/articles/java-memory-issues

在您的情况下，您可以将GC标志添加到JAVA_OPTS以查看内存详细信息。我建议以下标志：

heroku config:add JAVA_OPTS="-Xmx384m -Xss512k -XX:+UseCompressedOops -XX:+PrintGCDetails -XX:+PrintHeapAtGC -XX:+PrintGCDateStamps"

如果您想从JMX获取有关内存的更多信息，还可以添加一个简单的java代理。你还可以看看像New Relic这样的监控插件，如果你想更深入一些，但我认为你应该对旗帜和java代理做得很好。

Answer 2

我也有这个问题，并回答here。

我有同样的问题。 Heroku告诉你机器已经用完了   内存，而不是Java VM。 Heroku Play中确实存在一个错误   2.2部署，启动脚本读取java_opts，而不是JAVA_OPTS。

我通过设置两个来修复它：
heroku config:add java_opts='-Xmx384m -Xms384m -Xss512k -XX:+UseCompressedOops'
heroku config:add JAVA_OPTS='-Xmx384m -Xms384m -Xss512k -XX:+UseCompressedOops'
我还必须设置-Xms，否则我得到一个错误说明最小值和最大值是不相容的。我猜Play2.2使用的默认值高于 384米。

Heroku内存泄漏与Play2 scala

2 个答案: