Увеличение непрерывной памяти подкачки

1

У меня есть веб-приложение, работающее в стеклянной планете в RHEL. Для приложения они установлены:

Heap Memory:4GB
Perm Gen:1GB

JConsole показывает:

heap memory - 500mb
non heap memory - 350mb 
threads =378

Лучшие шоу:

PID   User       PR  NI  VIRT RES  SHR S  %CPU  %MEM   TIME+   COMMAND
17948 root       20   0 12.8g 1.9g  22m S  1.5   16.0  14:09.11 java

Начиная с самого начала процесс потребляет 12,8G.

Top также показывает:

Mem:  12251392k total, 11915584k used,   335808k free,    47104k buffers
Swap:  8322944k total,  6747456k used,  1575488k free,   177088k cached

Проблема заключается в том, что пространство подкачки постоянно увеличивается. Когда свободное место подкачки не остается, веб-приложение перестает отвечать.

  1. Процесс убийства не уменьшает пространство подкачки, но только после перезагрузки компьютера. Зачем?
  2. Почему процесс запускает 12,8 ГБ виртуального пространства при запуске?
  3. Как подойти, чтобы решить эту проблему?

Обновить:

Выход jconsole (записанный в течение 24 часов) показывает, что память кучи и память без кучи не сильно увеличились. Несмотря на то, что пространство подкачки, добавленное на 1,5 Гб за тот же период: выход Jconsole

Теги:
memory
glassfish
virtual-memory
swap

1 ответ

0

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

Насколько мне известно, система подкачки Linux не так проста. Ядро сначала сворачивает неактивную память, возможно, другую память приложения, чтобы предоставить GF достаточные ресурсы. Это не будет немедленно заменено обратно, когда GF будет завершен. Вы можете попытаться выполнить swapoff -a чтобы заставить Linux поменять местами, но не забудьте снова включить его с помощью swapon -a.

Пространство VIRT из-за верхней мансарды:

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

Я сомневаюсь, что отчеты ОС по использованию памяти настолько хороши, что можно отлаживать ваше приложение Java. Вы должны заглянуть в свою JVM-память с помощью таких инструментов, как JVisualVM (часть Oracle JDK). Наблюдайте за ходом использования памяти в течение соответствующего периода времени.

Далее вы можете попытаться проанализировать дамп кучи с помощью инструмента, такого как Eclipse Memory Analyzer (MAT). У MAT есть несколько приятных отчетов, которые могут помочь найти утечки памяти. Если ваше использование памяти приложения постоянно растет, похоже, утечка. В противном случае у него просто недостаточно памяти.

  • 0
    Спасибо! Я обновил вопрос с выходом Jconsole. swaoff -a выдает эту ошибку: swapoff: / dev / mapper / VolGroup-lv_swap: swapoff fail: невозможно выделить память. Я полагаю, потому что в ОЗУ недостаточно места для размещения содержимого подкачки.
  • 0
    Ошибка подкачки: да, похоже, вашей машине не хватает физической памяти. Использование кучи памяти на вашем скриншоте выглядит нормально для меня на этом таймфрейме. Как насчет использования perm gen / non heap?
Показать ещё 2 комментария

Ещё вопросы

Сообщество Overcoder
Наверх
Меню