Оптимизация 1С: когда доработки конфигурации эффективнее апгрейда серверов

Алгоритм диагностики

Шаг 1. Выберите значимые для вас ключевые операции.

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

Шаг 2. Зафиксируйте время выполнения каждой операции.

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

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

Статистику следует собрать за достаточно продолжительный период времени чтобы снизить возможную погрешность из-за технических сбоев (ошибки на сервере, сбои сети, ошибка при проведении документа и пр). 1С рекомендует делать не менее 100 замеров для каждой ключевой операции. Мы придерживаемся этой рекомендации.

Важно: статистику полезно смотреть еще и в разрезе пользователей.

Интерпретация результатов

1. Если в нерабочие часы длительность операций значительно меньше – мы имеем дело с проблемой параллельности, т.е. запросы «ждут» своей очереди.

Что проверить: блокировки данных в «1С» или в СУБД, мощность оборудования.

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

Лайфхак: анализировать загрузку процессора важно в разрезе ядер, так как мы можем видеть общую загрузку 50%, а на деле половина ядер загружена полностью, а половина простаивает. Это может быть связано с настройками в BIOS (есть возможность отключить часть ядер) или с типом лицензии 1С (если это ПРОФ-лицензия, то будет использовано максимум 12 ядер процессора, соответственно, если на сервере 24 ядра, то будет использована только половина).

2. Если длительность выполнения операций не зависит от времени – скорее всего проблема в производительности.

Что проверить:

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

Ниже два кейса из нашей практики, отлично иллюстрирующие обе ситуации.

КЕЙС №1.
ОПТИМИЗАЦИЯ КОДА ВМЕСТО АПГРЕЙДА 

Ситуация: крупная компания – ритейлер мясной столкнулась с проблемой медленной работы отдельных операций: долгое открытие форм документов «Заказ клиента» и «Реализация товаров и услуг», долгое проведение, долгое закрытие смены весовщика (нетиповой функционал). Длительность операций напрямую влияла на операционную эффективность ряда бизнес-процессов. Внутренние ИТ специалисты клиента считали, что необходимо купить более мощное оборудование и обратились в ФТО за консультацией по требуемым параметрам для выбора. Мы предложили сделать экспресс-анализ для того, чтобы убедиться в правильности выбранного клиентом решения.

Что сделали

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

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

Решение

• Оптимизирован код ряда модификаций

• в документах «Заказ клиента» и «Реализация товаров» в обработке проведения были долгие операции по расчету бонусов и скидок, которые мы вынесли за рамки транзакции. Логика позволяла делать такой расчет регламентным заданием уже после проведения документов. При открытии форм указанных документов для каждой строки в табличной части «Товары» выполнялся запрос, чтобы в форме справочно отображалась последняя цена продажи. Код был переписан таким образом, чтобы одним запросом получать данные для всей табличной части, т.е. ушли от запроса в цикле.
• по результату анализа логов технологического журнала выделили топ запросов по длительности (за одно выполнение) и по суммарной длительности (все время выполнения за сутки). Практика показывает, что имеет смысл смотреть суммарную длительность, т.к.  сам запрос может выполняться за 2 сек, но количество его выполнений настолько велико, что будет заметный выигрыш от его оптимизации. Для некоторых запросов был переписан текст, для других были проиндексированы поля в регистрах сведений и накоплений.

• Изменены настройки СУБД

• Max degree of parallelism — количество потоков для выполнения одного «тяжелого» запроса (было 0 – использовались все ядра).
• Cost threshold of parallelism — при тестировании пробовали разные комбинации этих настроек. Лучшей комбинацией показала себя MaxDop = 4, Cost = 35 (было 5 – какой должна быть стоимость запроса, чтобы он выполнялся параллельно).

КЕЙС №2.
КОГДА АПГРЕЙД БЕССИЛЕН

Ситуация
Крупный агрохолдинг столкнулся с регулярными «зависаниями» ERP-системы в периоды пиковых нагрузок: приемка урожая, формирование отгрузочных документов для крупных партий, закрытие отчетных периодов. Сотрудники не могли работать, что напрямую сказывалось на скорости поставок и финансовых операциях, могло привести к простоям и штрафам от клиентов. ИТ служба клиента предполагала, что причина в неоптимальном коде: медленные SQL запросы для расчета себестоимости, неоптимальные алгоритмы списания и т.п. Было переписано несколько ресурсоемких процессов, исправлены медленные запросы и добавлены недостающие индексы. Работы не дали ожидаемого результата – в часы массового ввода данных проблема воспроизводилась, отклик системы критически падал. На этом этапе клиент обратился к нам.

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

Вывод
Система хронически не справлялась с текущим объемом работ на предоставленном оборудовании:

• средняя загрузка CPU даже в спокойные периоды стабильно держалась выше 80%,
• свободной оперативной памяти было менее 10%.

Потенциал программной оптимизации был практически исчерпан. Дальнейшие правки дали бы мизерный прирост (1-2%) при непропорционально высоких затратах времени разработчиков.

Решение: направить бюджет на модернизацию «железа» — закупить более мощные процессоры, увеличить объем и скорость оперативной памяти, перейти на быстрые SSD-диски.

Главный урок из практики:
нет универсального решения для решения проблем производительности 1С.

• Измеряйте, а не предполагайте — только метрики дают объективную картину,
• Избегайте привычных решений, таких как «всегда оптимизируем код» или «сразу покупаем сервер».

Комплексный подход к оптимизации 1С позволит не только решать текущие проблемы с производительностью, но и создаст фундамент для стабильной работы системы в будущем. Всегда начинайте с диагностики. Только так получится принять обоснованное решение и верно распределить бюджет.