Привет, Хабр! Меня зовут Леша Литонов, я старший разработчик и техлид Lamoda Tech на проекте 1С:Управление холдингом. В начале 2024 года мы в компании закончили масштабную миграцию на новый финансовый контур, сменив зарубежную ERP и 1С-бухгалтерию на новую систему «1С:Управление холдингом». Изменения затронули всю финансовую систему Lamoda, включая расчеты с миллионами клиентов и контрагентов, поэтому нам было важно провести быстрый, бесшовный и безрисковый переход. Я опишу, с какими проблемами производительности мы столкнулись в блоке «Казначейство», и как их удалось решить с помощью подсистем «Менеджер потоков» и «Монитор».

Контекст

Изначально наш финансовый блок находился в ERP-системе Axapta. Во время его переноса в 1С:УХ было важно соблюсти следующие условия:

• снизить долю трудоемких и рутинных операций сотрудников за счет автоматизации,

• заместить импортное программное обеспечение,

• завершить процесс миграции на новую платформу ERP,

• обеспечить базу для централизации управления финансами: внедрения МСФО, бюджетирования (контроля) и непрямых закупок.

При переносе затронули три блока 1С: Казначейство, МСФО и Бухгалтерский учет.

При этом систему требовалось выкатить в сжатые сроки, поэтому перед запуском мы не успели провести нагрузочное тестирование, что и привело к проблемам. Поделюсь, как мы их решали в блоке «Казначейство».  

Производительность блока «Казначейство»  

Первый день работы системы совпал с платежным днем. Наши коллеги, работающие в «Казначействе», начали загружать файлы банковских выписок, и к концу дня стало понятно, что система не успевает прочитать и обработать все данные, то есть не отвечает требованиям производительности. Обработка файлов занимала по 6-8 часов, тогда как ранее в Axapta на это уходило 1-2 часа. 

Корнем проблемы стала обработка обмена с банком, где обнаружилось два препятствия:

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

2. Долгая обработка прочитанных данных, дальнейшая загрузка в систему и создание объектов.

Кейс №1. Чтение файла банковской выписки

Чтобы решить проблему, мы начали перерабатывать типовую функциональность под свои запросы. Для анализа использовали обычные замеры производительности из конфигуратора, и выяснили, что больше половины времени система тратила на два процесса:

• получала значение константы, связанной с нумерацией счетов-фактур для аванса,

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

Мы решили вынести данные методы в модуль с повторным использованием возвращаемых значений. Это дало нам ускорение чтения файла на 50% — в два раза быстрее. 

Кейс №2. Обработка загруженных данных выписки 

Прочитав файл, мы получили множество строк, которые необходимо было обработать, и затем создать в системе объекты.

Здесь мы столкнулись с тремя проблемами:

1. Много документов обрабатываются в один поток.

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

Здесь мы решили воспользоваться подсистемой «Длительные операции»  с БСП, и с ее помощью обрабатывать данные в фоне в несколько потоков. 

2. Ожидания на блокировках при записи в Регистры Накопления.

Мы столкнулись с проблемой ожидания блокировок при многопоточной записи документов. Она состоит в том, что при проведении разные документы пытаются записать данные в один регистр и встают в очередь на ожидание друг друга. Из-за этого смысл многопоточной обработки теряется. Пытаясь решить проблему типовым методом, мы включили разделение итогов у таблицы. Третьей проблемой стала производительность блока «Длительные операции», и это требует подробного рассказа. 

Производительность подсистемы «Длительные операции» 

Только на то, чтобы понять, что было не так с этой подсистемой, мы потратили три дня. Но описание наших действий займет гораздо меньше времени :)

Контекст: в свежей версии БСП в подсистеме «Длительные операции» появилась возможность выполнять процесс фоново в несколько потоков. 

Мы воспользовались этой опцией и совершили следующие действия:

• поставили в константе «Количество потоков длительных операций» нужное нам количество потоков.  

• запустили создание документов через ДлительныеОперации.ВыполнитьФункциюВНесколькоПотоков().

После того, как мы это сделали, на тестовом контуре и на проде всё было отлично, но до определенного момента. Пользователи стали жаловаться на то, что у них задваиваются некоторые создаваемые документы. 

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

Но проблема не решалась. Мы продолжили искать истинную причину и выяснили, что когда в системе нет свободных потоков, она ждет, чтобы запустить новый поток. Если параллельно с обработкой данных по банковским выпискам запустить типовую операцию, которая также использует многопоточность — например, массовое редактирование реквизитов или групповую пометку удаления, в какой-то момент система перестает ждать. Она начинает резко и бесконтрольно плодить фоновые задания, причем уже запущенные.

На кластере мы увидели, что таких фоновых заданий было около 500, и это помимо того, что в системе работали пользователи. Это приводило к тому, что появлялись дубли документов. При этом кластер был живой, а СУБД показывала, что у нее нет ресурсов процессора, и покидала чат. 

Выяснив, в чем дело, мы направили обратную связь в 1С об этой проблеме. А чтобы не терять время, решили, что используем для себя другую подсистему по работе с многопоточностью — «Менеджер потоков».

Как мы работали с «Менеджером потоков» 

Это довольно известная подсистема, и хотя в последний раз она обновлялась несколько лет назад, своей актуальности за это время не потеряла. Принцип ее работы заключается в том, что вы отдаете ей таблицу с данными, их она распределяет по потокам, которые нужно обработать.

