Расчет себестоимости в конфигурации «1С:Управление производственным предприятием» (УПП) — это одна из самых ресурсоемких и тяжелых операций в экосистеме решений 1С. В процессе проведения документа РасчетСебестоимостиВыпуска система выполняет миллионы математических операций, обращается к огромным массивам данных в регистрах накопления и генерирует гигантский объем транзакций в СУБД. Нередко возникает ситуация, когда запуск этой процедуры намертво «вешает» дисковую систему сервера, останавливая работу всей компании.
В этой статье мы подробно разберем, почему возникает лавинообразная нагрузка на диски, как диагностировать скрытые аппаратные проблемы RAID-контроллеров и какие настройки MS SQL Server и самой платформы 1С помогут оптимизировать процесс закрытия месяца.
Когда СУБД начинает активно записывать данные во время расчета себестоимости, дисковая подсистема подвергается экстремальной нагрузке. Если диски или контроллер работают некорректно, сервер мгновенно «замерзает». Проанализируем основные аппаратные причины этого сбоя:
Write-Back и переходит на режим прямой медленной записи на диски — Write-Through. В результате скорость дисковых операций падает в десятки раз, и очередь к дискам вырастает до критических значений.Reset to device, \Device\RaidPort0, was issued), это означает, что диски перестали отвечать контроллеру в рамках установленного тайм-аута SCSI. Пытаясь восстановить работоспособность, контроллер перезапускает порт, что вызывает кратковременное полное «замораживание» дисковой активности.Для оптимизации работы СУБД во время расчета себестоимости рассмотрим ключевые настройки MS SQL Server, которые напрямую влияют на дисковую активность:
Взрывной рост TempDB: Алгоритмы закрытия месяца в УПП активно используют временные таблицы. SQL Server вынужден непрерывно записывать и читать данные из системной базы данных tempdb. Если файлы этой базы расположены на медленном диске или на одном физическом накопителе с файлами основной базы, дисковая система неизбежно захлебнется. Рекомендуется перенести файлы tempdb на максимально быстрые твердотельные накопители (NVMe SSD) и разделить базу на несколько файлов равного размера (соответствующего числу ядер процессора, но не более 8).
Разрастание журнала транзакций (LDF): При проведении документа себестоимости миллионы записей последовательно фиксируются в журнале транзакций. Если база данных работает в модели восстановления Full (полная), файл журнала транзакций (LDF) будет стремительно разрастаться, создавая непрерывный поток записи на диск. Для решения этой проблемы во время проведения тяжелых расчетов рекомендуется перевести базу данных в модель восстановления Simple (простая) либо настроить регулярное резервное копирование журнала транзакций (каждые 10–15 минут), чтобы своевременно очищать лог.
Выполнить переключение модели восстановления можно с помощью следующего SQL-скрипта:
-- Переключение базы данных в модель Simple
ALTER DATABASE [ИмяВашейБазы] SET RECOVERY SIMPLE;
Неверные настройки параллелизма (MAXDOP): По умолчанию MS SQL Server пытается распараллелить выполнение одного тяжелого запроса на все доступные ядра процессора. При расчете себестоимости это приводит к взаимным ожиданиям потоков (ожидания типа CXPACKET) и перегрузке дискового ввода-вывода. Ограничим параметр параллелизма для оптимизации работы с 1С:
-- Ограничение максимальной степени параллелизма (MAXDOP) до 1 или 2
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'max degree of parallelism', 1;
RECONFIGURE;
Зачастую причина перегрузки сервера кроется не в самом железе, а в некорректных действиях пользователей и специфике работы партионного учета в УПП. Разберем основные проблемы:
РасчетСебестоимостиВыпуска. Попытка рассчитать весь год разом приводит к формированию одной гигантской неделимой транзакции СУБД, которая переполняет оперативную память и дисковый кэш.Чтобы успешно завершить расчет себестоимости без зависания сервера, выполним последовательно следующие шаги:
Шаг 1. Диагностика RAID-массива. Привлеките системных администраторов для детального анализа состояния контроллера. Необходимо запустить утилиту управления RAID (например, MegaRAID Storage Manager или HP Smart Storage Administrator) и убедиться, что:
Optimal.Write-Back.Шаг 2. Разнесение файлов СУБД на разные физические диски. Посмотрим на текущую структуру хранения файлов СУБД. Разнесем их по разным физическим массивам в соответствии со следующими рекомендациями:
tempdb — на быстрые локальные SSD/NVMe диски.Шаг 3. Регламентное обслуживание перед расчетом. Перед запуском проведения документа себестоимости обязательно выполним обновление статистики и реиндексацию таблиц базы данных в MS SQL Server Management Studio с помощью SQL-запроса:
-- Полное обновление статистики СУБД для оптимального построения планов запросов
EXEC sp_updatestats;
Шаг 4. Расчет строго помесячно. Запуск расчета себестоимости выполняем строго в хронологической последовательности. Для автоматизации проведения цепочки документов за несколько месяцев можно использовать простую обработку на встроенном языке 1С:
// Пример последовательного проведения документов расчета себестоимости за период
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| РасчетСебестоимости.Ссылка КАК Ссылка
|ИЗ
| Документ.РасчетСебестоимостиВыпуска КАК РасчетСебестоимости
|ГДЕ
| РасчетСебестоимости.Дата МЕЖДУ &ДатаНачала И &ДатаКонца
|УПОРЯДОЧИТЬ ПО
| РасчетСебестоимости.Дата ПОДЪЕМ";
Запрос.УстановитьПараметр("ДатаНачала", НачалоГода(ТекущаяДата()));
Запрос.УстановитьПараметр("ДатаКонца", КонецГода(ТекущаяДата()));
Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
ДокОбъект = Выборка.Ссылка.ПолучитьОбъект();
Если Не ДокОбъект.Проведен Тогда
Попытка
Сообщить("Начало проведения документа за: " + ДокОбъект.Дата);
ДокОбъект.Записать(РежимЗаписиДокумента.Проведение);
Сообщить("Успешно проведен документ за: " + ДокОбъект.Дата);
Исключение
Сообщить("Ошибка проведения за " + ДокОбъект.Дата + ": " + ОписаниеОшибки());
Прервать;
КонецПопытки;
КонецЕсли;
КонецЦикла;
Шаг 5. Включение режима версионирования строк (RCSI). Этот режим позволяет читать данные из таблиц базы данных без наложения жестких блокировок, что существенно снижает нагрузку на диски при параллельной работе пользователей во время тяжелых регламентных операций:
-- Включение режима READ_COMMITTED_SNAPSHOT для базы данных 1С
ALTER DATABASE [ИмяВашейБазы] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
ALTER DATABASE [ИмяВашейБазы] SET READ_COMMITTED_SNAPSHOT ON;
ALTER DATABASE [ИмяВашейБазы] SET MULTI_USER;
Применение этого комплексного подхода гарантированно позволит стабилизировать работу сервера, исключит «зависание» дисковой подсистемы при расчете себестоимости в 1С:УПП и значительно ускорит процесс закрытия отчетных периодов.