Хероку утечка памяти с Play2 scala

Проделал некоторый тест растяжения (ab) для моей 1-й базы героя и базы данных dev с 20 ограничениями на соединение.

Во время вызовов (которые получают доступ к базе данных с squeryl, распределение кучи увеличивается, вызывая R14 (память более 512 МБ))

Я не могу воспроизвести проблему (на этих уровнях хотя бы локально).

Есть ли способ получить дамп кучи геройку и проанализировать его, чтобы получить подсказку?

Есть ли какие-либо известные проблемы с потерей памяти play2, scala, squeryl и heroku?

Обновление

Если я делаю System.gc в конце контроллера, все кажется прекрасным и медленным... Я создаю много объектов при этом вызове, но не должен ли JVM Heroku заботиться о gc? Также, если я планирую gc-вызов периодически, не освобождайте память

ОТВЕТЫ

Ответ 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-агентом.

Ответ 2

У меня тоже была эта проблема, и я ответил здесь .

У меня была такая же проблема. Heroku говорит вам, что машина заканчивается памяти, а не виртуальной машины Java. На самом деле есть ошибка в игре Heroku 2.2, запуск script читает 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, иначе я получил сообщение об ошибке min и max были несовместимы. Я предполагаю, что Play2.2 использовал значение по умолчанию выше, чем 384M.