Сначала мы запускаем подсистему, затем сами потоки. «Менеджер» на старте контролирует количество потоков и элементов порции. Если один поток упал, можно либо поднять его, либо дропнуть все остальные потоки. 

Чтобы каждый раз не задавать кодом количество потоков на старте менеджера, либо количество элементов для обработки в одном потоке, мы создали для себя небольшой справочник. В нем задаем эти настройки и высчитываем, как более гибко контролировать процесс.

В итоге с использованием «Менеджера потоков» мы сократили время обработки в среднем до 30 минут.

Кейс №3. Оптимизация отображения списка документов к отправке в банк

Помимо всего прочего, от пользователей пришла обратная связь о том, что очень долго формируется список документов, который нужен при подготовке файла для отправки в банк. Мы стали разбираться и выяснили, что для создания списка из 9000 строк системе требовалось почти 8 минут.

В первой строке видно, что выполнение списка 9000 раз занимает 100 секунд чистого времени — 1,6 минут. Но в следующих строках видим, что конец цикла выполняется 51 секунду, а количество выполнений — 20 миллионов (!) раз.

Выяснилось, что проблема заключалась в проверке корректности заполнения расчетных счетов при формировании списка. 

Когда мы получаем таблицу с платежными поручениями, то формируем из нее еще одну таблицу, для которой из каждой исходной строки делаем еще две:

• со счетом организации, 

• со счетом клиента и датой, которую будем проверять. 

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

Таким образом, во второй таблице у нас получается в 2 раза больше значений, и на этом пересечении мы делаем 20 миллионов итераций. 

Далее мы добавили свертку по счету для новой полученной таблицы. Это удалось сделать, потому что у нас не очень много счетов, с которых идет оплата организации и контрагентам. Также мы добавили индексы по полям поиска. 

Итоговым результатом стало то, что время формирования списка сократилось до 25 секунд. Возможно, это тоже долго, но нужно учесть, что в списке 9000 строк, и он не динамический. 

Как избежать ошибок в будущем?

Учитывая описанные кейсы и время, потраченное на их решение, в дальнейшем мы хотели избежать негативного фидбека по производительности от пользователей. Хотелось бы заранее понимать узкие места, видеть, где нужно «подтюнить» производительность, смотреть на метрики, анализировать их, и на основании этого двигаться дальше. 

Для решения такой задачи мы провели анализ предложений на рынке, посмотрели open source варианты, варианты от вендора, и в итоге остановились на инструменте «Монитор».

Еще одной альтернативой был инструмент 1С:ЦУП, но нам требовалось что-то небольшое и быстро внедряемое. Также важно было видеть ошибки в техническом журнале, долгие запросы, блокировки и взаимоблокировки, и «Монитор» отвечал этим требованиям. 

Мы подключили инструмент для нашей базы за один день и настроили первую MVP-версию алертинга в наш корпоративный мессенджер Пачка с помощью веб-хука.

Расскажу, как мы используем этот инструмент для своих целей.

Возможности «Монитора»  

1. Показывает длительные запросы

Подсистема ранжирует запросы, показывает количество выполнений (в том числе среднее), и время, за которое выполняется каждый запрос. Он может показать контекст СУБД, сам запрос, и транслировать имена таблиц СУБД в названия таблиц 1С. А также может отдельно показать контекст 1С, место вызова данного конкретного длительного запроса. Это очень помогает сразу определить, куда нужно смотреть и что исправлять.

2. Дает возможность смотреть на блокировки

В «Мониторе» можно посмотреть, кто «виновник», а кто «жертва», и понять контекст, чтобы быстро решать проблему без погружения в журналы. 

3. Дает возможность легко настроить алертинг по трэш-холдам

Это было одним из главных преимуществ для нас при выборе. Из коробки решение умеет отправлять алерты в Telegram, но ничего не мешает настроить их отправку на свой сервис либо на веб-хук корпоративного мессенджера. 

Выводы

На стабилизирование блока «Казначейство» у нас ушло около двух месяцев. По их итогам я сформулировал три рекомендации, которые могут помочь вам в существующих проектах либо при будущих внедрениях.

1. Проводите нагрузочные тесты до запуска проекта на пре-продакшн средах.

Как я рассказывал в начале, мы не смогли их провести из-за сжатых сроков. При проведении нагрузочного тестирования мы бы еще до запуска проекта поняли, что обмен с банком работает не так, как хотелось бы. На этом этапе следовало сделать первый подход к переводу процесса работы с банковскими выписками на многопоток через «Длительные операции», и тогда после запуска нам было бы гораздо проще работать. И потратив время на анализ ДО, мы могли бы переехать на «Менеджер потоков».

2. Если стандартные решения не удовлетворяют вашим требованиям, не бойтесь вносить в них изменения, но подходите к этому осознанно. 

Мы довольно глубоко поменяли логику работы в обработке обмена с банком, но сделали это таким образом, что по факту у нас поменялся вызов типовых методов. То есть мы создали свою обертку, которая запускает многопоточное выполнение в фоне, возвращает его на клиент, дообрабатывает, выводит пользователю список и обновляет форму.

3. Внедряйте системы мониторинга с возможностью настройки алертов.

Это критически важный шаг. Он позволяет не только оперативно реагировать на проблемы, но и предотвращать их появление. Обязательно необходимо внедрять систему мониторинга с возможностью настройки алертов. Конечно, можно настроить APDEX, но когда ты узнаешь о проблеме от пользователя, это не решение. 

Спасибо за внимание! В комментариях буду рад обсудить ваш опыт по решению похожих задач и обменяться мнениями.