Java Today

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

Именно поэтому, к жизненным показателям, которые наблюдаются на работающем сервере приложений прежде всего, относятся уровни текущего использования памяти виртуальной машины. Самый важный из них для «долгоиграющих» JVM — Old Gen Used Space по отношению к Old Gen Max Size. Дело в том, что утечки в Perm Gen становятся заметны сразу в силу его небольшого размера, а Young Gen утечек не покажет никогда. Именно в Old Gen накапливаются все те «утёкшие» объекты, на которых начинает буксовать Full GC, останавливая все прикладные потоки.

Именно поэтому, разрабатывая и развивая большие информационные системы на Java, приходится задумываться над тем, как грамотно “слушать пульс” JVM. В этой статье я сделаю небольшой обзор различных подходов к решению этой задачи, после чего обосную свой личный выбор.
Read more…

Статьи jmx, jvm, monitoring

Это завершающая часть серии публикаций, в которых я рассказываю, как реализовать механизм добавления логирования к классам без перезапуска JVM с использованием JVMTI и Javassist. В этой части описывается технология JMX, как инструмент подключения к удалённой виртуальной машине для управления ею. Мы будем использовать JMX для того, чтобы дать команду Java-агенту на осуществление инструментации кода и добавление инструкций логирования. Первая часть серии, в которой обсуждается постановка задачи и общий подход к её решению, размещена здесь. Вторая часть, в которой описываются детали реализации Java-агента JVMTI, размещена здесь. Третья часть, где рассматривается использование библиотеки Javassist для манипуляции байт-кодом, находится здесь.
Read more…

Статьи javassist, jmx, jvmti, logging

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

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

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

• Сборка должна включать тот же код, что сейчас работает на реальном комплексе плюс необходимое логирование, а ветка, в которой ведётся разработка уже обычно ушла вперёд. Это значит, требуются приседания по созданию в вашей системе управления исходным кодом новой ветки от того момента, когда собирался текущий билд (вы ведь ставите метки на каждую выпускаемую версию, не так ли?);
• Обновление кода боевой системы, как правило, требует её перезапуска и некоторого времени простоя, а это не всегда допустимо в текущий момент как по технологическим причинам (необходимость выдерживать SLA), так и по организационным (заявку на установку новой версии требуется согласовывать в инстанциях);

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

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

Read more…

Статьи javassist, jmx, jvmti, logging