Как устранить взаимные блокировки и ускорить совместный расчет зарплаты в 1С на MS SQL Server?

← На главную

При совместной работе нескольких расчетчиков в базах данных на устаревших архитектурах (таких как «1С:Зарплата и управление персоналом 2.5» или «1С:Медицина. Зарплата и кадры бюджетного учреждения 1.0») часто возникает ситуация, когда один пользователь запускает расчет заработной платы, а остальные расчетчики вынуждены ждать окончания этой операции. Система зависает, производительность падает, а процесс расчета затягивается на несколько дней. Особенно остро эта проблема проявляется, когда вся инфраструктура (сервер СУБД, сервер приложений 1С и терминальный сервер RDP) развернута на одном физическом компьютере под управлением клиентской операционной системы Windows 10.

В этой статье мы подробно проанализируем причины возникновения подобных блокировок и зависаний, а также разберем по шагам комплекс мер по оптимизации работы СУБД MS SQL Server, операционной системы и самой конфигурации 1С для восстановления комфортной многопользовательской работы.

Выясняем причины проблемы: почему возникают зависания?

Прежде чем переходить к настройкам, давайте разберем физику процесса. В рассматриваемой конфигурации (ЗБУ 1.0 / ЗУП 2.5) по умолчанию используется автоматический режим управления блокировками. Это накладывает серьезные ограничения на параллельную работу:

Уровень изоляции SERIALIZABLE: При проведении документов расчета СУБД MS SQL Server вынуждена использовать самый жесткий уровень изоляции транзакций. Это предотвращает появление «фантомных строк», но приводит к тому, что СУБД блокирует целые диапазоны индексов в регистрах расчета (например, «Основные начисления» или «Дополнительные начисления»).
Эскалация блокировок: Когда документ рассчитывает большое количество сотрудников (или обрабатывает объемные таблицы начислений), транзакция задействует тысячи строк. Как только количество заблокированных строк в одной таблице превышает 5000, MS SQL Server выполняет автоматическую эскалацию блокировки — закрывает монопольным замком (TABLOCKX) всю таблицу целиком. В этот момент любой другой расчетчик, пытающийся провести свой документ, встает в очередь ожидания.
Конкуренция за ресурсы «все в одном»: Если СУБД, Сервер 1С и 12 RDP-сессий запущены на одном клиентском процессоре (например, i7-4770) с 32 Гб оперативной памяти, то физические ресурсы компьютера мгновенно исчерпываются. Начинается борьба за оперативную память и дисковую очередь единственного SSD-накопителя, из-за чего время удержания транзакций и блокировок увеличивается многократно.

Рассмотрим подробнее пошаговый план решения этой проблемы, начиная от простых системных настроек и заканчивая методическими изменениями в работе пользователей.

Шаг 1. Включение режима Snapshot Isolation (RCSI) в MS SQL Server

Для того чтобы читающие запросы (отчеты, расчетные листки, кадровые списки) не блокировались пишущими транзакциями (проведение расчетов), и наоборот, необходимо перевести базу данных в режим snapshot-изоляции (Read Committed Snapshot Isolation). Это позволит СУБД отдавать читающим пользователям согласованные версии строк из временной базы данных tempdb без наложения реальных блокировок на таблицы базы.

Выполним этот переход. Для этого откроем SQL Server Management Studio (SSMS), создадим новый запрос к нашей базе данных и выполним следующий скрипт:


ALTER DATABASE [Имя_Вашей_Базы] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
ALTER DATABASE [Имя_Вашей_Базы] SET READ_COMMITTED_SNAPSHOT ON;
ALTER DATABASE [Имя_Вашей_Базы] SET MULTI_USER;

Важное примечание: Этот шаг существенно облегчит жизнь кадровикам и тем расчетчикам, которые формируют отчеты во время проведения документов. Однако он не решает проблему на 100%, если два расчетчика одновременно пытаются производить запись в одни и те же таблицы регистров. Перейдем к оптимизации ресурсов сервера.

Шаг 2. Настройка параметров параллелизма СУБД (MAXDOP)

