Как определить необходимость повышения лимитов памяти для Jboss

Общие симптомы

• Визуализация Jboss по порту 8090 отвечает через раз.

• Страница потоков (транспортный сервлет) по адресу в веб-браузере http://ip_адрес_сервера:8090/SetXRMI/TransportServlet отвечает через раз.

• В логе server.log есть ошибки вида:

  • Java Heap Space;

  • Could not open connection;

  • Unable to get managed connection;

  • No managed connections available;

  • Could not invoke service method;

  • Network error в визуализации.

Определение потребления памяти Jboss на Linux

1. Подключитесь к серверу по SSH с помощью клиента PuTTy или SetConsole.

2. Перейдите в каталог /var/lib/jboss/bin.

Open

3. Запустите средство CLI для Jboss:

Open

4. Выполните команду проверки памяти Jboss:

5. Отобразится вывод по потреблению памяти:

6. Проведите анализ. Например:

• Из результата выполнения команды по выводу потребления памяти сложите значения параметров heap-memory-usage => used и non-heap-memory-usage => used.

• В данном случае реальное потребление памяти Java на сервере занимает 1,3Гб RAM совокупно.

• Для анализа нужно сравнить значение параметров heap-memory-usage => init и heap-memory-usage => used.

  • Если used близко к init, значит, почти вся возможная выделенная память занята и может понадобиться увеличение -Xms и -Xmx в /var/lib/jboss/bin/standalone.conf.

7. Выйдите из CLI Jboss с помощью команды CTRL+D или CTRL+C.

8. Проверьте общее потребление процессом Jboss в системе (вывод в килобайтах):

В данном случае это 1,7 ГБ:

9. Более простой способ проверки общего количества RAM на сервере и её занятость через инструмент htop. Наберите команду htop для его запуска.

10. Дополнительно проверьте RAM с помощью команды free -m.

Идеальное значение - SWAP в идеале должен быть свободен.

• total - общий объём памяти;

• used - занятый объём;

• free - свободное место в памяти.

Выводы

• Сравните значение из пункта 6 (реальное потребление памяти Java) и пункта 8 (выделенная память для Java в ОС):

  • Если значение из пункта 6 близко к значению 8, значит, почти вся возможная память занята,

  • Может потребоваться увеличение лимита в /var/lib/jboss/bin/standalone.conf и возможно добавление RAM на сервер, если запаса места в памяти нет.

Определение потребления памяти Jboss в ОС Windows

1. На сервере SetRetail/SetCentrum запустите сеанс командной строки.

2. Перейдите в каталог {DISK}:\ПАПКА_УСТАНОВКИ_SETRETAIL\bin:

3. Запустите средство CLI для Jboss:

4. Выполните команду проверки памяти Jboss:

5. Отобразится вывод по потреблению памяти:

6. Проведите анализ. Например:

• Из результата выполнения команды по выводу потребления памяти сложите значения параметров heap-memory-usage => used и non-heap-memory-usage => used.

• В данном случае реальное потребление памяти Java на сервере занимает 1,14Гб RAM совокупно.

• Для анализа нужно сравнить значение параметров heap-memory-usage => init и heap-memory-usage => used.

  • Если used близко к init, значит, почти вся возможная выделенная память занята и может понадобиться увеличение -Xms и -Xmx в {DISK}:\ПАПКА_УСТАНОВКИ_SETRETAIL\bin\standalone.conf.bat.

7. Выйдите из CLI Jboss с помощью команды CTRL+D или CTRL+C.

8. Проверьте общее потребление процессом Jboss в системе (вывод в килобайтах). Максимальное значение, это и есть Jboss::

Выводы

• Сравните значение из пункта 6 (реальное потребление памяти Java) и пункта 8 (выделенная память для Java в ОС):

  • Если значение из пункта 6 близко к значению 8, значит, почти вся возможная память занята,

  • Может потребоваться увеличение лимита в {DISK}:\ПАПКА_УСТАНОВКИ_SETRETAIL\bin\standalone.conf.bat и возможно добавление RAM на сервер, если запаса места в памяти нет.

Оптимизация настроек памяти для Jboss

Основная документация

https://crystals.atlassian.net/wiki/spaces/SR10SUPPORT/pages/450461816

Куда обращать внимание

• Windows: {DISK}\Папка_установки_SetRetail10\bin\standalone.conf.bat;

• Linux: /var/lib/jboss/bin/standalone.conf;

Пример оптимизации

1. В файле standalone.conf найдите строку "JAVA_OPTS="$JAVA_OPTS -Xms4096M -Xmx4096M -XX:PermSize=512M -XX:MaxPermSize=512M -XX:MaxMetaspaceSize=1024M" #x64".

2. Добавьте в строку параметр -XX:MaxMetaspaceSize=1024M → перезапустите службу сервера

"JAVA_OPTS="$JAVA_OPTS -Xms4096M -Xmx4096M -XX:PermSize=512M -XX:MaxPermSize=512M -XX:MaxMetaspaceSize=1024M" #x64".

