Конец месяца в 1С: почему 30-е число стабильно кладёт базу

MAATRIX

Если вы администрируете сервер с 1С дольше пары месяцев, вы уже знаете этот звонок наизусть: «база встала», «документы не проводятся», «отчёт висит уже двадцать минут». И почти всегда это происходит в последние два-три дня месяца. Не потому что сервер внезапно сломался — а потому что раз в месяц на одну и ту же базу одновременно наваливаются закрытие периода, расчёт зарплаты и попытки полусотни пользователей провести всё, что копилось неделями. Это не авария, а предсказуемый техпроцесс, который почти никогда не закладывают в план мощности, потому что 27 дней из 30 всё работает нормально.

Что физически происходит 28-30 числа

Закрытие месяца в 1С — это не одна операция, а последовательность регламентных заданий, которые запускаются либо вручную бухгалтером, либо по расписанию: «Закрытие месяца» в 1С:Бухгалтерии, «Расчёт себестоимости» в управленческих конфигурациях, переоценка валютных остатков, начисление амортизации, распределение косвенных расходов, закрытие счетов 20/23/25/26/90/91. Каждая из этих операций — не точечная запись в одну таблицу, а пересчёт по всей базе за период: программа проходит по всем документам движения, пересчитывает партии, себестоимость, финансовый результат.

Ключевая особенность: многие из этих шагов строго последовательны. Нельзя посчитать себестоимость, пока не закрыты все затратные счета, нельзя закрыть 90-й счёт, пока не посчитана себестоимость, нельзя сформировать финрезультат, пока не закрыта валютная переоценка. Это цепочка с зависимостями, а не параллельный набор задач — и именно поэтому она долго держит блокировки, а не просто нагружает CPU на пару секунд.

Добавьте к этому банальную человеческую психологию: документы, которые можно было провести равномерно за месяц, откладываются «на потом» — и это «потом» у всех сотрудников наступает одновременно, в последнюю неделю перед сдачей. База получает не только регламентные операции закрытия, но и вал обычного пользовательского проведения поверх них.

Блокировки: почему один зависший документ останавливает всех

1С использует два режима управления параллельностью: автоматический (транзакционные блокировки СУБД) и управляемый (собственные блокировки платформы поверх регистров). В обычный рабочий день конфликты редки — пользователи проводят разные документы, которые трогают разные объекты учёта. В дни закрытия ситуация меняется качественно: регламентные операции читают и изменяют общие регистры — регистр себестоимости, регистр партий, регистр взаиморасчётов, — на которые в это же время претендуют десятки обычных документов.

Классическая цепочка: регламентное задание «Расчёт себестоимости» держит блокировку на регистре накопления, пока идёт пересчёт по всей номенклатуре. Параллельно бухгалтер пытается провести накладную, которая тоже должна записать движение в этот регистр — документ встаёт в очередь ожидания блокировки. Если пересчёт себестоимости идёт по крупной базе 10-40 минут, все документы, претендующие на тот же регистр, эти 10-40 минут просто висят с крутящимся индикатором. Пользователи видят не ошибку, а бесконечное «выполняется» — и, не дождавшись, часто открывают второе окно и пробуют снова, что только добавляет нагрузки.

В файловом режиме (базы на .1CD без выделенного сервера СУБД) ситуация обычно хуже: блокировки грубее, а конкурентный доступ к файлу базы деградирует резче с ростом числа одновременных сеансов. В клиент-серверном варианте (1С + MS SQL Server или PostgreSQL) блокировки точнее, но при большом количестве параллельных операций сервер СУБД начинает упираться в собственные ограничения — количество блокировок, глубина журнала транзакций, конкуренция за tempdb.

Пример типичной картины в час пик закрытия месяца:
23:00-06:00  фоновые регламентные задания (если настроено расписание)
09:00-11:00  обычная рабочая нагрузка, документы проводятся штатно
11:00-13:00  бухгалтер запускает "Закрытие месяца" вручную
13:00-15:00  пик блокировок: расчёт себестоимости держит регистры,
             десятки пользователей ждут проведения своих документов
15:00-16:00  формирование отчётности поверх свежезакрытого периода —
             тяжёлые запросы к базе, конкуренция за CPU и диск

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

Расчёт зарплаты — второй пик поверх первого

Отдельная головная боль в том, что расчёт зарплаты в 1С:ЗУП или в зарплатном блоке комплексной конфигурации часто приходится на те же самые последние дни месяца — потому что расчёт зависит от отработанного времени за весь период, а окончательные данные табеля появляются только к его концу. Начисление зарплаты по полусотне-две сотни сотрудников — это тоже пакетная операция, которая перебирает сотрудников, начисления, удержания, взносы, и в момент расчёта активно пишет в регистры расчётов, которые могут пересекаться с бухгалтерскими проводками при одновременном формировании межрасчётных отчётов.

Если зарплата и бухгалтерское закрытие месяца в вашей организации технически размещены в одной базе (частая ситуация в небольших и средних компаниях, где не разделяют ЗУП и Бухгалтерию на отдельные информационные базы), эти два процесса накладываются друг на друга физически, на одном и том же сервере СУБД. Каждый по отдельности создаёт терпимую нагрузку; вместе, в одно и то же окно, — уже нет.

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

Почему это не попадает в план мощности

Стандартный подход к расчёту ресурсов для сервера — посмотреть среднюю нагрузку и заложить запас сверху. Проблема в том, что средняя нагрузка за месяц почти ничего не говорит о пике в последние три дня: если 27 дней CPU занят на 20-30%, а три дня — на 85-95%, среднее по месяцу останется скромным числом, по которому легко занизить конфигурацию сервера. При выборе VPS или выделенного сервера ориентируются на конфигурацию, которая комфортно тянет обычный день — а дни закрытия просто не рассматривают как отдельный сценарий, потому что «ну это же всего пара дней».

Это тот же класс ошибки, что при планировании под сезонный трафик в интернет-магазине или при расчёте мощности под маркетинговую кампанию — только здесь цикл не годовой и не разовый, а ежемесячный и постоянный. У сезонного бизнеса пик раз в год можно списать на форс-мажор и решить точечно; у 1С пик приходит каждые 30 дней с завидной регулярностью, и именно поэтому его логичнее закладывать в базовую архитектуру, а не тушить пожар заново каждый месяц.

Вторая причина, по которой пик игнорируют — он не всегда виден в стандартном мониторинге. Если алерты настроены на пороги вроде «CPU > 90% в течение 5 минут — тревога», то дни закрытия месяца либо генерируют шквал ложных срабатываний (потому что high CPU в эти дни — норма), либо, если пороги ослаблены «чтобы не спамило», реальную деградацию в обычные дни пропускают. О том, как настраивать алерты так, чтобы они не превращались в шум на каждый скачок нагрузки, у нас есть отдельный разбор — это применимо и к 1С-нагрузке, где обсуждается, как отличить ожидаемый пик от реальной проблемы.

Как увидеть цикл на своих графиках

Прежде чем что-то менять, стоит убедиться, что описанный паттерн действительно у вас есть и понять его реальные границы — не «примерно в конце месяца», а конкретные дни и часы. Для этого достаточно недорогого мониторинга с историей хотя бы за 2-3 месяца:

• CPU и load average по дням месяца. Постройте график за 60-90 дней и наложите дни друг на друга — если пик стабильно приходится на одни и те же числа (обычно 28-31 и первые 1-3 рабочих дня следующего месяца, когда доделывают то, что не успели), паттерн подтверждён.
• IO диска и latency. Регламентные операции закрытия — это в первую очередь дисковая нагрузка: чтение больших объёмов движений и запись пересчитанных итогов. На медленном диске (тем более сетевом с высокой задержкой) фаза закрытия растягивается непропорционально сильно по сравнению с CPU-нагрузкой.
• Число активных блокировок / ожиданий в СУБД. Если у вас MS SQL Server или PostgreSQL под 1С, штатные средства (Activity Monitor, pg_stat_activity) покажут рост числа сессий в состоянии ожидания блокировки именно в часы закрытия — это прямое подтверждение механизма, описанного выше, а не просто «сервер медленный».
• Число одновременных сеансов 1С. В консоли кластера серверов 1С (или в технологическом журнале) видно, сколько сеансов активно и сколько документов проводится параллельно — это число обычно заметно выше среднего в последние дни месяца.

Собрать эти графики в одном месте удобнее через Grafana поверх метрик СУБД и ОС — мы разбирали настройку мониторинга баз данных через Grafana отдельно, включая то, какие метрики СУБД реально стоит выводить на дашборд, а какие только засоряют картину.

Что реально помогает: и по железу, и по процессу

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

Технические меры:

• Выносить тяжёлые регламентные операции на ночь или раннее утро, когда пользователей в базе почти нет. Не всё закрытие можно автоматизировать полностью (часть шагов требует ручной проверки бухгалтером), но расчёт себестоимости, амортизацию, переоценку валюты можно и нужно ставить по расписанию на минимально загруженное время через регламентные задания или внешние планировщики.
• Держать запас по CPU и диску именно под пиковые дни, а не под средний день месяца. Если у вас облачный сервер с возможностью временного апгрейда конфигурации, дни закрытия — ровно тот случай, когда стоит на 3-5 дней в месяц поднять число ядер или переехать на более быстрый диск (NVMe вместо сетевого SSD ощутимо сокращает время регламентных операций, которые упираются в IO). Разово посчитать, сколько ресурсов реально нужно под вашу базу и число пользователей, помогает отдельный разбор по подбору VPS под 1С.
• Убедиться, что СУБД настроена под пиковую нагрузку, а не только под обычный день: размер tempdb (для MS SQL) заранее увеличен и не растёт «на лету» в момент пика, autovacuum в PostgreSQL не запускается одновременно с закрытием месяца, журнал транзакций не упирается в диск.
• Разделить конкурирующие процессы во времени, если это возможно организационно: не запускать расчёт зарплаты и закрытие бухгалтерского периода в одно и то же окно на одной базе, развести регламентные задания разных модулей по расписанию так, чтобы они не боролись за одни и те же регистры одновременно.

Организационные меры, которые снижают нагрузку не хуже железа:

• Договориться с бухгалтерией о равномерном проведении документов в течение месяца, а не скопом в последние дни — это снижает объём операций, которые накладываются на регламентное закрытие.
• Предупреждать пользователей заранее о датах закрытия месяца, чтобы плановые тяжёлые отчёты (например, для руководства) формировались либо до, либо после пиковых дней, а не в разгар закрытия.
• Если база растёт и пик усугубляется от месяца к месяцу — это сигнал считать конфигурацию сервера по актуальному числу пользователей и размеру базы, а не по конфигурации, которая была куплена два-три года назад. Похожая логика разбора применима и к общему расчёту конфигурации сервера под нагрузку — просто с той оговоркой, что для 1С пик наступает не от внешнего трафика, а от внутреннего регламента.

Ни одна из этих мер не «чинит» 1С — блокировки при последовательном закрытии счетов никуда не денутся, это архитектурная особенность платформы. Но правильно посчитанный запас по ресурсам и разведённые по времени процессы превращают «база встала и все на нервах» в «сегодня медленнее обычного, но работать можно» — и это уже совсем другой разговор с бухгалтерией.

Частые вопросы