По умолчанию в MS SQL Server параметр Max Degree of Parallelism (MAXDOP) равен 0. Это означает, что один «тяжелый» запрос на расчет заработной платы может задействовать все доступные ядра процессора (в нашем случае — все 8 вычислительных потоков процессора i7). В результате СУБД монополизирует процессорное время, вызывая взаимные ожидания потоков (CXPACKET) и парализуя работу остальных 11 терминальных сессий.

Для оптимизации работы систем на платформе 1С настроим параметры параллелизма СУБД. Рекомендуется установить максимальную степень параллелизма для одного запроса равной 1. Выполним в SSMS следующий скрипт:


EXEC sys.sp_configure N'show advanced options', N'1' RECONFIGURE WITH OVERRIDE;
GO
EXEC sys.sp_configure N'max degree of parallelism', N'1' RECONFIGURE WITH OVERRIDE;
GO
EXEC sys.sp_configure N'cost threshold for parallelism', N'50' RECONFIGURE WITH OVERRIDE;
GO
EXEC sys.sp_configure N'show advanced options', N'0' RECONFIGURE WITH OVERRIDE;
GO

Установка max degree of parallelism в значение 1 гарантирует, что один сложный запрос будет обрабатываться в рамках одного процессорного ядра, оставляя остальные ресурсы свободными для других пользователей.

Шаг 3. Жесткое ограничение оперативной памяти для SQL Server

Когда СУБД, Сервер 1С (процессы rphost.exe) и терминальные сессии пользователей работают в рамках одной операционной системы с объемом ОЗУ 32 Гб, может произойти критическое исчерпание памяти. Каждая запущенная сессия 1С в режиме терминала потребляет около 1-1.5 Гб памяти. 12 активных пользователей заберут до 18 Гб ОЗУ. Серверу приложений 1С требуется еще около 4 Гб, операционной системе — 2-3 Гб.

Если СУБД SQL Server не ограничить, она захватит всю оставшуюся и доступную память под свой кэш (Buffer Pool). Это приведет к тому, что Windows начнет сбрасывать данные RDP-сессий и процессов 1С в файл подкачки (pagefile.sys) на SSD, вызывая катастрофические задержки ввода-вывода.

Проанализируем доступные ресурсы и установим жесткий лимит для SQL Server на уровне 8 Гб (8192 Мб). Выполним скрипт:


EXEC sys.sp_configure N'show advanced options', N'1' RECONFIGURE WITH OVERRIDE;
GO
EXEC sys.sp_configure N'max server memory (MB)', N'8192' RECONFIGURE WITH OVERRIDE;
GO
EXEC sys.sp_configure N'show advanced options', N'0' RECONFIGURE WITH OVERRIDE;
GO

Это гарантирует стабильную работу операционной системы и предотвратит уход процессов 1С в виртуальную память (своп).

Шаг 4. Оптимизация дисковой подсистемы и базы TempDB

Поскольку в системе используется единственный SSD-накопитель объемом 120 Гб, на нем одновременно лежат операционная система, файлы баз данных 1С (.mdf и .ldf), а также временная база данных СУБД tempdb. В режиме включенной snapshot-изоляции нагрузка на tempdb возрастает многократно, так как именно туда пишутся версии строк при изменениях.

Для ускорения дисковых операций выполним следующие действия:

