Приложение Grails слишком много памяти

Question

Tomcat 5.5.x и 6.0.x

Grails 1.6.x

Java 1.6.x

ОС CentOS 5.x (64 бит)

VPS-сервер с памятью 384M

JAVA_OPTS: пробовал много комбинаций, включая следующие

export JAVA_OPTS = '- Xms128M -Xmx512M -XX: MaxPermSize = 1024m'

экспортJAVA_OPTS = '- сервер -Xms128M -Xmx128M -XX: MaxPermSize = 256M'

(В соответствии с рекомендациями http://www.grails.org/Deployment)

я создал пустое приложение Grails, т.е. просто с помощью команды grails создать-app, а затем WARE его

Я запускаю Tomcat на VPS-сервере

Когда я просто запускаю сервер Tomcat без развернутых приложений, свободная память составляет около 236 МБ, а используемая память - около156M

При развертывании моего «пустого» приложения потребление памяти резко возрастает до 360M, и, наконец, экземпляр Tomcat уничтожается, как только он занимает всю свободную память

Как вы уже видели, мойприложение настолько легкое, насколько это возможно.

Не уверен, почему потребление памяти такое жевысокая.

Я на самом деле устраняю неполадки в реальном приложении, но сузился до этого сценария, который легче поделиться и объяснить.

ОБНОВЛЕНИЕ Я тестировал то же самое«пустое» приложение на моем локальном Tomcat 5.5.x под Windows, и оно работало нормально

Потребление памяти процессом Java увеличилось с 32 М до 107 МБ.Но он не вылетел и остался в допустимых пределах

Так что охота за ответом продолжается ... Интересно, что-то не так с моей коробкой Linux.Не уверен, что хотя ...

ОБНОВЛЕНИЕ 2 Также посмотрите это http://www.grails.org/Grails+Test+On+Virtual+Server

Это подтверждает мое убеждение, что мое простое пустое приложение должно работать в моей конфигурации.

Answer 1

Неправильно пытаться запускать долго работающее Java-приложение в минимально возможной памяти.Сборщик мусора и, следовательно, приложение будут работать намного эффективнее, если в нем будет много обычной кучи памяти.Дайте приложению слишком мало кучи, и оно будет тратить слишком много времени на сбор мусора.

(Это может показаться немного нелогичным, но поверьте мне: эффект предсказуем в теории и заметен на практике.)

РЕДАКТИРОВАТЬ

В практическом плане я бы предложил следующий подход:

1. Начните с запуска Tomcat + Grails с столько памяти, сколько вы можете дать ему , чтобы выесть что-то, что работает.(Установите размер permgen по умолчанию ... если у вас нет четких доказательств того, что Tomcat + Grails исчерпывает permgen.)

2. Запустите приложение на некоторое время, чтобы привести его в устойчивое состояниеи выяснить, каков его средний рабочий набор.Вы должны быть в состоянии выяснить это с помощью профилировщика памяти или с помощью регистрации GC.

3. Затем установите размер кучи Java, скажем, дважды измеренный размер рабочего набора или более.(Это то, что я пытался изложить выше.)

На самом деле, есть другая возможная причина ваших проблем.Даже если вы говорите Java использовать кучи заданного размера, может случиться так, что не сможет сделать это.Когда JVM запрашивает память у ОС, существует несколько ситуаций, когда ОС отказывает.

• Если на машине (реальной или виртуальной), на которой вы работаете, ОС нетЧем больше нераспределенной «реальной» памяти и пространство подкачки операционной системы полностью выделено, ей придется отклонять запросы на получение дополнительной памяти.

• Также возможно (хотя и маловероятно), чтоограничения памяти процесса в силе.Это может привести к тому, что ОС будет отклонять запросы, превышающие этот предел.

Наконец, обратите внимание, что Java использует больше виртуальной памяти, которую можно учесть простым сложением чисел стека, кучи и permgen.Есть память, используемая исполняемыми файлами + DLL, память, используемая для буферов ввода-вывода, и, возможно, другие вещи.

Answer 2

Можете ли вы попробовать развернуть веб-приложение для мониторинга tomcat, например psiprobe и посмотрите, где используется память?

Answer 3

384 МБ довольно мало. Я запускаю небольшое приложение Grails на VPS 512 МБ на веб-сайте enjoyvps.net (никак не связан, просто доволен клиентом), и оно работает уже несколько месяцев, чуть менее 200 МБ. Я использую 32-битный Linux и JDK, хотя нет смысла тратить всю эту память на 64-битные указатели, если у вас все равно нет доступа к большому количеству памяти.