Неожиданное поведение JVM в 64-битной Linux - PullRequest
2 голосов
/ 31 июля 2010

Я пытался сравнить поведение моего Java-приложения на 32-битных окнах и 64-битных Linux.

Когда я просматриваю использование памяти через jconsole, я нахожу совершенно другой график использования памяти. На окнах приложение никогда не касается 512 метров. Однако, когда я работаю на 64-битной Linux с 64-битной виртуальной машиной, память постепенно увеличивается и достигает пикового значения около 1000 м очень быстро, и я также получаю oome ошибку, связанную с превышением предельного значения GC. В Linux каждый раз, когда я выполняю GC вручную, он падает ниже 100 м.

Похоже, что GC работает так же хорошо, как и на Windows.

В Windows приложение работает лучше с еще большей нагрузкой.

Как мне найти причину этого?

Я использую jdk1.6.0.13

минимальная куча: 512 м и максимальная куча 1024 м

EDIT:

  • Используете ли вы одинаковые версии JVM для Windows и Linux?

    • yes.1.6.0.13.
  • Используете ли вы одинаковые сборщики мусора в обеих системах?

    • Я заметил в jconsole и вижу, что gc разные.
  • Используете ли вы одинаковые веб-контейнеры в обеих системах?

    • yes.Tomcat.
  • Ваш веб-приложение использует собственные библиотеки?

    • Не уверен. Я использую tomcat + spring + hibernate + jsf.
  • Существуют ли другие различия в конфигурации вашего веб-приложения на двух платформах? Нет

  • Что именно было сообщением об ошибке, связанным с OOME?

    • java.lang.OutOfMemoryError: превышен лимит накладных расходов GC
  • Сколько времени понадобится вашему веб-приложению, чтобы начать плохо себя вести / сообщать об ошибках в Linux?

    • Разница в характере использования видна после того, как я оставляю его запущенным, скажем, 3 часа. Ошибка появляется примерно через день или через 2 дня, так как к тому времени среднее использование памяти становится видимым около 900 мегабайт.

Ответы [ 2 ]

4 голосов
/ 31 июля 2010

64-битная JVM, естественно, будет использовать гораздо больше памяти, чем 32-битная JVM, что и следовало ожидать (в конце концов, внутренние указатели в два раза больше) Вы не можете сохранять одинаковые настройки кучи при переходе с 32-разрядной на 64-разрядную версию и ожидать того же поведения.

Если ваше приложение успешно работает на 512 м на 32-битной JVM, нет никаких причин использовать 64-битную JVM. Единственное обоснование для этого - использовать гигантские размеры кучи.

Помните, что совершенно нормально запускать 32-битную JVM в 64-битной операционной системе. Два не связаны.

1 голос
/ 31 июля 2010

Слишком много неизвестных, чтобы объяснить это:

  • Используете ли вы одинаковые версии JVM для Windows и Linux?
  • Используете ли вы одинаковые сборщики мусора в обеих системах?
  • Используете ли вы одинаковые веб-контейнеры в обеих системах?
  • Ваше веб-приложение использует собственные библиотеки?
  • Существуют ли другие различия в конфигурации вашего веб-приложения на двух платформах?
  • Что именно точно было сообщением об ошибке, связанным с OOME?
  • Сколько времени понадобится вашему веб-приложению, чтобы начать плохо себя вести / сообщать об ошибках в Linux?

Кроме того, я согласен с @skaffman ... не используйте 64-битную JVM, если ваше приложение не требует этого.

...