Иногда это происходит так: - Да ладно, мы упали.
Если сейчас не поднимешь, покажут по телевизору.
И мы собираемся.
Ночью.
На другой конец страны.
Ситуация, когда вам не повезло: на графике видно резкое увеличение нагрузки на СУБД.
Очень часто это первое, на что смотрят системные администраторы и это первый признак того, что что-то не так.
Но чаще всего речь идет о каких-то типичных вещах.
Например, заказчик столкнулся с низкой производительностью системы документооборота.
По понедельникам и вторникам система падала, перезагружали сервер, а потом всё восстанавливалось.
База данных задыхалась.
Захотели приобрести дополнительное оборудование (это долго и дорого), позвонили нам, чтобы рассчитать смету.
Мы рассчитали для них оценку и заодно предложили разобраться, что именно их тормозит. Через три-четыре часа источник проблемы был локализован.
Мы выяснили, что это медленные запросы к базе данных и неоптимальные схемы индексации.
Создали недостающие индексы, повозились с оптимизатором запросов в Oracle, некоторые проблемы потребовали изменения кода — изменили условия поиска (не меняя функционал), заменили некоторые запросы на использование заранее вычисленных представлений.
Если бы у них был нормальный человек, работающий с базами данных, они могли бы сделать то же самое сами.
Но вместо нормального человека раз в полгода был аудит базы у крутых оракулистов - давали общие рекомендации по настройкам и железу.
Как это происходит
Подробности немного изменены по просьбе силовиков.Система документооборота существует на сотнях промышленных объектов.
Иногда он падает и работа останавливается.
То есть объекты могут работать, но ни один документ не передан и не подписан.
А это, в частности, отгрузка сырья, заработная плата и инструкции, что и сколько производить за смену.
Каждое падение — это боль, слезы, коньяк для ИТ-директора, потому что ему тяжело: много потерь.
Режиссер, кстати, находится на этой должности всего полгода с момента последнего.
И прошлый год продолжался.
И оба они работают по системе, которую реализовал режиссер три поколения назад. Второй попытался внедрить свое с конца, но не успел, прежде чем его уволили.
Ситуация очень реалистичная.
На первый взгляд производительности недостаточно.
Загрузка профиля – блокировка (Ожидание класса «Приложение»).
То есть конкуренция за линии.
Мы начинаем расследовать инцидент. Сеанс открывается для каждой пользовательской транзакции.
Он довольно быстро переходит в состояние блокировки заказов, по которому выдаются к исполнению задания и инструкции, ведь пользователь должен поставить как минимум визу «Ознакомлен».
Последний случай связан с введением нового стандарта частоты прохождения сотрудниками медицинских осмотров.
Высокопоставленный кадровик написал приказ и разослал его по всем организациям.
То есть каждый работник каждого производства.
Десятки тысяч пользователей получили визовые транзакции.
Они практически одновременно начали открывать ордера и выстроили длинную цепочку блокировок в базе.
Из-за не самого оптимального кода в результате произошло «небольшое» переполнение и всё захлебнулось.
Около 40 тысяч пользователей не работают. Единственная запасная схема – телефоны и почта.
Производство не останавливается, но эффективность сильно падает, что приводит к конкретным финансовым потерям.
А потом начинаются звонки с каждого предприятия лично ИТ-директору, крики.
На практике у них есть SLA, но согласованного контракта пока нет. И ситуация приобретает окончательные черты чисто российской истории.
Проблема была быстро решена путем глубокого профилирования, анализа логики блокировки объектов, устранения ненужных объектов, которые были заблокированы, хотя в этом не было необходимости, поскольку объект не менялся (например, каталоги, права доступа и т.п.
).
Затем за пару месяцев мы провели рефакторинг основных участков кода.
Как находятся такие участки кода?
Помимо стандартных инструментов (threaddumps, logs, metrics, AWR, данных из системных представлений и т. д.), мы также используем и более гражданские инструменты, в том числе коммерческие.Пример 1. Журнал сделок работает медленно От пользователей поступали жалобы на медленную работу журнала (известная и распространенная проблема).
Находим проблемное представление, затем ищем в операциях запрос на представление Deal_journal_view. Ищем все транзакции, содержащие такой запрос.
По каждой операции можно просмотреть ее детали и найти сам запрос с параметрами выполнения, что позволяет проанализировать работу запроса, проверить и скорректировать план.
Мы нашли конкретный медленный запрос.
Мы сами проанализировали и предложили варианты оптимизации.
И только потом для отслеживания этой группы бизнес-транзакций (просмотр журнала транзакций) создаем Тип транзакции и настраиваем оповещения.
Пример 2: Поиск причин низкой производительности пользователя 1
Пользователь 1 пожаловался на медленную работу приложения.
Давайте посмотрим: 
Все действия пользователя были найдены и отсортированы по продолжительности.
Далее были проанализированы самые медленные операции и обнаружены медленные запросы к внешней системе (SAP).
Мы указали на это соседней команде и исправили.
Пример 3: другой пользователь жалуется на медленную работу приложения Давайте посмотрим на ту же схему.
На этот раз мы видим большое количество обращений к внешней службе подписи.
Оказалось, что при определенных условиях некоторые документы подписывались дважды.
Исправленный.
Пример 4: когда деталей недостаточно
Иногда для анализа более сложных частей кода мы прибегаем к использованию кастомных профайлеров, которые позволяют более глубоко изучить поведение приложения.
Например, как здесь: куча непонятной логики при вводе логики в систему.
Разобрались с логикой, добавили пару кешей и оптимизировали запросы.
Пример 5: больше тормозов
Пользователь пожаловался на медленную работу с контрактными картами.
Анализировались медленные операции пользователей (параметр = ‘userlogin=”…”’) за одну неделю.
Больше всего проблем было с поисковыми запросами по договорам, но были обнаружены и операции с карточкой документа.
Большую часть времени уходит на создание большого количества задач по заданиям.
Были найдены идентификаторы (столбец Значение параметра на скриншоте) сохраненных задач и время их сохранения.
Логично, что они могут создаваться асинхронно, но теперь ставятся в очередь и требуют монопольных блокировок.
Здесь нужно глубже вникать в архитектуру.
Это так просто: нужно просто найти узкое место и всё?
Нет. И снова нет. Все дело в лечении симптомов.Правильно быстро спасти ситуацию, которая сейчас «горит».
А затем установите процессы.
Редко когда люди, работающие с системой, не понимают, что они делают. Просто либо им нужно обосновать выделение средств на сокращение технического долга (а им никто не верит), либо менять процессы на более современные (на которые тоже нет ресурсов), либо сделать что-то еще подобное.
В общем, мы приходим с верхнего уровня и видим боль клиента.
Далее ловим узкое место.
Иногда это заканчивается внедрением системы мониторинга.
И если заказчик понимает, что необходимо менять процессы разработки ПО, то начинается этап «долгий, дорогой и даже не офигенный».
Смотрим два-три проекта, прочесываем все документы, репозитории, интервьюируем людей.
Далее готовим шаблоны новых документов, готовим процедуры, смотрим инструменты управления требованиями и тестирования.
И мы помогаем это реализовать.
Иногда достаточно просто высказать мнение, что нужно изменить, и вдохновленный CIO с бумагой получает бюджет. Иногда приходится напрямую реализовывать это, кровью и слезами.
Боль может быть чем угодно: от неправильного выбора архитектуры до каких-то особенностей рабочего процесса.
Это примеры - конкретно об игре в процессы в разных компаниях по стране.
Что касается оптимизации приложений со стороны базы данных, то вот типичный пример.
Есть медицинская система (одна из тех, что упали).
Они пригласили нас на просмотр.
Мы приехали, когда уже отключили все модули, кроме документооборота врачей, чтобы хоть как-то проходили анализы и была запись через регистратуру.
В числе отключенных модулей, в частности, оказалась онлайн-запись.
Нам удалось все исправить за одну неделю.
Изначально заказчик думал, что проблемы на уровне приложений: были сбои по таймаутам и зависшие потоки.
Выяснили, что проблема в базе данных.
Была сложная структура, много разделения по дням и месяцам.
Оказалось, что забыли про пару индексов, разработчики до конца не знали, во что это превратится со временем — и вот результат. Примерно тот же набор операций плюс ограничения поиска (когда нужно скачать что-то в диапазоне дат, лучше искать между этими датами, а не по всей базе).
Понятно, что такая оптимизация не всегда решает проблему.
Например (в архитектуре) энергетика: заказчик просит посмотреть, что происходит с зависанием системы.
И там при доставке все летало, но через пару лет документов стало гораздо больше, и все приятно тормозило.
Заказчик сидел с секундомером на рабочем месте оператора и говорил: эта операция сейчас занимает 31 секунду, мы хотим 3. Эта занимает 40 секунд, мы хотим 2. И так далее.
Понятно, что так измерять не очень корректно, но задача вполне конкретная и легко может быть представлена в виде объективных критериев.
Не все было сделано; «чистка» заняла в общей сложности около шести месяцев.
По большей части мы перевели логику на асинхронное выполнение, часть баз данных поменяли на noSQL, установили поисковик Solar, а на одном участке нужно было выбрать самую горячую базу данных и сделать ее in-memory. В результате около 90% потребностей было удовлетворено, но кое-где не удалось сократить задержки.
Это работа сторонних библиотек, физические ограничения платформы и так далее.
Все это контролировалось и мы смогли четко доказать, где именно и что тормозит.
Зачем еще может понадобиться такой мониторинг?
Мы используем различное программное обеспечение для мониторинга, чтобы быстро находить медленные процессы и оптимизировать их.ИТ-команда одного из наших крупных клиентов посмотрела, как мы это делаем, и попросила внедрить это на одном из их сайтов в качестве постоянного инструмента.
Окей, мы мониторили все процессы и узлы, настраивали их систему под задачи, работали почти четыре месяца, но создали набор инструментов для их поддержки.
А там 80 тысяч пользователей, есть первая и вторая линии внутри и третья, часто с подрядчиками или тоже внутри.
На второй линии находится как раз этот набор инструментов.
Сейчас примерно в 50% случаев они используют мониторинг для диагностики, поиска узких мест и причин зависаний, чтобы их собственные разработчики могли смотреть, понимать и оптимизировать.
Благодаря быстрому выявлению причины проблемы экономится много времени поддержки.
После пилота мы масштабировались за счет транзакций.
Именно на это ушло четыре месяца: на каждое действие есть бизнес-операция.
Открытие карточки документа – это хозяйственная операция.
Вход в систему документооборота является бизнес-операцией.
Загрузка отчета или поиск – тоже.
Описано 1500 таких бизнес-операций за четыре месяца, чтобы понять, где и что работает. Мониторинг ранее отслеживал HTTP-вызовы, отслеживал вызываемые методы и функции, а также отслеживал конкретные запросы.
До этого только разработчики понимали, что это соглашение или поиск.
Чтобы система мониторинга отображала актуальные данные для разных линий поддержки и для бизнеса, мы настроили все эти ссылки.
Компания также начала самостоятельно готовить отчеты о развитии ИТ.
В логах там уже особо никто не ковыряется.
Кстати, обо всем, зачем вообще нужны классовые системы АПМ , а как их выбрать, мы расскажем вам на вебинар 1 октября .
Какие еще технические проблемы есть?
Еще пара примеров.Крупный иностранный банк с представительствами в России.
Мы поддерживаем Oracle DB и Oracle Weblogic. Произошло постепенное снижение производительности в системе, бизнес-операции выполнялись медленнее, работа клерков становилась все менее эффективной, а в периоды импорта и синхронизации с мастер-данными все замирало.
В таких случаях мы используем стандартные инструменты Java и Oracle для сбора данных: собираем дампы потоков, анализируем их в бесплатных сервисах или используем самодельные инструменты анализа, смотрим AWR, отслеживаем выполнение SQL-запросов, анализируем планы и статистику выполнения.
В итоге, помимо стандартных вещей вроде оптимизации состава индексов и корректировки планов запросов, предложили ввести партиционирование путем деления данных.
Получилось два сегмента: исторический (они остались на HDD) и оперативный — их разместили на SSD. До этого было довольно сложно понять, какие данные к чему относятся, потому что все равно приходилось регулярно спускаться к историческим данным, как на длинных отчетах, так и в обычных операциях.
В результате правильного разделения более 98% основных операций не мешали медленным историческим данным.
Важно то, что не нужно было лезть в системный код. Бывает, что некоторые наши рекомендации требуют внесения изменений в код приложения, который нами не поддерживается — тогда мы обычно договариваемся.
Второй пример: международный производитель в сфере легкой промышленности и сегмента FMCG в целом.
Час простоя основного сайта стоит около 20 миллионов рублей.
Типичная нагрузка на базу — 200 AS (активных сессий) с пиками до 800-1000. Нередко оптимизатор запросов сходит с ума, планы начинают идти не так, как надо, и начинается дикая конкуренция за буферный кэш.
От этого никто не застрахован, но снизить вероятность можно: мы мониторили систему два месяца, анализируя профиль нагрузки, попутно тушая возникающие пожары, корректируя схемы индексации и секционирования, логику обработки данных из PL/SQL-кода.
Тут нужно понимать, что в живой, развивающейся системе такой аудит нужно проводить регулярно, хотя нагрузочное тестирование и помогает, но не всегда.
А компании проводят аудиты, приглашая сторонних оракулистов, но редко кто из них опускается до уровня бизнес-логики и готов вникать в данные, взаимодействуя с разработчиками.
Это то, что мы делаем.
Что ж, хочу сказать, что не всегда проблема заключается в отсутствии регулярной чистки или должной поддержки.
Часто проблемы возникают в процессах.
Зачем нам такие услуги, когда наши разработчики живы?
Потому что бизнес любит решения, а не процессы.Это основная причина.
Во-вторых, не каждый может выделить ресурсы на поиск узкого места в приложении, особенно если это стороннее приложение.
И не всегда в одной команде есть люди, обладающие необходимыми компетенциями.
Теперь в нашей команде есть системный инженер, сетевые инженеры, специалисты по Oracle и 1С, люди, умеющие оптимизировать Java и фронтенд. Ну а если вам интересно углубиться в детали, то Наш вебинар состоится 1 октября.
о том, что можно сделать заранее, пока все не рухнуло.
А вот моя почта для вопросов — [email protected]. Теги: #Управление проектами #ИТ-инфраструктура #разработка #оптимизация #код #производительность #приложение #пользователь #пользователь #консультирование #анализ
-
Хлор Активный
19 Oct, 24 -
Сервис Мониторинга Статуса Сайта Vigil
19 Oct, 24 -
Малый Бизнес И Saas\S+S
19 Oct, 24 -
Как Легко Понять Логистическую Регрессию
19 Oct, 24 -
Еженедельный Подкаст №57
19 Oct, 24
