Переход с редакции 1С:ЗУП 2.5 на 1С:ЗУП 3.0 часто сопровождается неожиданной проблемой: операции, которые штатно и быстро завершаются в файловой информационной базе (например, перенос данных или заполнение документа Начисление зарплаты и взносов), в клиент-серверном режиме «намертво» зависают на стадии фонового задания. Пользователь видит бесконечное выполнение, при этом нагрузка на процессор может быть минимальной или, наоборот, упираться в один поток. Разберем по шагам, почему возникает такое поведение связки «Сервер 1С Предприятия — MS SQL Server» и какими методами можно локализовать и устранить зависание.
Прежде чем менять конфигурацию серверов, выясним причину задержки: действительно ли фоновое задание выполняет тяжелый расчет, зациклилось или вовсе упало с неперехваченной ошибкой. Проанализируем логику фонового задания с помощью вывода контрольных точек в поток сообщений.
Внесем в исполняемый код фонового процесса маркеры прогресса с помощью метода Сообщить():
Сообщить("Моё фоновое задание: НАЧАЛО");
// Блок подготовки данных
Сообщить("Моё фоновое задание: контрольная точка 1 (выборка сотрудников)");
// Блок расчета начислений
Сообщить("Моё фоновое задание: контрольная точка 2 (расчет начислений)");
// Завершение работы
Сообщить("Моё фоновое задание: КОНЕЦ");
Для того чтобы прочитать эти контрольные точки из основного клиентского сеанса или внешней обработки управления заданиями, применим следующий алгоритм:
ФЗ = ФоновыеЗадания.НайтиПоУникальномуИдентификатору(УникальныйИдентификаторФоновогоЗадания);
Если ФЗ <> Неопределено Тогда
МассивСообщений = ФЗ.ПолучитьСообщенияПользователю(Истина);
Для Каждого Сообщение Из МассивСообщений Цикл
Сообщить("Лог фонового задания: " + Сообщение.Текст);
КонецЦикла;
КонецЕсли;
Пошагово сужая диапазон между контрольными точками, мы сможем точно локализовать процедуру или конкретный SQL-запрос, на котором останавливается выполнение.
Конфигурация ЗУП 3.0 активно использует временные таблицы, глубокие соединения и пакетные запросы. Неправильная конфигурация сервера СУБД часто приводит к взаимным блокировкам или катастрофически медленному выполнению планов запросов. Разберем ключевые настройки SQL Server, влияющие на расчет заработной платы:
tempdb на отдельный высокоскоростной диск (SSD/NVMe). Разделим основное хранилище tempdb на несколько файлов данных одинакового размера (по количеству физических ядер процессора, выделенных под SQL, но не более 8 файлов за раз). Это устранит конкуренцию за системные страницы распределения памяти (PFS/GAM).Max Degree of Parallelism (MAXDOP) значением 1. Параллельное выполнение одного составного запроса в 1С часто порождает ожидание CXPACKET и блокирует соседние сессии. В свойствах процессоров SQL Server также проконтролируем параметр max worker threads, увеличив его при большом количестве одновременных подключений.9481, заставляющий использовать старый Cardinality Estimator. Также обязательно включим флаг 2371 для динамического автообновления статистики больших таблиц.
EXEC sp_updatestats;
Параметры самого кластера 1С напрямую влияют на обработку очередей сеансов. Проанализируем настройки рабочего сервера в консоли администрирования 1С:
1C:Enterprise Server Agent, перейдем в каталог srvinfo\reg_xxxx\ и удалим временные папки с сеансовыми данными (префикс snccntx*), после чего запустим службу заново.Перенос данных из ЗУП 2.5 переносит огромный массив кадровых срезов и исторических записей. При первом заполнении документа Начисление зарплаты и взносов типовые механизмы программы пытаются выполнить расчет с учетом всей накопленной истории. Разберем, как облегчить работу конфигурации:
Настройка -> Расчет зарплаты и снимем флаг «Выполняется автоматический перерасчет документов при их редактировании». Это предотвратит запуск тяжелых фоновых цепочек при любом изменении строк документа.Функции для технического специалиста откроем регистры сведений Перерасчет зарплаты и Перерасчет межрасчетных начислений. Если после миграции в них зарегистрировались тысячи записей за прошлые периоды, система будет пытаться пересчитать их все в текущем документе. Очистим эти регистры перед формированием начисления.Начисления проверим вкладку Приоритет. Некорректно перенесенные пользовательские начисления не должны взаимно вытеснять друг друга, иначе алгоритм расчета времени попадает в бесконечный цикл.Если фоновое задание уже висит, выясним его текущее состояние прямо в MS SQL Server Management Studio с помощью системных представлений:
SELECT
r.session_id,
r.status,
r.wait_type,
r.wait_time,
r.last_wait_type,
r.blocking_session_id,
t.text AS [sql_query]
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
WHERE r.session_id > 50;
Проанализируем столбец wait_type:
LCK_M_* — задание ждет освобождения таблицы, заблокированной другим фоновым процессом или регламентным заданием (например, полнотекстовым поиском).PAGEIOLATCH_* — узким местом является дисковая подсистема, сервер не справляется с чтением страниц во временные таблицы.ASYNC_NETWORK_IO — SQL Server подготовил результат запроса, но процесс rphost сервера 1С не считывает его из сокета из-за зависания сетевого стека или перегрузки рабочего процесса.Комплексное применение описанных мер — обновление статистики, отключение паразитных перерасчетов и ограничение параллелизма на SQL-сервере — позволяет стабильно выполнять ресурсоемкие расчеты и перенос данных в ЗУП 3.0 без зависания фоновых заданий.