Исключение нехватки памяти (сервер Linux Debian)
У меня есть сервер Linux (Debian 10, физическая память 16 ГБ) с тремя работающими докер-контейнерами и двумя Java-программами, выполняющими финансовые расчеты.
Докер-контейнеры:
- Один из них — Nginx.
- Один из них — база данных postgresql.
- Один из них — keycloak (аутентификация).
Так что ничего особенного.
Java-программы:
Эти программы запускаются следующим образом. Обратите внимание на параметр -Xmx10g:
./java/jdk/bin/java -Xmx10g -jar portal-backend-1.0-SNAPSHOT-runner.jar 2>&1 >> log/portal.log &
./java/jdk/bin/java -Xmx10g -jar pea-backend-1.0-SNAPSHOT-runner.jar 2>&1 >> log/pea.log &
SWAP-файл:
Конфигурация моего 24-гигабайтного файла подкачки:
fallocate -l 24G /swapfile
chown root:root /swapfile
sudo chmod 0600 /swapfile
Формат файла подкачки:
mkswap /swapfile
Активируйте файл подкачки:
swapon /swapfile
В файл "/etc/fstab" добавлено:
/swapfile swap swap defaults 0 0
Когда я теперь набираю swapon -s для статуса, я получаю следующее сообщение:
Filename Type Size Used Priority
/swapfile file 25165820 0 -2
ПРОБЛЕМА:
Несмотря на то, что я активировал SWAP file, я получаю out-of-memory exception. Интересно то, что размер файла SWAP всегда составляет 0 КБ. Кажется, что на него никогда не нападут. Что не так?
Прикрепил фотографию htop незадолго до того, как я получил сообщение Out-of-memory-Exception
//РЕДАКТИРОВАТЬ
Кстати, я не понимаю, за что мне минусуют баллы за эту тему
Спасибо за ваш ответ. Ты прав. Серверная часть портала выдает исключение памяти. Программы Java используют внутреннюю библиотеку журналирования. Насколько я понимаю, структура файла logfile.txt выглядит хорошо. Но я также рассмотрю тему ведения журнала поближе. Спасибо
Можете ли вы добавить трассировку стека типичного OutOfMemoryError? Интересный вопрос, на который нужно ответить: является ли ваш собственный код «частью» этой трассировки стека или это полностью сторонний материал? Возможно, у вас есть утечка памяти в вашем коде.
Ответы 1
Чтобы ответить хотя бы на ваш вопрос, почему вы получаете OutOfMemoryError, хотя ваш файл подкачки не используется:
Обе вещи следует рассматривать отдельно. Вы назначили фиксированный максимальный объем оперативной памяти, который будет использоваться вашим процессом Java, с помощью опции -Xmx10g. Ваша JVM не будет запрашивать дополнительную память кучи у операционной системы, а скорее выдаст ту ошибку, которую вы заметили.
Поскольку JVM требуется больше памяти, чем просто куча, на скриншоте htop вы видите, что процесс сбоя использует 13,9 МБ памяти операционной системы. Это кажется возможным, вы могли это немного понаблюдать.
Поэтому, когда на самом деле проблемой является чрезмерное использование кучи, у вас, вероятно, есть утечка памяти в вашей программе (например, циклические ссылки или коллекции, которые никогда не очищаются, хотя вам не нужно их содержимое или что-то подобное), или ей приходится обрабатывать какой-то действительно большой кусок данных, но не был готов сделать это «потоковым» способом (например, для сетевых запросов) и вместо этого пытается выделить всю кучу сразу.
Простое увеличение максимально доступной кучи может временно помочь, но если требуется обработать большой кусок входных данных, следующий, еще больший кусок снова приведет к сбою программы.
Если проблема заключается в утечке памяти, увеличение места в куче, вероятно, приведет к ситуации, когда сбор мусора будет занимать все больше и больше времени, и ваша программа не будет реагировать в то время, пока выполняется сбор мусора.
Чтобы избавиться от этого сбоя, вам придется провести дополнительное расследование, если оно просто «основано на времени» или «на основе ввода». На основе времени означает, что после работы в течение определенного времени программа обычно выходит из строя (при нормальной нагрузке). На основе входных данных означает, что специальные входные данные вызывают сбой (это могут быть большие входные данные или входные данные, которые запускают специальные вычисления).
вы упускаете некоторую информацию: какая из двух Java-программ завершается с ошибкой OutOfMemoryError? Кроме того, ваш метод ведения журнала немного критичен - не из-за проблемы с памятью, а из-за того, что вы перенаправляете стандартный вывод в файл журнала и не используете библиотеку журналирования, у вас возникнут трудности с ротацией журналов, поэтому ваши журналы, вероятно, заполнят жесткий диск. а также будет сложно найти.