Закрытие месяца в 1С:ERP Управление предприятием — одна из самых ресурсоемких операций, с которой регулярно сталкиваются пользователи и системные администраторы. В этот период нагрузка на аппаратную часть сервера достигает пиковых значений, а время ожидания результатов расчета может исчисляться часами. В этой статье мы подробно разберем, как архитектура процессора, сетевая инфраструктура и тонкие настройки СУБД влияют на скорость этой процедуры. Мы ответим на классический вопрос: что лучше для закрытия месяца — много медленных ядер или мало быстрых?
Рассмотрим дилемму, представленную в обсуждении: какой сервер приложений 1С покажет себя лучше при закрытии месяца (при условии, что другие пользователи в системе не работают):
Практика и особенности архитектуры платформы «1С:Предприятие» однозначно указывают на то, что Вариант 2 (4 ядра по 4.4 ГГц) будет работать существенно быстрее. Выясним причину такого распределения производительности.
Основная и самая долгая процедура при закрытии месяца — это расчет себестоимости. С математической точки зрения этот процесс представляет собой решение систем линейных алгебраических уравнений (СЛАУ), построенных на основе графа движения материальных ценностей и затрат предприятия. Этот алгоритм по своей природе является последовательным: расчет каждого последующего узла графа зависит от результатов расчета предыдущего. Такую математическую задачу крайне тяжело (а во многих аспектах невозможно) эффективно распараллелить на множество независимых потоков.
В результате во время расчета себестоимости сервер 1С и СУБД нагружают преимущественно одно процессорное ядро на 100%, в то время как остальные ядра могут простаивать или выполнять незначительные фоновые задачи. Таким образом, скорость выполнения этого этапа напрямую зависит от производительности на одно ядро (Single-Thread Performance). Процессор с частотой 4.4 ГГц выполнит последовательные вычисления почти в два раза быстрее, чем процессор с частотой 2.4 ГГц, независимо от того, сколько свободных ядер простаивает рядом.
Несмотря на то, что ядро расчета себестоимости последовательно, современные редакции 1С:ERP (начиная с версии 2.5) позволяют выполнять параллельно некоторые сопутствующие регламентные операции. Разберем по шагам, какими механизмами многопоточности мы можем управлять через интерфейс системы:
СебестоимостьТоваров и ВыручкаИСебестоимостьПродаж. Платформа умеет распределять запись этих данных. Если в настройках операций закрытия отключить опцию «Ожидать окончания записи предыдущей порции этого же регистра», система запустит параллельные фоновые задания на запись. Это существенно ускорит финальную стадию расчета, утилизируя все доступные ядра процессора. Однако здесь важен баланс, так как избыточное параллельное обращение к таблицам может вызвать взаимные блокировки в СУБД.Проанализируем ситуацию, когда сервер 1С и сервер СУБД (например, MS SQL) разнесены на разные физические машины. Даже если между ними проложена высокоскоростная сеть 10 Гбит/сек, задержка передачи пакетов (Network Latency) будет оказывать разрушительное влияние на общую производительность.
При закрытии месяца платформа 1С генерирует так называемый «болтливый» трафик — сотни тысяч и миллионы мелких, последовательных запросов к СУБД. Скорость пропускного канала (ширина шины) в данном случае не играет роли, так как объемы передаваемых данных в рамках одного запроса ничтожно малы (несколько байт). Решающим фактором становится время отклика сети. Если задержка на один сетевой запрос составляет всего 0.5 миллисекунды, то при миллионе запросов мы получим суммарную потерю времени около 500 секунд (более 8 минут) чистого ожидания сети на ровном месте. На реальных базах количество таких микрозапросов может исчисляться десятками миллионов.
Решение: Для достижения максимальной скорости закрытия месяца необходимо размещать сервер приложений 1С и сервер СУБД на одном физическом сервере. Это позволяет настроить их взаимодействие через протокол Shared Memory (общая память). В этом случае обмен данными происходит напрямую через оперативную память сервера в обход сетевого стека операционной системы, что снижает сетевые задержки практически до нуля.
При работе с большими графами затрат в оперативной памяти сервера постоянно создаются огромные временные таблицы. Процессору приходится оперировать гигантскими массивами адресов памяти.
Если объем кэш-памяти третьего уровня (L3 Cache) процессора мал, то ядро процессора будет регулярно сталкиваться с ситуацией кэш-промахов (Cache-misses). В этот момент ядро вынуждено останавливать вычисления и ожидать доставки данных из более медленной оперативной памяти (RAM). Это нивелирует преимущество даже высокой тактовой частоты.
Именно поэтому при выборе процессора для серверов 1С так важен объем L3-кэша. Современные серверные процессоры с технологией увеличенного кэша (например, AMD 3D V-Cache или старшие линейки Intel Xeon) показывают колоссальный прирост производительности на тяжелых расчетных задачах 1С именно за счет того, что все временные таблицы и указатели графа распределения затрат помещаются в сверхбыстрый процессорный кэш.
Настройка СУБД играет ключевую роль в том, насколько эффективно будут использоваться ресурсы процессора.
По умолчанию фирма «1С» рекомендует устанавливать параметр Max Degree of Parallelism (MAXDOP) равным 1. Это запрещает СУБД распараллеливать выполнение одного запроса на несколько ядер, что предотвращает появление неоптимальных планов запросов в повседневной многопользовательской работе.
Однако во время закрытия месяца, когда система монополизирована одним процессом, это ограничение можно обойти. Опытные администраторы баз данных на время тяжелых расчетов повышают MAXDOP до 2 или 4, одновременно увеличивая параметр Cost Threshold for Parallelism (порог стоимости для параллелизма) со стандартного значения 5 до 50–80. Это гарантирует, что СУБД будет распараллеливать только действительно тяжелые, ресурсоемкие расчетные запросы, не тратя процессорное время на параллелизм простых операций.
Если ваша база данных работает под управлением PostgreSQL, критически важно использовать специализированные сборки СУБД, адаптированные для работы с 1С (например, решения от Postgres Pro). Стандартный планировщик ванильного PostgreSQL часто некорректно оценивает стоимость соединений в сложных вложенных запросах 1С, выбирая неоптимальный метод Nested Loop (вложенные циклы) вместо эффективного Hash Join (соединение хешированием). Настройка параметров планировщика и использование актуальной статистики позволяют распределить нагрузку по ядрам процессора наиболее эффективным образом, ускоряя закрытие месяца в разы.
Современные процессоры (как десктопные, так и серверные) по умолчанию работают в режимах динамического изменения частоты для экономии электроэнергии и снижения тепловыделения. При длительной стопроцентной нагрузке на одно или несколько ядер, которая неизбежна при закрытии месяца, процессор может начать снижать частоту Turbo Boost из-за достижения лимитов энергопотребления (TDP) или нагрева.
Чтобы процессор выдавал максимум своей производительности на протяжении всего многочасового расчета себестоимости, выполним следующие настройки:
Подводя итог, можно с уверенностью сказать: для быстрого закрытия месяца в 1С:ERP вам необходим процессор с максимально возможной частотой на одно ядро (не менее 4.0–4.5 ГГц) и большим объемом кэша L3, размещение сервера приложений и СУБД на одной машине с использованием Shared Memory, а также правильная настройка параметров параллелизма в СУБД и электропитания на уровне железа.