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

Речь пойдет о бизнес-приложениях с одним сервером Java-приложения и одним сервером базы данных PostgreSQL, в каждом из которых одновременно работают от 500 до 2000 сотрудников компании. Приложения разработаны на базе открытой и бесплатной платформы lsFusion (пример приложения), но большинство описанных проблем и настроек не являются специфическими именно для нее.

Архитектура

В нашем случае сервер приложения представляет собой простую службу, которая запускает один java-процесс, обрабатывающий подключения по RMI-протоколу. Он общается как с каждым десктоп-клиентом, установленным у конкретных пользователей через Web Start, так и с веб-сервером Apache Tomcat, которые реализует веб-интерфейс. С другой стороны, сервер приложения обращается к PostgreSQL для непосредственной работы с данными.

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

Ресурсы

Основные ресурсы, которые потребляет сервер приложений - это CPU и память. Обращения к диску в нашем случае практически не идет, поэтому для сервера приложений можно спокойно выделять маленькие и медленные диски.

Сервер приложений lsFusion (как и большинство других java-приложений) использует CPU для двух целей : обработка запросов клиентов и сборка мусора. 

Специфика платформы lsFusion заключается в том, что сервер приложений является своего рода “прослойкой”, которая не хранит в себе пользовательских данных, а фактически только выполняет SQL-запросы к серверу БД, и передает их результат клиенту. Параллелизм в этом процессе практически не используется, поэтому один клиент в большинстве случаев использует один поток. Таким образом, количество используемых CPU для пользователей прямо пропорциональна количеству пользователей в системе.

В приложении на платформе lsFusion логика системы задается декларативно при помощи встроенного языка. В ходе работы на ее основе постоянно генерируются SQL-запросы при помощи достаточно сложных алгоритмов, чье выполнение составляет значительную часть загрузки CPU. Этот процесс мы называем “компиляцией запросов”. Важно понимать, что в случае очень сложной логики, генерация SQL запроса может занимать до нескольких секунд, что в свою очередь может приводить к задержкам для пользователей. Чтобы уменьшить нагрузку на процессор и ускорить процесс, “скомпилированные” SQL-запросы сохраняются в LRU-кэш, который является общим для всех пользователей. Таким образом одно и то же действие у разных пользователей может выполняться разное время. Данные из кэша удаляются по истечению определенного интервала времени при отсутствии к ним обращения. Этот интервал динамически изменяется в зависимости от загрузки памяти сервера приложений.

Сборка мусора

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

Java-приложение, в отличие от PostgreSQL, как правило, работает как один процесс (если приложение само не создает новых) с большим количеством потоков. Самую большую часть  используемой памяти этим процессом занимает так называемая куча, в которой находятся все пользовательские объекты. Ее размер задается в параметрах запуска java-процесса и не может изменяться в ходе работы. Параметр Xms задает начальный размер кучи на запуске, а Xmx - максимальный размер. Мы, как правило, задаем их одинаковыми, так как никаких других служб на этих виртуальных машинах нет, и можно отдать серверу приложений сразу всю доступную память.

В любой момент времени память в куче занята тремя категориями объектов.

1. Постоянные объекты. Они создаются на старте приложения и необходимы для работы платформы. Их размер зависит только от сложности логики приложения. Соответственно, чем больше размер кучи, выделенной для сервера приложений, тем таких объектов меньше в процентном соотношении.

2. Кэши. Основную часть кэшей занимает кэш, в которым хранятся сгенерированные запросы. Его размер постоянно изменяется в зависимости от действий пользователей и интервала очистки. Туда попадают новые запросы, а старые по мере выпадания из интервала кэша автоматически собираются сборщиком мусора. Так как свойств в приложении могут быть десятки тысяч, то различных вариантов запросов могут быть сотни тысяч, и даже миллионы. По этой причине кэш занимает много памяти, и часто подвергается ротации.

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