В данном случае для Heap Java (Xms/Xmx) выделено 4ГБ + 1ГБ (MaxMetaspaceSize). Итого: 5 ГБ.

Баланс коннектов от Jboss к PostgresSQL

Основная документация

https://crystals.atlassian.net/wiki/spaces/SR10SUPPORT/pages/450428983

https://crystals.atlassian.net/wiki/spaces/SR10SUPPORT/pages/2118942933

Куда обращать внимание

• Windows: {DISK}\Папка_установки_SetRetail10\standalone\configuration\standalone.xml.

• Linux: /var/lib/jboss/standalone/configuration/standalone.xml.

• PostgresSQL:

  • Windows: {DISK}\Папка_установки_PostgreSQL\11\data\postgresql.conf.

  • Linux:

    • /var/lib/pgsql/11/data/postgresql.conf.

    • Команда ps fax | grep pgsql | grep -v grep.

Последовательность шагов

1. Параметр <max-pool-size>...</max-pool-size> в standalone.xml

• Основная нагрузка по коннектам идёт на базу данных set, для неё нужно выделить ~3/4 от общего пула коннектов, остальные распределить к базам данных set_operday и set_loyal.

• Рекомендуемое количество коннектов можно определить, опираясь на сайзинг из официальной документации PostgreSQL или Jboss согласно топологии.

Пример настроенных коннектов на высоконагруженном сервере (более 10-ти тысяч касс на одном сервере SetCentrum):

set → <max-pool-size>4000</max-pool-size>:

set_loyal → <max-pool-size>150</max-pool-size>:

set_operday → <max-pool-size>400</max-pool-size>:

2. Параметр http max-connections в standalone.xml

1. Проверьте текущее потребление коннектов к Jboss можно командой:

• Windows: netstat -n | find /c /i ":8090"

• Linux: netstat -n -p | grep :8090 | wc -l

2. Например, при значении для баз данных в параметре <max-pool-size>...</max-pool-size> (set = 2000) + (set_loyal = 150) + (set_operday = 400) установите значение 2295 (минус 10%). В этом случае понизьте значение на 10-20% ниже общей суммы коннектов max-pool-size.

3. Параметр max_connections в postgresql.conf

Значение должно быть равно общему пулу коннектов max-pool-size + 20 (на служебные коннекты).

В данном примере, это значение (set = 2000) + (set_loyal = 150) + (set_operday = 400) +20 = 2570.

4. Параметр max_prepared_transactions в postgresql.conf

Повысьте 90% до 100% от значения max_connections в postgresql.conf.

5. Параметр effective_cache_size в postgresql.conf

Размер кэша, хранимого на диске, установить не менее 8000MB.

5. Параметр maintenance_work_mem в в postgresql.conf

Должен быть не меньше 64MB. Допускаются значения: 1GB или 2GB.

Полная оптимизация настроек Postgres

Основная документация

Описание параметров

• max_connection - общий пул коннектов, которые может принять СУБД, включая запросы от Jboss, Zabbix, живых пользователей, например, через pgAdmin или другие источники.

• shared_buffers - рекомендуется установить 25-30% от свободной оперативной памяти (например, при 16GB всего, нормальное значение этого параметра 4GB).

• work_mem - рекомендуемые значения 16MB - 48MB для высоконагруженных серверов. Учитывать, что каждый коннект из пула max_connection занимает значение work_mem, то есть 2000 коннектов по 16MB при одновременном использовании занимают 32GB RAM (должен быть запас в RAM по максимальному значению).

Настройка лимитов в CentOS

Пример в документации

На что обратить внимание

• лимиты открытых приложением файловых дескрипторов;

• лимиты системных файловых дескрипторов;

• лимиты количества запущенных процессов.

Что проверить?

Системные лимиты количества процессов для Jboss

Проверки для повышения лимита

1. Проверьте текущие системные лимиты для Jboss (настройка max user processes по-умолчанию 4096):

2. Проверить текущее количество открытых процессов (для Jboss)

Если полученное значение подходит близко к max user processes, тогда увеличьте его до рекомендуемого 16384.

3. Выполните команду sudo mcedit /etc/security/limits.conf → добавьте строку ниже после # End of file → сделайте клавишей ENTER новую строку после добавленной → перезапустите службу сервера приложений.

Проверка существующих ограничений максимального количества открытых файлов

1. Выполните команду для процессов Java (команда требует повышение привилегий через sudo или root):

2. Проверьте разницу между значениями Max open files и Currently open files:

Например: Max open files = 4096, Currently open files = 3875.

Если пределы по одному из процессов подходят к лимиту, тогда настройте их.

3. Откройте Midnight Commander командой mc → откройте на редактирование файл в завимисомти от названия продукта /etc/systemd/system/название_продукта.service.

4. В блок [Service] добавьте параметр LimitNOFILE=32768 (пример конфигурационного файла SetAgent):

5. Перезапустите службу продукта: