← На главную

Проведение регламентного документа Расчет себестоимости выпуска — одна из самых ресурсоемких операций в производственных конфигурациях 1С (таких как 1С:УПП и 1С:Комплексная автоматизация). На практике часто возникает ситуация, когда в начале года расчет выполняется за несколько минут, а к концу года или по мере роста базы время проведения увеличивается до нескольких часов. Разберем по шагам, почему возникает деградация производительности, как правильно локализовать узкое место и какими методами можно существенно сократить время выполнения процедуры.

1. Диагностика узких мест: учетные данные против производительности сервера

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

1. Замер производительности в конфигураторе. Проведем тестовый расчет себестоимости на копии базы данных в монопольном режиме с включенным замером производительности. Это позволит увидеть конкретные строки модулей и запросы, на которые тратится свыше 80% общего процессорного времени.
2. Использование инструментов мониторинга (ЦУП, технологический журнал). Анализируем длительные серверные вызовы, блокировки и очереди к дисковой подсистеме. Если процессор СУБД или сервера приложений загружен минимально, задержки часто вызваны ожиданием дисковых операций или неоптимальными планами выполнения запросов.
3. Оценка однопоточности алгоритма. Важно помнить, что типовой алгоритм расчета себестоимости при партионном учете выполняется в один поток в рамках одной пользовательской сессии. Соответственно, решающее значение имеет высокая тактовая частота одного ядра процессора (CPU Single-Thread Performance), а не общее количество ядер на сервере.

2. Методологические причины замедления и оптимизация структуры учета

Как показывает практика, в подавляющем большинстве случаев источник проблемы кроется в структуре учетных данных и способах их заполнения:

1. Сверхобъемные документы списания и распределения затрат. При использовании «котлового метода» списание материалов на выпуск часто фиксируется документами Распределение материалов на выпуск, содержащими предельное число строк (вплоть до 99 999 строк). Формирование колоссальных промежуточных таблиц распределения при сопоставлении с выпусками приводит к квадратичному росту сложности алгоритма. Разукрупнение документов, разбиение распределений по отдельным производственным сменам или номенклатурным узлам многократно сокращает объем обрабатываемых массивов за один проход.
2. Накопление остатков в незавершенном производстве (хвосты НЗП). Если затраты на счетах 20, 23, 25, 26 или в регистрах незавершенного производства закрываются не полностью, алгоритм расчета с каждым новым месяцем обрабатывает все увеличивающийся массив нераспределенных зависших остатков прошлых периодов. Это объясняет прогрессирующий рост времени проведения от января к декабрю. Регулярная инвентаризация и списание копеечных остатков НЗП полностью устраняют эту нагрузку.
3. Кольцевые зависимости и встречный выпуск. Если полуфабрикаты одного подразделения передаются в другое, а затем возвращаются обратно в рамках одного периода, запускается циклический пересчет до достижения заданной погрешности. Для устранения долгих итераций необходимо явно заполнять регистр правил встречного выпуска или фиксировать порядок переделов подразделений вручную через соответствующий регистр сведений.
4. Отрицательные остатки и нарушение партионной последовательности. Наличие несписанных остатков со знаком «минус» или смещение границы последовательности партий вынуждает алгоритм производить дополнительные выборки по всей глубине истории учета, что многократно увеличивает время проведения.
5. Выбор между партионным учетом и РАУЗ. При традиционном партионном учете перебор партий и списание по методам FIFO/LIFO на больших объемах данных создают огромную нагрузку. Переход на режим расширенной аналитики учета затрат (РАУЗ) заменяет партионный перебор решением системы линейных уравнений, что обеспечивает стабильное и быстрое время проведения даже на крупных производственных базах.

3. Настройка СУБД и системного окружения

Параллельно с оптимизацией учетных данных проверим и настроим параметры работы базы данных на сервере СУБД:

1. Управление базой TempDB (для MS SQL Server). В процессе расчета себестоимости формируются сотни временных таблиц. Разделим файл данных tempdb.mdf на несколько файлов одинакового размера (по числу физических ядер процессора, но не более 8), вынесем их на высокоскоростной SSD/NVMe-диск и зададим фиксированный шаг автоувеличения в мегабайтах, чтобы исключить фрагментацию.
2. Ограничение параллелизма (MAXDOP). Для серверов баз данных под управлением MS SQL при работе с 1С рекомендуется устанавливать параметр Max Degree of Parallelism в значение 1. Это исключит построение неоптимальных параллельных планов выполнения сложных запросов внутри транзакций расчета.
3. Актуализация итогов регистров накопления. Перед проведением регламентных операций закрытия месяца обязательно выполним сдвиг границы рассчитанных итогов регистров накопления на конец закрываемого месяца. Если итоги не рассчитаны, чтение остатков происходит путем сплошного сканирования всех движений с момента создания базы.
4. Оптимизация параметров PostgreSQL (при использовании платформы на Linux/Postgres). Настроим параметры памяти: увеличим work_mem для исключения сброса временных таблиц на диск при сортировках, выставим корректные значения shared_buffers и maintenance_work_mem. Также ограничим параметры join_collapse_limit и from_collapse_limit (значения от 1 до 8), чтобы планировщик запросов PostgreSQL не тратил избыточное время на перебор сотен вариантов соединений таблиц.
5. Разрядность серверного процесса. Убедимся, что служба ragent сервера приложений 1С запущена в 64-разрядном режиме. Это предотвратит аварийное завершение сессий по нехватке адресного пространства оперативной памяти (лимит 2–4 ГБ для 32-битных процессов) при обработке тяжелых матриц распределения.

4. Поэтапное разделение регламентного расчета

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

1. Первый документ: только расчет прямых производственных затрат и распределение материалов.
2. Второй документ: распределение косвенных и общехозяйственных расходов (статьи затрат счетов 25, 26).
3. Третий документ: окончательный расчет фактической себестоимости выпуска готовой продукции и полуфабрикатов.

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