Специфика работы Java-приложений заключается в том, что нехватка памяти чаще всего приводит не к завершению его работы, а к торможению. По мере того как память начинает заканчиваться, любой алгоритм сборки мусора начинает работать более активно, значительно нагружая CPU и останавливая работу пользовательских потоков. По этой причине, когда начинаются жалобы сразу всех пользователей на тормоза, в первую очередь мы смотрим на логи сборщика мусора. Для включения такого логирования в командную строку запуска приложения (где задаются и Xmx с Xms) добавляется следующая строка :

-Xlog:gc:file=logs/memory.log:tags,uptime,time,level:filecount=10,filesize=50m
-Xlog:gc*,gc+ergo+cset=info,gc+ref=info,gc+heap=info,gc+age=info,gc+phases=info:file=logs/gc.log:tags,uptime,time,level:filecount=10,filesize=50m

Для приложения на платформе lsFusion ее нужно добавить в параметр FUSION_OPTS файла /etc/lsfusion5-server/lsfusion.conf. Вместо logs/memory.log и logs/gc.log можно выбрать любой другой путь, в том числе и абсолютный. Первая часть строки включает логирование основных событий сборки мусора в файл memory.log, а вторая - более детальное логирование в gc.log, необходимое для глубокого анализа работы алгоритма сборки мусора. 

На практике мы используем два алгоритма сборки мусора : G1 и ZGC. По умолчанию, начиная с Java 11 используется сборщик мусора G1. ZGC рекомендуется использовать, только начиная с Java 17.

G1

Одной из важных особенностей данного алгоритма является, так называемый процесс Stop The World (STW). В этот момент все пользовательские процессы фактически приостанавливаются на определенное время для выполнения манипуляций с памятью.

Если немного упростить, то у этого сборщика мусора есть два режима работы : Normal и Mixed. В первом уничтожаются только “временные” объекты, которые были созданы совсем недавно и быстро стали не нужны (а в Java таких генерируется большое количество). В ходе этого процесса выполняется STW на небольшой промежуток времени. По умолчанию, он таргетируется на 200 мс, но в редких случаях может увеличиваться. В нормальном режиме лог работы сборщика мусора (в memory.log) будет выглядеть так :

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

Как только использованная память достигает определенного порога параллельно запускается подготовительный процесс Concurrent Mark Cycle для сборки уже и “старых” объектов. К этим объекта относятся как объекты, выпавшие из кэшей, так и временные объекты, которые по какой-то причине просуществовали долгое время.

После его завершения будет запущена сборка мусора по всем объектам (Mixed) :

В данном примере возникают не очень продолжительные паузы всех процессов (максимум 508мс), тем не менее они могут быть заметны пользователям, так как возникают последовательно за короткий интервал. Проблема алгоритма G1 заключается в том, что по мере роста размера кучи (увеличения Xmx) паузы во время Mixed сборки увеличиваются значительно быстрее. Это приводит к тому, что при 120ГБ выделенной памяти на практике сервер может останавливаться на 2-4 секунды, что уже очень некомфортно для пользователей. Частично это можно решить за счет увеличения параметра G1RSetRegionEntries (добавив в параметры запуска строку -XX:G1RSetRegionEntries=4096). Однако, это не полностью устраняет проблему, и фактически использовать больше 120ГБ с G1 для lsFusion проблематично (хотя в других java-приложениях может быть и больше, так как там по другому может использоваться память).

В нормальном режиме работы G1 очистка памяти должна происходить не медленнее, чем создание новых объектов. По мере увеличения потребления памяти, начинают чаще происходить Mixed сборки мусора, что увеличивает скорость очистки памяти, но в то же время увеличивая нагрузку на CPU. В случае, если все-таки память переполнится, например, во время Concurrent Markup Cycle, то происходит самое “страшное” : запускается Full GC. В этот момент все приложение целиком останавливается, и G1 начинает процесс полной сборки, чтобы очистить все, что может. Выглядит в логах это вот так :

В итоге все пользователи зависают на 25 секунд, но память при этом очищается с 100ГБ до 40ГБ.

