Оптимизация производительности нагруженных...
-
Upload
alex-chistyakov -
Category
Economy & Finance
-
view
1.802 -
download
1
Transcript of Оптимизация производительности нагруженных...
Оптимизация производительности нагруженных веб-систем на Java
Личный опыт и не только
Давайте познакомимся
• [email protected]• Разрабатываю с 1998-го• Разрабатываю на Java с осени 2000-го• Кроме разработки, занимаюсь
консультированием команд, разрабатывающих веб-приложения
• Читаю доклады по оптимизации производительности
Вы?
• Разработчики на Java• Разработчики веб-приложений на Java?• Архитекторы приложений?• IT operations engineers?• Performance engineers?
Почему веб-приложения?
• У веб-приложений много пользователей• В интернете при решении даже простых
бизнес-задач легко столкнуться с большими нагрузками
• Интернет большой, и уменьшения числа пользователей не предвидится – в будущем любое успешное веб-приложение будет высоконагруженным
Постановка задачи
• Что такое «высокая нагрузка»?• Все относительно• Метрики: время обработки запроса и
процент успешно обработанных запросов• У приложения нет периодов простоя, вас не
будят по ночам – эта презентация не для вас
• Метрики неудовлетворительны – надо искать выход
Где же выход?
• http://ru.wikipedia.org/wiki/Шаманизм•
Шаманизм и оптимизация
• http://ru.wikipedia.org/wiki/Карго-культ• «Сделаем, как у больших (как у Google)»• «Сделаем, как делал архитектор Вася в
прошлом проекте»• «Сделаем, как написано в этом блоге»• Shotgun programming: «Сделаем как-нибудь
и посмотрим» – может быть хорошим подходом для начала
Если это был не выход...
• Путь 1: Наймите консультанта• Путь 2: Измеряйте, потом оптимизируйте!• Что измерять?• Все, до чего можете дотянуться, в первую
очередь:• Параметры системы в целом• Параметры вашего приложения
Параметры системы
• Состояние HDD – IOPS, latency• Состояние оперативной памяти – размер
памяти приложений, размер файлового кэша• Состояние CPU – user time, system time• Состояние очереди планировщика – LA• Состояние сетевой подсистемы – количество
подключений, объем трафика• Состояние JVM – количество major/minor
garbage collections
Сбор параметров системы
• Java-based: OpenNMS, … - жизнь слишком коротка, других ресурсов тоже мало
• Zabbix – если вы работаете в Yandex, или у вас есть время переписать код работы со стат. данными
• Munin – требует мало ресурсов и не требует первичной настройки
• Cacti – если используете DBMS MySQL• Collectd – требует минимальное количество
ресурсов, агент написан на pure C.
Параметры приложения
• Длительность выполнения разных участков кода приложения
• Потребление памяти структурами данных• Частота выделения памяти под новые
структуры данных• Можно использовать профайлер• Профайлеры: YourKit, JProfiler, …• Можно использовать другие средства
профилирования
Недостатки профайлера
• Профайлер знает о вашем приложении гораздо меньше, чем вы
• Профайлер профилирует каждый вызов• Профайлер может вносить сильную
погрешность и даже менять картину в целом
• Использование профайлера предполагает предварительное знакомство с ним
Другие средства
• Отладочная печать – служит разработчикам ПО с 60-х годов прошлого века
• Thread stack sampling (kill -QUIT PID)• BTrace – аналог DTrace для JVM• Самостоятельная расстановка вызовов
профилирования в коде (вызовы JAMon, запись данных во внешнее хранилище для постобработки, статистическая предобработка)
Выбор средств профилирования
• Используйте универсальные средства• Серебряной пули нет• А, поэтому, используйте любые средства• Подумайте об интеграции ваших средств
профилирования со средствами мониторинга системы
• Подумайте о возможности профилирования системы в продакшн режиме
Нагрузочное тестирование
• Средства создания тестовой нагрузки – ab, siege, JMeter, Tsung
• ab и siege – недостаточно настроек• JMeter – кому-нибудь удавалось создать с
его помощью нагрузку хотя бы в 400 rps с одного хоста?
• Tsung – может работать в распределенном режиме, но довольно капризен
Случай из жизни 1
• Tomcat, Spring, MySQL, многонодовая конфигурация в Amazon Cloud
• Куплен профайлер• Проблемы под тестовой нагрузкой• Профайлер ничего не показывает
Брейндамп решения 1
• Попытка подключить VisualVM (практически провалилась – RMI плохо работает через SSH туннель)
• Thread stack sampling в консоли при помощи стандартной утилиты jstack, сброс сэмплов в файл и ручной анализ файла
Брейндамп 1 – анализ тред стеков
• Много записи на диск (ведутся логи) – изменили уровень логгинга
• Потоки стоят на блокировке при обращении к БД – долго выполняются некоторые из SQL-запросов (сами запросы написаны неоптимально)
• Проблема вообще не в Java!• (зря покупали профайлер)
Случай из жизни 2
• Приложение, написанное в 2002-м году• Weblogic, сервлеты подключенные без
использования web.xml, Solaris 8, Oracle, JVM 1.2, часть бизнес-логики в хранимых процедурах и другие радости жизни
• Исходного кода приложения нет• Первоначально задачи оптимизации
производительности не было, но мне начали звонить по ночам...
Брейндамп решения 2
• Сложный путь апдейта JVM до версии 1.5• Сбор данных о потреблении памяти, сбор
данных о поведении GC• Тюнинг Oracle, чтобы он не мешал Java-
приложению• Попытка тюнинга GC (ни к чему не привела)• Разные опции запуска JVM, разные версии JVM• Непонятна корреляция между падениями
системы и внешними событиями
Брейндамп решения 2 - продолжение
• Включение access log на время в момент проблемы с доступностью
• Корень проблемы – брут-форс подбор логинов и паролей
• Внедрение ehcache и временной блокировки по IP на час после 10 неудачных попыток логина в течение 5 минут
• Нагрузка исчезла• Бывают такие легаси-системы, в которых все
непривычно
Случай из жизни 3
• Веб-сайт в Рунете с довольно большой нагрузкой
• Resin, JSP, servlets, три физических сервера• RDBMS Firebird• Apache 1.3 как reverse proxy• В моменты пиковой нагрузки проблемы с
производительностью вплоть до недоступности серверов, необходим рестарт
Брейндамп 3
• Команда консультантов поделилась на две части
• Одна часть – «сисадмины» зачем-то настраивала mod_accel
• Вторая часть пыталась разбираться с Java и Firebird
• Анализ Firebird показал, что с ним все в порядке и улучшить что-либо существенно нельзя
Брейндамп 3 - продолжение
• Попытка построить тестовое окружение и профилировать приложение под YourKit
• Профайлер не показал узких мест на том шаблоне нагрузки, который был применен для тестирования
• Добавление в код приложения печати отладочной информации в лог
• Несколько падений системы на глазах команды, время восстановления после рестарта по 3.5 часа – разогрев кэшей
Брейндамп 3 - приложение
• Анализ отладочной информации из лога показал узкое место
• Анализ кода выявил доступ к базе в synchronized блоке
• Сужение области действия synchronized блока (разбили на два блока) привело к уменьшению времени разогрева кэша до нескольких минут
• Используйте lock-free структуры данных• Не используйте Firebird!
Выводы
• Невозможное возможно• Накапливайте и используйте факты и знания
о вашей системе, не пользуйтесь религиозными представлениями примитивных сообществ
• Сложные и дорогие инструменты часто ничем не лучше простых и бесплатных
Вопросы?
• • • •
Спасибо за внимание!
• Alexander Chistyakov, DataArt• [email protected]• http://alexclear.livejournal.com• https://github.com/alexclear• Enjoy IT!