Эксплуатационные затраты на профилирование веб-приложения в производстве

Я пытаюсь решить проблемы с производительностью с помощью большого и сложного веб-приложения tomcat java. Самая большая проблема на данный момент заключается в том, что время от времени всплеск использования памяти и приложение становятся невосприимчивыми. Я исправил все, что я могу исправить, с помощью профилей логов и байесовского анализа файлов журнала. Я рассматриваю возможность запуска профилировщика на сервере Tomcat.

Примечание для читателя с мягкой чувствительностью:

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

Вопросы:

Я ищу ответы, которые работают либо для веб-приложения java, работающего на tomcat, либо для ответа на этот вопрос агностическим языком.

Каковы затраты на профилирование?
Любые другие причины, по которым плохой идеей является дистанционное подключение и профилирование веб-приложения на производстве (странные режимы отказа, проблемы с безопасностью и т.д.)?
Сколько будет выполняться профилирование печати в памяти?
В частности, есть ли инструменты профилирования java, которые имеют очень низкие эксплуатационные расходы?
Любые инструменты профилирования java, предназначенные для профилирования веб-приложений?
Есть ли у кого-то тесты производительности для профилирования с помощью visualVM?
В каких размерах приложения и наборы данных можно визуализировать масштаб VM?

Ответ 1

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

Чтобы ответить на ваши вопросы:

Накладные расходы:. Это выборочные профилировщики, то есть они генерируют таймер или счетчик производительности прерывает некоторый регулярный интервал, и они смотрят, какой код в настоящее время выполняется. Они используют это для построения гистограммы того, где вы тратите свое время, и накладные расходы очень низки (1-8% - это то, что они утверждают) для разумные интервалы выборки.

Посмотрите этот график частоты дискретизации против служебных данных для OProfile. Вы можете настроить частоту дискретизации для более низких накладных расходов, если по умолчанию вам не по душе.
Использование в производстве: Единственное предостережение от использования OProfile заключается в том, что вам нужно будет установить его на свою производственную машину. Я считаю, что поддержка ядра в Red Hat с RHEL3, и я уверен, что другие дистрибутивы поддерживают его.
Память: Я не уверен, что такое точный объем памяти OProfile, но я считаю, что он хранит относительно небольшие буферы и иногда выгружает их в файлы журнала.
Java: OProfile включает профилирующие агенты, поддерживающие Java, и которые знают о коде, запущенном в JIT. Таким образом, вы сможете видеть вызовы Java, а не только вызовы C в интерпретаторе и JIT.
Веб-приложения: OProfile - это профилировщик на системном уровне, поэтому он не знает о таких вещах, как сеансы, транзакции и т.д., которые будут иметь веб-приложение.

Тем не менее, это полнофункциональный профилировщик, поэтому, если ваша проблема с производительностью вызвана плохими взаимодействиями между ОС и JIT, или если это в какой-то сторонней библиотеке, вы сможете увидеть это, потому что OProfile профилирует ядро и библиотеки. Это преимущество для производственных систем, так как вы можете ловить проблемы, связанные с неправильными конфигурациями или особенностями производственной среды, которые могут отсутствовать в вашей тестовой среде.
VisualVM: Не уверен в этом, так как у меня нет опыта работы с VisualVM

Здесь учебник об использовании OProfile для поиска узких мест производительности.

Ответ 2

Я использовал YourKit для профилирования приложений в среде с высокой нагрузкой, и, хотя это, безусловно, было удачным, было легко приемлемым. Yourkit делает большое дело в том, что он может сделать это неинвазивным образом, например, выборочно отключать некоторые профилирующие функции, которые стоят дороже (на самом деле это скользящая шкала).

Мой любимый аспект заключается в том, что вы можете запускать виртуальную машину с запущенным агентом MyKit и иметь нулевое влияние на производительность. это только когда вы подключаете GUI и начинаете профилирование, что оно имеет эффект.

Ответ 3

Нет ничего плохого в профилировании производственных приложений. Если вы работаете с распределенными приложениями, бывают случаи, когда исключение outofmemory происходит в очень уникальном вероятностном сценарии, который очень сложно воспроизвести в среде dev/stage/uat.

Вы можете попробовать использовать пользовательские профилировщики, но если вы спешите и подключаете/устанавливаете профайлер upa на поле производства, потребуется время, вы также можете использовать jvm для получения дампа памяти (дамп памяти jvms также дает вам поток свалка)

Вы можете активировать автоматическую генерацию в командной строке JVM, используя следующую опцию: -XX: + HeapDumpOnOutOfMemoryError
Проект Eclipse Memory Analyzer имеет очень мощную функцию, называемую "group by value", которая позволяет создавать объектный запрос и перегруппировать экземпляры по значению поля. Это полезно в случае, когда у вас много экземпляров, которые содержат меньший набор возможных значений, и вы можете увидеть, какие значения используются больше всего. Это действительно помогло мне разобраться с некоторыми сложными дампами памяти, поэтому я рекомендую вам попробовать.

Ответ 4

Вы также можете рассмотреть возможность использования одного из современных JSM - Java Flight Recorder для HotSpot и Java Mission Control. Это набор инструментов, которые позволяют собирать информацию о времени выполнения на низком уровне с накладными расходами процессора около 5% (я никак не могу доказать последний оператор, это выражение инженера Oracle, представившего эту функцию и живую демонстрацию).

Вы можете использовать этот инструмент, пока ваше приложение работает 1_7u40 JVM или выше. Чтобы включить сборку информации о времени выполнения, вам нужно запустить JVM с определенными флагами:

По умолчанию JFM отключен в JVM. Чтобы включить JFR, вы должны запустить Java-приложение с опцией -XX: + FlightRecorder. Поскольку JFR является коммерческой функцией, доступной только в коммерческих пакетах на базе Java Platform, Standard Edition (Oracle Java SE Advanced и Oracle Java SE Suite), вам также необходимо включить коммерческие функции с помощью -XX: + UnlockCommercialFeatures.

(Цитируется http://docs.oracle.com/javase/8/docs/technotes/guides/jfr/about.html#sthref7)

Я добавил этот ответ, поскольку это жизнеспособный вариант для профилирования в производстве IMO.

Также есть плагин Eclipse, который поддерживает JFR и JMC и способен отображать информацию, удобную для пользователя.

Ответ 5

Инструменты значительно улучшились за эти годы. В наши дни большинство людей, у которых есть подобные потребности, используют инструмент, который перехватывает API-интерфейсы Java вместо API профилирования. Конечно, есть больше примеров, но NewRelic и AppDynamics Приходят на ум. Решения, основанные на инструментах, обычно выполняются как агент в JVM и постоянно собирают данные. Они сообщают данные на более высоком уровне (бизнес-транзакция, веб-транзакция, транзакция базы данных), чем старый подход к профилированию, и позволяют при необходимости копать глубже (вплоть до метода или линии). Вы даже можете настроить мониторинг и оповещения, чтобы вы могли отслеживать/предупреждать о показателях, таких как время загрузки страницы и производительность по сравнению с SLA. С помощью этих замечательных инструментов у вас действительно не должно быть причин запускать профилировщик в производство. Стоимость их запуска незначительна.