Сколько раз мне приходилось настраивать GC, чтобы вылечить приложение, которое время от времени подвергается атаке и временно перестает выполнять свои функции.
Работа, я скажу, не самая занимательная и требует хорошего знания матчасти.
В этой теме я опишу, какие еще есть способы решения этой проблемы.
Если ваша java Heap больше нескольких гигов (в зависимости от требований приложения), то никакие настройки GC вам не помогут. Будь то CMS, JRocket или даже G1, который находится в разработке уже сто лет, вас в этом случае ничто не спасет. Хотя нет, на горизонте есть один продукт: виртуальная машина Java от Azul. Но это решение опять-таки платное и требует собственного оборудования или виртуализации, что опять-таки имеет свои накладные расходы.
Если кому-то интересно, подробнее можно прочитать в комментариях к моему посту.
Что может сделать обычный Java-разработчик, чтобы исправить приложение, требующее значительный объем памяти? Первым делом, конечно, нужно выяснить, есть ли утечки памяти.
Может быть, они настолько велики или память используется настолько неэффективно, что, устранив утечку, вы автоматически решите свои проблемы.
Если у вас есть возможность периодически перезапускать приложение или существует временной интервал, когда вы можете вызвать Full GC. Учитывая определенную схему работы с памятью, когда вы можете сохранить размер молодого поколения небольшим и иметь разумный поток объектов, попадающих в старое поколение, вы можете увеличить размер своей кучи до такого значения, которое будет накапливаться в памяти.
Old Gen будет происходить только в те моменты, когда вы можете себе это позволить.
Но этот вариант больше похож на хак, чем на мейнстрим.
Еще один очень популярный метод сокращения пауз GC — разделение вашего приложения на несколько частей, которые будут выполняться на разных JVM. Большинство людей в настоящее время идут по этому пути.
На самом деле это хорошее решение, если ваша система слабосвязана и хорошо разделена логически.
Но любой дистрибутив так или иначе существенно усложняет вашу архитектуру и замедляет связь, поэтому подходит не для каждого приложения.
Также как вариант можно рассмотреть удаленный кеш, написанный на чем-то безголовом.
Например, мемкеш.
Но здесь опять же, как и в предыдущем решении, мы получаем распределённую систему и замедление работы приложения, так как теперь объекты нужно будет сериализовать и передавать через сокеты.
Кроме того, мы получаем компонент, не написанный на Java, поддержка которого может стать затруднительной для обычного Java-программиста.
Довольно долгое время список возможных решений на этом практически заканчивался, оставляя Java-программистов в затруднительном положении.
Но в последнее время все чаще начинает появляться решение на основе так называемого прямого буфера, когда дополнительная память выделяется непосредственно внутри Java-процесса, но вне кучи, что позволяет иметь приложение, полностью написанное на Java, легко использовать память.
десятков гигабайт и избежать проблем, возникающих при распространении.
Подробнее об этом подходе вы можете прочитать в статье Кэш вне кучи Java .
Также примите участие в опрос на эту тему .
Теги: #java #heap #gc #gc #java
-
Курсы По Ит-Поддержке - Insights
19 Oct, 24 -
Ноутбук Acer Trave-As5740G-372G32Mn
19 Oct, 24 -
Mastermindcms2 — С Чего Начать?
19 Oct, 24 -
Инструкции — Odin Thunderbird На Двух Ос
19 Oct, 24 -
Urban Airship Закрывает Бесплатную Лицензию
19 Oct, 24