Скорость сборки мусора также зависит от количества потоков, которые ей занимаются. Если для сборки во время STW (в частности при Full GC) задействуется сразу достаточное количество потоков ( по умолчанию, ⅝ всех логических ядер, и увеличение вряд ли поможет), то в обычном режиме используется четверть всех ядер. Увеличить их количество можно при помощи опции ConcGCThreads (поставить в строке запуска -XX:ConcGCThreads=<кол-во потоков>). Однако, слишком большое значение может приводить к тому, что ядер не будет хватать для пользовательских процессов. Поэтому с изменением этого параметра надо быть аккуратным.

При установке размера кучи с использованием G1 следует учитывать, что сам алгоритм использует достаточно большие структуры для хранения внутренней информации. Поэтому реальный объем потребляемой памяти может на 20-30% превышать выделенный размер кучи. Соответственно, выставлять параметр Xmx надо с учетом этого. Например, если выделить для кучи 100ГБ, то процесс может использовать 130ГБ. Если в операционной системе не будет хватать памяти процессу, то либо сработает oom_killer, убив все приложение, или пойдет использование swap.

ZGC

Для относительно небольших приложений стандартного сборщика мусора G1, как правило, достаточно. Когда количество одновременно работающих пользователей начинает превышать одну тысячу, то для того, чтобы избежать длительных пауз во время STW, мы используем ZGC. Чтобы его включить надо в параметры запуска добавить строку -XX:+UseZGC.

Следует отметить, что при больших размерах кучи часто бывает нужно поднимать параметр max_map_count. Это можно обнаружить в логах memory.log. При старте сервера в нем будет следующее предупреждение :

Если этого не сделать, то сервер запустится, но через какое-то время работы просто внезапно упадет.

Преимущество алгоритма ZGC в том, что у него очень низкие глобальные паузы STW (несколько миллисекунд). Однако, из-за этого скорость сборки мусора у него ниже по сравнению с G1 (за все надо платить), что требует большего размера кучи. В то же время, ZGC не потребляет так много дополнительной памяти, как G1. Таким образом, если для G1 было выделено 120ГБ памяти, и он справлялся, то даже 150ГБ для ZGC может быть недостаточно. Необходимый размер мы обычно вычисляем опытным путем, но плюс в том, что ZGC может эффективно работать на очень больших объемах памяти. Учитывая, что на современных серверах памяти сейчас много, то можно выделить с запасом (мы выделяли пока максимум 300ГБ).

Когда ZGC не успевает очищать память быстрее, чем она используется, блокируются до следующего процесса очистки не все приложение, а лишь те процессы, которые создают новые объекты. В логах memory.log это выглядит следующим образом :

В данном примере паузы незначительные, но в случае большой перегрузки памяти они могут составлять несколько секунд. Таким образом, с алгоритмом ZGC в отличие от G1 (с STW) пользователи “зависают” неравномерно, и у кого-то все может работать хорошо, а у кого-то будут тормоза. Также в ZGC отсутствует аварийный процесс полной очистки, поэтому в случае критических ситуаций выход в нормальный режим работы у него занимает значительно дольше, чем у G1.

Кэши

В ходе работы загрузка памяти непостоянна, и могут быть моменты, когда резко увеличивается генерация новых объектов, что приводит к тому, что сборка мусора перестает успевать. Когда такое происходит, платформа lsFusion пытается автоматически уменьшать размеры кэшей запросов (как самые большие), чтобы больше памяти оставалось под новые временные объекты. Для этой цели платформа слушает уведомления об окончании сборки мусора, и, если после ее завершения занятая память становится больше какого-то порога, то уменьшается интервал хранения LRU-кэшей запросов. 

Если, наоборот, занятая память становится меньше какого-то порога, то интервал увеличивается. Информация об этом процессе записывается в файл logs/lru.log : 

Строка DEC MULTI 1.371012546330251 показывает, что интервал хранения логов был снижен до 1.37 часа, как только использованная память после сборки (68127248392 байт) стала выше порога (67645734912 байт). Пороговый интервал использования памяти и скорость увеличения/снижения интервала задаются в настройках платформы.

Большое потребление памяти

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

