Деградация производительности 1С:ERP

После масштабного роста объемов строительства и увеличения количества объектов компания столкнулась с деградацией производительности 1С.

Проблемы особенно проявлялись в пиковые периоды:

• утром — массовая загрузка банковских выписок;
• днем — проведение КС-2/КС-3 и закупочных документов;
• вечером — резервирование материалов и закрытие складских операций.

В отдельные часы система практически переставала отвечать:

• документы проводились по 3–7 минут;
• пользователи получали ошибки таймаута;
• блокировались рабочие места бухгалтерии и ПТО;
• массовые операции могли выполняться часами;
• закрытие месяца регулярно переносилось.

Основные проблемы

Казначейство и банковские операции

Загрузка банковских выписок объемом 30-50 МБ занимала до 5 часов.

При параллельной обработке:

• возникали блокировки регистров;
• создавались дубли платежных документов;
• фоновые задания перегружали кластер 1С.

Проведение КС-2 и КС-3

Во время массового формирования актов выполненных работ:

• несколько пользователей одновременно проводили документы;
• происходила конкуренция за движения по одним и тем же регистрам;
• система формировала длинные очереди ожидания SQL-блокировок.

В часы пик проведение одного комплекта документов могло занимать до 10 минут.

Складской учет и резервирование

Параллельное резервирование материалов по строительным объектам приводило к конфликтам за остатки:

• пользователи повторно запускали операции;
• возрастало количество незавершенных транзакций;
• увеличивалась нагрузка на SQL Server.

Закупки и согласование заявок

Согласование заявок на закупку запускало цепочки бизнес-процессов одновременно по нескольким подразделениям.

Из-за большого количества фоновых задач:

• резко возрастала нагрузка на сервер 1С;
• интерфейс пользователей начинал зависать;
• формирование отчетов замедлялось в разы.

Команда проекта

Для поиска узких мест была сформирована рабочая группа.

Со стороны подрядчика:

• руководитель проекта;
• архитектор 1С;
• 2 senior-разработчика 1С;
• DBA MS SQL;
• DevOps-инженер.

Со стороны заказчика:

• ИТ-директор;
• руководитель финансового блока;
• руководитель ПТО;
• ключевые пользователи бухгалтерии и склада.

Как проводилось обследование

Диагностика выполнялась в несколько этапов.

Используемые инструменты

• технологический журнал 1С;
• замеры производительности;
• SQL Profiler;
• ЦУП;
• Монитор производительности 1С;
• анализ блокировок SQL Server;
• мониторинг фоновых заданий;
• нагрузочный анализ кластера 1С.

Ключевые причины деградации производительности

Критическое количество ожиданий на блокировках

Большинство проблем было связано не с «тяжелыми» запросами, а с параллельной записью данных:

• регистры накопления;
• движения по остаткам;
• взаиморасчеты;
• казначейские регистры.

Многопоточность ухудшала ситуацию

Часть операций уже была реализована в фоне, однако при росте нагрузки это приводило к обратному эффекту:

• фоновые задания начинали конкурировать между собой;
• происходило каскадное создание новых задач;

SQL Server уходил в ожидания LCK_M_X и PAGEIOLATCH.

Повторяющиеся обращения к данным

В типовых механизмах:

• многократно запрашивались одинаковые настройки;
• повторно вычислялись одинаковые данные;
• происходили одинаковые обращения к справочникам и константам.

Выбор оптимальной стратегии оптимизации

На этапе проектирования обсуждалось несколько подходов.

Вариант 1. Масштабирование инфраструктуры

Предполагалось:

• увеличить CPU SQL Server;
• расширить RAM;
• вынести фоновые задания на отдельный сервер.

Недостатки

• высокая стоимость;
• отсутствие гарантированного эффекта;
• риск повторения проблемы через несколько месяцев.

Вариант 2. Полная оптимизация кода и запросов

Предполагалось:

• глубокое переписывание механизмов проведения;
• переработка транзакций;
• оптимизация SQL-запросов.

Недостатки

• длительные сроки;
• высокий риск ошибок;
• невозможность быстро получить эффект.

Вариант 3. Управление потоками и отложенная обработка

Команда выбрала комбинированный подход:

