Heroku内存泄漏问题与Play2 Scala

Question

进行了一些对1个heroku dyno和20个连接限制的开发数据库进行伸缩性(ab)测试。

在使用squeryl访问数据库的调用过程中，堆分配增加导致R14(内存超过512MB)错误。

我无法在本地复现这个问题（至少不到那个级别）。

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

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

更新

如果我在控制器末尾执行System.gc，一切似乎都很好，但会变慢...在该调用中创建了很多对象，但不应该heroku的JVM负责垃圾回收吗？此外，如果定期安排垃圾回收调用不释放内存。

- weakwire

---

你是否使用流式传输（返回数据块）？ - Schleichardt

不，我不这样做。如果我在控制器的末尾执行System.gc，一切似乎都很好，但速度会变慢...我在那个调用中创建了很多对象，但是Heroku的JVM不应该负责垃圾回收吗？此外，如果我定期安排gc调用，它不会释放内存... - weakwire

你在Procfile中使用默认的'JAVA_OPTS'了吗？ - James Ward

JAVA_OPTS => -Xmx384m -Xss512k -XX:+UseCompressedOops - weakwire

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"。

还有一个简单的Java代理程序，如果需要从JMX获取关于内存的更多信息，则可以将其添加到您的进程中。 如果您想要更深入地了解，则可以查看监控插件（如New Relic），但我认为使用标志和Java代理应该就足够了。

- Naaman Newbold

Answer 2

我也遇到过这个问题，我的回答在这里。

I had the same issue. Heroku is telling you the machine is running out of memory, not the Java VM. There is actually a bug in the Heroku Play 2.2 deployment, the startup script reads java_opts, not JAVA_OPTS.

I fixed it by setting both:

heroku config:add java_opts='-Xmx384m -Xms384m -Xss512k -XX:+UseCompressedOops'
heroku config:add JAVA_OPTS='-Xmx384m -Xms384m -Xss512k -XX:+UseCompressedOops'

I also had to set -Xms otherwise I got an error saying the min and max were incompatible. I guess Play2.2 was using a default higher than 384m.

- WearyMonkey

---

FYI。这不再是一个问题。部署了一个Play 2.3应用程序，它很好地接收了JAVA_OPTS。 - Lionel Port