При больших объемах данных и множестве операций в 1С оптимизация — почти обязательная процедура. И к этому все подходят по-разному: кто-то пытается использовать штатные инструменты для мониторинга (ведь есть ЦУП), а кто-то выстраивает целую систему. Мы уже рассказывали, как BI-система помогает ИТ-директору мониторить производительность. Кратко: сегодня на одной витрине руководитель видит операции, может отследить, какие из них пересекаются, сколько в среднем тратится времени на выполнение той или иной операции и т. д.
Но только этим в компании не ограничились, дашборд работает в связке с таким инструментом как «Монитор». Он предназначен для анализа производительности баз и серверов 1С. О первом успешном опыте использования также рассказывали в одной из статей. Сегодня разберем особый случай — новый релиз в сочетании с кастомизированной системой.
Компания работает на российском рынке информационных технологий более 25 лет. Ключевые направления деятельности: системная интеграция, ИТ-сервис и аутсорсинг, поставка и сопровождение программно-аппаратных средств, копировально-печатного оборудования и расходных материалов, а также собственное производство серверов, рабочих станций и компьютеров. Также есть интернет-магазин компьютеров, компьютерных комплектующих, периферии, расходных материалов XCOM-SHOP, который входит в TOP‑30 крупнейших интернет‑магазинов России и ТОП‑5 компьютерных. В ассортименте более 120 тысяч товарных позиций.
«Тяжелые» задачи: поиск проблемы после обновления
В компании X-Com используют кастомизированную конфигурацию 1С со множеством доработок. Обновления в законодательстве потянули за собой обновление системы. При этом при накатывания нового релиза ошибки могут возникнуть даже в типовой конфигурации, с доработанными базами проблем еще больше. В тестовом контуре после обновления ошибок не возникло, они проявились под нагрузкой в реальной среде:
- часть задач, которые выполняли пользователи, дублировалась в фоновые задания;
- процессор был загружен на 100%;
- как следствие операции пользователей выполнялись долго.
Скорость проведения документов увеличилась в несколько раз. Например, на проведение документов реализации раньше тратилось несколько секунд, после обновления мы уперлись в десятки минут. А при условии, что требуется большой объем этих документов, можно сказать, что система была парализована.
Леонид Дегтярёв,
директор по информационным технологиям компании X-Com
Команда подключила для анализа «Монитор». Этим инструментом можно проанализировать все базы и сервера.
Начали с самых тяжёлых процессов и запросов: лишние запросы при открытии формы заказов, дополнительное расширение для логистов и т. д.
Перечень довольно быстро проработали, однако нагрузка и задержки сохранялись. Поиск неисправностей тормозил работу, к тому же необходимо было накатывать новые релизы. За неделю удалось найти баланс по скорости работы, чтобы процессы не остановились и при этом новые требования законодательства соблюдались. Но необходимо было решить проблему.
Погружение в «Монитор»: что оказалось причиной
После того как видимые, основные процессы удалось поправить, специалисты ещё раз обратились к «Монитору» для более глубокого анализа. При выгрузке данных, которые может отдавать «Монитор» в СУБД, обнаружилось большое количество коротких запросов — несколько тысяч за минуту. И каждый запрос грузил процессор.
Нам это сразу показалось подозрительным, потому что такого быть не должно. Мы увидели, что на самом деле есть множество фоновых заданий и каждое фоновое задание выполняется, но очень медленно. При этом их количество соотносится с количеством этих самых очень коротких, но грузящих операций. Дальше стало понятно, что одна из доработок — наше ограничение, которое мы наложили для скрытия чувствительной информации, работает некорректно. При выполнении пользователем любого действия в системе оно инициировало фоновое задание.
Леонид Дегтярёв,
директор по информационным технологиям компании X-Com
В результате удалось не только вернуть скорость проведения документов к исходным значениям, но и сделать этот процесс быстрее. А благодаря инциденту, технический директор и команда увидели также другие проблемные места, которые нужно оптимизировать.
Инцидент стал катализатором и помог решиться на изменения. Сейчас в компании уже работают над оптимизацией процессов по маркетплейсам (загрузка остатков, цены и так далее). Но самое ценное — это контроль результативности действий, который доступен в динамике. С помощью «Монитора» можно сравнить на графике как было в критический момент и сейчас.
Результат
После оптимизации система вернулась в рабочее состояние:
- процессор перестал забиваться под 100%,
- время проведения документов вернулось к нормальным показателям,
- пользователи снова смогли работать без простоев.
Без «Монитора» команда искала бы причину значительно дольше. Инструмент позволил не только найти тяжёлые процессы, но и докопаться до скрытой ошибки, которая и парализовала работу системы.