Платформа lsFusion умеет подсчитывать сколько новой памяти использует каждый поток за определенный интервал и постоянно записывает эту информацию в файл logs/allocatedbytes.log :

Для защиты от переполнения памяти в платформе есть определенные пороги, которые стараются предотвратить такую ситуацию. Например, есть порог по памяти, при превышении которого, результаты уже выполненного запроса не будут передаваться на сервер приложений, а пользователю будет выдано сообщение с ошибкой (TOO LARGE QUERY ROWS). Также платформа умеет автоматически уничтожать потоки, которые генерируют слишком много памяти за определенный интервал. 

Открытые файлы

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

По умолчанию, во многих ОС порог для одного процесса составляет всего 4096 файлов. При этом каждое сетевое подключение также попадает в "открытые файлы". Каждый пользователь (а их может быть больше 2000) или входящий/исходящий HTTP-запрос могут создавать новые соединения. В случае превышения порога, во время создания соединения или открытия файла потокам начнет приходить ошибка "Слишком много открытых файлов" ("Too many open files"). 

Для решения описанной проблемы лучше всего поднять пороги непосредственно для службы, которая запускает java приложение. В нашем случае мы в файле /usr/lib/systemd/system/lsfusion5-server.service добавляем следующий блок :

[Service]
LimitNOFILE=16384
LimitNOFILESoft=16384

Слишком большие пороги также не имеет смысла выставлять, так как если открытых файлов становится больше 16К, то явно что-то идет не так, и лучше выяснить и исправить первопричину проблемы.

Swap

Если выделить серверу приложений слишком большой размер кучи, то дальше возможны два варианта, когда операционной системе перестанет хватать памяти для java-приложения. Либо ОС завершит этот процесс при помощи oom_killer как главного и единственного претендента на смерть. Либо, если включен swap, то память начнет сбрасываться в него. И это тоже очень плохо. 

Дело в том, что во время любой сборки мусора идет реорганизация памяти. В частности, она идет и во время действий при STW, когда останавливаются все пользовательские потоки. Если в этот момент окажется, что нужный участок памяти находится в свопе, то во время его загрузки из свопа приложение будет висеть для всех. Кроме того, java никак не учитывает использование свопа и не отдаст уже выделенную память. То есть в своп уйдет какой-то другой кусок памяти, который потом также повиснет при следующей реорганизации памяти, и процесс торможения будет повторяться. Поэтому нужно всячески стараться избегать использования свопа на сервере приложений. Проще всего в таком случае просто понижать Xmx.

Тем не менее, все-таки лучше, чтобы приложение начало притормаживать, чем полностью завершилось, и все пользователи потеряли несохраненные данные. По этой причине мы все-таки стараемся не отключать swap.

Также в swap операционная система может скидывать неиспользуемую память просто в ходе работы. Это регулируется системным параметром vm.swappiness и измеряется в процентах. Чтобы это максимально предотвратить, обычно мы его выставляем в /etc/sysctl.conf равным 1 или 0 :

vm.swappiness = 1

Резюме

Главный параметр, от которого зависит работа Java-приложения - это максимальный размер кучи (Xmx). Подбирать его нужно аккуратно опытным путем, так как слишком большое значение приведет к торможению из-за попадания памяти в своп. Слишком маленькое значение не будет утилизировать всю память сервера, а также будет приводить к более частым сборкам мусора и увеличению загрузки CPU. Чем больше CPU на сервере, тем быстрее за счет параллелизма будет идти сборка мусора, и тем меньше нужно памяти. Чем больше памяти на сервере, тем реже нужно будет собирать мусор, и тем меньше будет загрузка CPU.

Сборщик мусора G1 достаточно эффективен, но у него длинные паузы всего сервера приложений. По этой причине его можно использовать на серверах с общей памятью до 150ГБ, а далее лучше переключаться на ZGC (есть еще Shenandoah, но мы его пока нигде не пробовали). Рекомендуется настраивать логирование работы сборщика мусора, и смотреть в эти логи в первую очередь, если сразу все пользователи жалуются на медленную работу программы, или наблюдается очень высокая загрузка CPU.