Ускорение производительности продуктов 1С:ERP
Содержание
Большинство компаний, которые пользуются продуктами 1С, со временем сталкиваются с трудностями, связанными с неудовлетворительной производительностью. Это может быть связано с резким ростом количества пользователей, с переходом на новое железо, с добавлением нового функционала и т.д.
Особенно часто с этим сталкиваются пользователи продукта 1С:ERP, так как это комплексная система, в которой работает большинство сотрудников предприятия, в том числе и руководство компании. А значит от скорости работы с этой системой зависит скорость бизнес-процессов компании. Если 1С:ERP работает медленно, то снижается эффективность работы сотрудников, снижается скорость принятия решения.
В чем выражается проблема низкой производительности 1С:ERP?
Проблемы с производительностью могут проявляться по-разному, вот несколько наиболее частых сценариев:
- Все (или почти) пользователи жалуются на то, что программа работает медленно: приходится постоянно ждать, когда откроются окна, проведутся документы, а на формирование отчета уходит значительное количество времени.
- Если открыть показатели мониторинга системы, то они все будут завышены, что означает, что система едва справляется с обработкой данных в ней.
- Пользователи сталкиваются с проблемой проведения какого-то одного документа, например, заказ поставщику или реализация товаров и услуг. И при этом, если запустить эту операцию в тестовой среде или в нерабочее время на продуктивной среде, проблема не будет воспроизводиться, все документы будут формироваться быстро.
- Часть пользователей жалуются на медленную работу системы, но при этом они выполняют разные задачи, то есть проблемы производительности локализованы в разных местах, которые являются узким местом, но источники не обнаружены.
- Произошли существенные изменения условий работы системы, например, обновили платформу или релиз конфигурации, внесли новые доработки в систему, добавилось значительное количество одновременно работающих пользователей, и в результате программа начала «тормозить».
Какие есть варианты решения проблемы торможения 1С:ERP?
Проверить настройки аппаратного обеспечения
Из нашего опыта можем отметить, что достаточно частая ошибка при первоначальных настройках ПО, влияющая на производительность 1С — это не активированный режим энергосбережения «Высокая производительность» на сервере Microsoft SQL. А на PostgreSQL следует отключить Energy Saving, иначе могут вырасти задержки ответов из базы данных.
Все эти рекомендации подробно описаны на сайтах вендоров, а на партнерских сайтах 1С можно почерпнуть и другие примеры best practices по настройке сервера. Но также часто подобрать оптимальные настройки можно только путем различных экспериментов, подбирая те или другие параметры. Для подобных экспериментов нужна, конечно, тестовая база, так как времени на это может уйти немало.
Неоптимальный код
Это самый важный пункт, причем код может быть не оптимальным как в типовых конфигурациях, так и в самописных модулях.
Найти этот код помогает анализ технологического журнала, который показывает самые длительные запросы СУБД и 1С, переписав которые можно снизить нагрузку в системе. Если мы говорим о программе 1С:ERP, то просмотреть весь код будет просто невозможно, нужно знать, в каком месте работать с кодом.
Ускоряем производительность 1C:ERP для фарфорового завода
Проблема заказчика
Компания-заказчик — один из крупнейших заводов по производству фарфора в России, ежедневно принимающая большое количество заказов на производство производство изделий.
Предпосылкой проекта по оптимизации производительности стало то, что основной информационной системе — 1С:ERP — стало требоваться больше времени на выполнение операций по формированию и удалению заказов.
Замер производительности и анализ технологического журнала показывал отсутствие одной нагружаемой операции или так называемого «бутылочного горлышка» — проблемы, которая вызывает 90% падения производительности.
Суть работы данного механизма — это проведения/отмена проведения/пометка удаления большого количества документов в цикле фонового задания.
Анализ кода операции показал, что фоновое задание перебирает все связанные документы для этого заказа, перебор документов идет в цикле.
Статистика производительности
Были проведены четыре замера времени при разных значениях формирования этапов производства:
| № | Количество | Длительность |
|---|---|---|
| 1 | 100 | 0 час. 3 мин 14 сек |
| 2 | 40 000 | 1 час. 14 мин 12 сек |
| 3 | 100 000 | 3 час. 6 мин. 29 сек. |
| 4 | 300 000 | 9 часов 39 мин. 1 сек |
* на примере товара: артикул 81.13748.00.1 из номенклатуры: "чашка с блюдцем [к]/Галантный/Классическая – 2/ Костяная" с характеристикой: "Комплектовка комплектов ГП 9000 СОРТ1"
Решение
В ходе анализа было выявлено допустимое количество операций на 40 000 документов, поэтому улучшения каких-либо запросов или обращений через ток не дали бы весомого улучшения, так как среднее время каждой операции достаточно маленькое, а выполнения той или иной процедуры, в процентном соотношении распределено достаточно плавно.
Однако, если развести сделать обработки на несколько параллельных фоновых заданий, то применимость транзакции будет неприемлема, так как:
- у каждого фонового задания будет свой сеанс, а значит и свои транзакции;
- одно из основных свойств транзакции — изолированность, то есть транзакции одного фонового задания никак не могут повлиять на транзакции другого фонового задания;
- возникновение ошибки при обработке документов, в одном фоновом задании, приведет к отмене действий части документов обрабатываем только этим фоновым заданием, что недопустимо при работе данного механизма.
При решении задач на распараллеливание вычисления был предложен следующий вариант распределения нагрузки серверов:
Таким образом фоновые задания стали отрабатываться на отдельном рабочем сервере. При возрастании нагрузки количество рабочих серверов может быть увеличено, в том числе, если распределить не просто вынос всех фоновых заданий на отдельный рабочий сервер, а только определенных фоновых заданий, таких как фоновое задания по удалению/созданию этапов производства.
Так как каждое такое фоновое задание обрабатывает большую партию «маленьких» документов, то было предложено взять рабочий сервер с большим количеством ядер, даже в ущерб производительности тактовой частоты.
Результаты
Чтобы обеспечить работу единой транзакционной модели для параллельной работы в фоновых заданиях, был отработан механизм сообщений между фоновыми заданиями.
При распараллеливании тяжелых операций прирост производительности кратно увеличился. Клиент перешел с версии ПРОФ на КОРП, и смог вынести фоновые задания на отдельный сервер. Если сравнивать пиковые часы до оптимизации и после, то прирост мог составить в 3 раза.
В итоге, компания смогла увеличить количество проведенных заказов в месяц на 20%.