• убрать критичные операции из пользовательских сеансов;
• сократить параллелизм;
• перевести тяжелые процессы в управляемые очереди;
• стабилизировать фоновые операции.

Именно этот вариант стал основой проекта.

Кейс №1. Отложенное проведение КС-2 и КС-3

Ранее пользователи одновременно проводили десятки актов

Теперь:

• документ переводится в статус «К проведению»;
• запись ставится в очередь;
• отдельное фоновое задание проводит документы последовательно.

Результат

• количество блокировок снизилось более чем на 80%;
• среднее время проведения сократилось с 7 минут до 50 секунд;
• пользователи перестали получать таймауты.

Кейс №2. Очередь резервирования материалов

Для складских операций внедрили единый диспетчер резервирования

Теперь:

• пользователь только инициирует операцию;
• резервирование выполняется отдельным обработчиком;
• операции идут последовательно по объектам строительства.

Результат

• исчезли взаимные блокировки;
• склад перестал «зависать» в часы пик;
• количество повторных операций сократилось в 5 раз.

Кейс №3. Многопоточная загрузка банковских выписок

Была переработана типовая обработка обмена с банком

Что изменили:

• кешировали часто используемые данные;
• вынесли повторные обращения к БД;
• внедрили контролируемую многопоточность через собственный менеджер потоков;
• ограничили максимальное количество параллельных задач.

Сложности

На этапе тестирования обнаружилось:

• неконтролируемое создание фоновых заданий;
• дублирование документов;
• деградация производительности SQL Server.

Для решения:

• ввели диспетчер потоков;
• реализовали контроль очередей;
• ограничили количество активных задач;
• добавили механизм повторной обработки ошибок.

Результат

• загрузка банковской выписки сократилась с 5 часов до 35 минут;
• исчезли дубли платежных документов;
• нагрузка на SQL стабилизировалась.

Кейс №4. Оптимизация закупочных процессов

Во время согласования заявок система формировала десятки связанных запросов.

Что сделали:

• добавили индексацию временных таблиц;
• убрали повторные вычисления;
• переработали цикл формирования маршрутов согласования;
• внедрили пакетную обработку уведомлений.

Результат

• время согласования сократилось в 3 раза;
• интерфейс перестал зависать;
• нагрузка на сервер приложений снизилась на 40%.

Проект оказался нетривиальным по нескольким причинам

Проблемы проявлялись только под реальной нагрузкой. На тестовых стендах часть сценариев не воспроизводилась.

Высокая нагрузка на продуктиве

Проблемы проявлялись только под реальной нагрузкой. На тестовых стендах часть сценариев не воспроизводилась.

Большое количество интеграций

Система была связана с:

• клиент-банком;
• ЭДО;
• BI-системой;
• внутренними порталами;
• строительными системами учета.

Любые изменения требовали дополнительного тестирования.

Ограниченное окно внедрения

Большинство изменений внедрялось:

• ночью;
• в выходные;
• между закрытиями периодов.

Управление потоками оказалось эффективнее масштабирования инфраструктуры

Производительность

• проведение КС-2/КС-3 ускорилось в 6 раз;
• загрузка банковских выписок — в 8 раз;
• резервирование материалов — в 5 раз;
• согласование закупок — в 3 раза.

Эффект для бизнеса

Снижение простоев

Пользователи перестали ждать завершения массовых операций.

Стабилизация работы системы

Даже в пиковые часы:

• система сохраняла отзывчивость;
• отчеты формировались без зависаний;
• фоновые задания работали предсказуемо.

Сокращение количества инцидентов

Количество обращений в ИТ-поддержку снизилось более чем на 70%.

Что в итоге оказалось главным

Ключевой вывод проекта — далеко не всегда проблемы производительности требуют полной переработки системы или масштабной оптимизации SQL.

Во многих случаях основной причиной деградации становятся:

• неконтролируемая многопоточность;
• параллельная запись одних и тех же данных;
• перегруженные пользовательские транзакции.

В ПАО «Кислородмонтаж» основной эффект дала не глубокая переработка архитектуры, а:

• грамотное управление потоками;
• отложенная обработка;
• сокращение конкуренции за ресурсы;
• перенос тяжелых операций в фон.