Разделение файлов TempDB: По умолчанию база tempdb создается с одним файлом данных. Нам необходимо разбить ее на несколько файлов одинакового размера (рекомендуется создавать количество файлов, равное числу физических ядер процессора — в нашем случае 4 файла). Это устранит внутреннюю конкуренцию СУБД за распределение страниц (проблемы SGAM/PFS). Выполним скрипт реорганизации:
```
ALTER DATABASE tempdb MODIFY FILE (NAME = tempdev, SIZE = 2048MB, FILEGROWTH = 512MB);
-- Добавляем дополнительные файлы (пути укажите актуальные для вашей системы)
ALTER DATABASE tempdb ADD FILE (NAME = tempdev2, FILENAME = 'C:\SQLData\tempdb2.ndf', SIZE = 2048MB, FILEGROWTH = 512MB);
ALTER DATABASE tempdb ADD FILE (NAME = tempdev3, FILENAME = 'C:\SQLData\tempdb3.ndf', SIZE = 2048MB, FILEGROWTH = 512MB);
ALTER DATABASE tempdb ADD FILE (NAME = tempdev4, FILENAME = 'C:\SQLData\tempdev4.ndf', SIZE = 2048MB, FILEGROWTH = 512MB);
```
Простая модель восстановления (Simple Recovery Model): Убедимся, что для рабочей базы 1С установлена простая модель восстановления. Это предотвратит бесконтрольный рост лога транзакций (.ldf) и снизит нагрузку на запись на единственный SSD: ALTER DATABASE [Имя_Вашей_Базы] SET RECOVERY SIMPLE;
Аппаратное расширение: Настоятельно рекомендуется приобрести дополнительный быстрый NVMe SSD-накопитель (например, через переходник PCI-e, так как на старых платах может не быть разъема M.2) и перенести на него файлы tempdb и файлы логов транзакций рабочей базы. Это физически разделит потоки чтения и записи.

Шаг 5. Тонкая настройка Windows 10 в режиме терминального сервера

Использование клиентской Windows 10 с неофициальными патчами для многопользовательского RDP-доступа несет в себе скрытые проблемы с распределением приоритетов процессов:

Распределение времени процессора: По умолчанию Windows 10 настроена на приоритет работы активных «Программ» (пользовательского интерфейса). Для сервера баз данных это критично, так как фоновые службы (СУБД и сервер 1С) работают с пониженным приоритетом. Перейдем в Свойства системы -> Дополнительные параметры системы -> Быстродействие (Параметры) -> Дополнительно. В разделе «Распределение времени процессора» переключим переключатель в положение «Фоновых служб» (Background Services).
Настройка схемы электропитания: По умолчанию операционная система может переводить ядра процессора в энергосберегающие режимы со снижением частоты (парковка ядер). Перейдем в панель управления электропитанием и жестко установим режим «Высокая производительность» (High Performance).
Использование протокола Shared Memory: Поскольку СУБД и Сервер приложений 1С работают физически на одном компьютере, мы можем исключить сетевой стек TCP/IP из цепочки обмена данными. Для этого в настройках подключения кластера 1С к СУБД в качестве имени сервера баз данных укажем локальную точку или точку с запятой (. или localhost). СУБД автоматически перейдет на протокол работы через общую память (Shared Memory), что ускорит обмен данными между 1С и SQL на 15–20%.

Шаг 6. Методические оптимизации в самой конфигурации 1С

Даже самые лучшие настройки оборудования и СУБД не помогут, если пользователи продолжат работать неэффективно. Проанализируем алгоритм работы расчетчиков и внесем организационные изменения:

Дробление документов расчета: Главная ошибка расчетчиков — создание одного общего документа «Начисление зарплаты» на всю организацию или на огромное подразделение (например, на 1000 и более сотрудников). Проведение такого документа занимает много времени, транзакция длится долго, вызывая эскалацию блокировок. Приучим расчетчиков создавать документы порциями — по конкретным небольшим подразделениям, источникам финансирования или с использованием механизма «Группы сотрудников» (не более 100-150 человек на один документ). Мелкие документы проводятся за секунды, транзакции становятся короткими, и другие пользователи не будут замечать блокировок.
Отключение ограничений на уровне записей (RLS): Если в информационной базе включен механизм RLS (когда каждый расчетчик видит сотрудников только своего ведомства/подразделения), СУБД выполняет сложнейшие запросы с проверками прав доступа при проведении документов. На период массового расчета заработной платы рекомендуется временно отключать RLS или выполнять расчеты под пользователем с Полными правами (у которого RLS не применяется).
Регулярное обслуживание индексов и статистики: Из-за постоянных массовых записей и расчетов таблицы индексов СУБД быстро фрагментируются, а статистика распределения данных устаревает. Настроим ежедневное ночное регламентное задание в MS SQL Server для реорганизации/перестроения индексов и обновления статистик базы данных 1С:
```
-- Обновление статистик для всей базы данных
EXEC sp_updatestats;
```

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