Комментарии 9
рекомендую использовать FastThread GUI для анализа
Ну, хз. Для каких-то своих проектов ещё можно подумать, но в каком-нибудь энтерпрайзе отправка внутрянки во внешние облака может сильно не понравиться безам. К проду-то не у каждого будет доступ, а тут просто взять и отправить во вне треддамп. Да и $10800 в год не сказать, чтобы дешёвое удовольствие.
Первое-же замечание: почти во всех книгах по оптимизации Java указывается, что цель оптимизации - нагрузить процессор. Чтобы он работал 100%. Не ждал ввода-вывода, ответов от базы и так далее. Пришел запрос - процессор нагрузился на 100% - отдал ответ - простаивает. Целью оптимизации является не создание курорта для процессора (у процессоров нет профсоюзов (пока)), а достижение максимальной производительности - количестве обрабатываемых запросов в секунду при приемлемом времени ответа.
Ну как бы да...
Процессор должен быть нагружен и "разгорет". “Нагрев” приложений — это отдельный большой топик. Это не отменяет факта, что если процессор постоянно работает на 100% в случаях аварии, то что-то не так с приложением, и его нужно профилировать и искать ошибку.
А как быть, если процессор нагружен слишком сильно и он начинает троттлиться?
На самом деле полезная статья в большинстве случаев, особенно для новичков, кто сталкивается с данного рода задачей впервые. Однако бывает, что те же java приложения работают не на постоянной основе, а допустим вызываются jar в кронджобах для каких-то сложных рассчетов, было бы интересно послушать , что делать в данном кейсе ну или другие альтернативные сценарии
на самом деле название статьи не совсем верное, под профилированием понимается анализ произодительности, т.е. до пожара еще не дошло, а вашем случае - это уже анализ последствий, когда что то свалилось/перестало работать
Профилирование Java-приложений: от HeapDump до Grafana