Если приложение регулярно падает, заказчики нервничают, сроки поджимают и не понятно в чём проблема, не стоит паниковать. Мы расскажем вам, что делать в такой ситуации и покажем, как мы выходили из сложившейся ситуации. В докладе на примере двух реальных проектов рассматриваются проблемы, которые могут возникать с Web приложениями на production environment’ах, пути их решения и инструменты, которые для этого могут быть использованы. Подробно будет рассмотрена настройка и использование JavaMelody. Докладчики: Владимир Малинин и Антон Семаник (Nix Solutions)

1. ШЕФ, ВСЕ ПРОПАЛО
Проблемы с Production
Антон Семаник
Владимир Малинин

2. О докладчиках
Антон Семаник
Nix Solutions Ltd.
Java Developer, Group Lead
Legacy code fan =)))
Владимир Малинин
Nix Solutions Ltd.
Java Developer, Group Lead

3. С чего всё начинается?
Рано или поздно разрабатываемое нами приложение
попадает на Production…
И именно в этот момент
начинается всё самое
интересное:
Другая среда…
Другие нагрузки…
Реальные пользователи…

4. Проблема:
• Приложение регулярно падает
• Заказчики бьют тревогу
• Сроки поджимают
• В чем проблема не понятно
• Все пропало!

5. Что мы имеем на входе?
Обычно не очень детальное описание проблемы от заказчиков,
но с требованием поправить и поскорее.
…надцати мегабайтный файл с логами за последний месяц (если
повезёт, то за день).
Мысль о том, что это происходит явно не по нашей вине.

6. Что же делать в таком случае?
Существует как минимум два варианта:
• Поддаться общей панике и идти искать решение в Google,
надеясь на удачу;
• Провести детальный анализ приложения в поисках проблемы.

7. Следуя по пути анализа, нужно:
• Попытаться воспроизвести поведение локально;
• Проанализировать логи приложения;
• Поискать проблемы в коде;
• Посмотреть на работающее приложение изнутри
используя профилировщик;
• Собрать статистику потоков / памяти / соединений к
базе.

8. Какие инструменты нам могут
помочь?
Профилировщики:
• jconsole
• VisualVM
• Jprofiler
• YourKit
Более продвинутые средства:
• JavaMelody

9. Ограничения профилировщиков
• Невозможно держать его открытым 24
часа в сутки 7 дней в неделю, не всегда
доступны требуемые порты на сервере
• Невозможно предсказать когда в
приложении возникнет проблема
• Для сбора статистики нужно
изобретать дополнительные грабли

10. Рассмотрим проблему на примере
реального проекта:
С регулярностью ~2 недели с приложением начинались
проблемы:
• Статические страницы отдавались сервером без проблем
• Все страницы запрашивающие информацию из базы
отдавались сервером как 504 Gateway Timeout

11. Конфигурация приложения:
Spring 3
Hibernate 3.5
BoneCP 0.8
СУБД MySQL
Apache tomcat 6 + Nginx proxy

12. Что нам было нужно:
Мощный но легковесный инструмент для мониторинга и
сбора статистики, которым можно использовать на
Production

13. К чему мы пришли:
В результате поисков был найден инструмент полностью
удовлетворяющий всем требованиям - JavaMelody

14. Преимущества JavaMelody
• Может работать на QA и Production
• Легко встраивается в готовое приложение
• Позволяет анализировать:
1. Использование памяти
2. JDBC соединения и SQL запросы
3. HTTP
4. MBeans
• Представляет информацию наглядно, в виде графиков
Недостатки JavaMelody
• Если приложение упало, то JavaMelody тоже будет
недоступен
• Графики не всегда информативны
• Нельзя указать интервал просмотра статистики менее 1-го дня

15. Настройка JavaMelody
Добавляем зависимость в pom.xml
<dependency>
<groupId>net.bull.javamelody</groupId>
<artifactId>javamelody-core</artifactId>
<version>1.50.0</version>
</dependency>
Добавляем фильтр в web.xml
<filter>
<filter-name>monitoring</filter-name>
<filter-class>net.bull.javamelody.MonitoringFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>monitoring</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<listener>
<listener-class>net.bull.javamelody.SessionListener</listener-class>
</listener>
Добавляем дополнительный конфиг для поддержки Spring:
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
classpath:net/bull/javamelody/monitoring-spring.xml
/WEB-INF/applicationContext.xml
</param-value>
</context-param>

16. На что стоит обратить внимание:

17. Использование памяти (хорошо):

18. Использование памяти (плохо):

19. Открытые JDBC соединения (хорошо):

20. Открытые JDBC соединения (плохо):

21. BoneCP через MBeans:
Соединения берутся из pool’a но не возвращаются назад.

22. Открытые JDBC соединения:
На протяжение длительного времени соединения остаются открытыми.
Наблюдается утечка JDBC соединений.

23. Класс-источник проблемы:

24. Источник проблемы:
Отсутствующая @Transactional аннотация. После её
добавления проблема утечки JDBC соединений исчезла.

25. Проект 2

26. Конфигурация приложения:
Spring 3
Hibernate 3.5
BoneCP 0.8
СУБД Postgres
Apache tomcat 6 + Nginx proxy

27. Проект2

28. Статистика из JavaMelody

29. Статистика используемой
памяти

30. Статистика http сессий

32. Что же делать дальше?
Пофикси приложение!

33. Воспроизвести проблему локально
JMeter parameters:

34. Проблема 1: Незакрытые соединения
ConnectionWatcher

35. Проблема 1: Незакрытые соединения

36. Проблема1: Незакрытые соединения

37. Проблема1: Незакрытые соединения
Результат работы анализатора логов

38. Победа?!

39. Что, опять?

40. Статистика используемой
памяти

41. Проблема2: “Тяжелые” запросы

42. Проблема2: “Тяжелые” запросы

43. Проблема2: “Тяжелые” запросы

44. Проблема2: “Тяжелые” запросы
Проанализировать модель данных
- на предмет Eager/Lazy fetchType
- разбить сложные тяжеловесные запросы на более
мелкие/быстрые
- класть в модель только необходимые данные

45. Пофиксили!

46. Если беда:
1. Hе паниковать
2. Собрать и проанализировать статистику
3. Проанализировать логи на предмет ошибок.
4. Воспроизвести проблему локально
5. Локализовать и пофиксить проблему
6. Пофиксить попутные баги

47. Спасибо за внимание!
Вопросы?