При переходе на современные тяжелые конфигурации класса 1С:ERP администраторы и разработчики часто сталкиваются с критическим падением производительности СУБД в моменты пиковой нагрузки. Типичный сценарий: во время группового обучения или одновременного проведения документов (например, перемещения товаров или внутреннего потребления) процесс sqlservr.exe моментально утилизирует 100% ресурсов процессора, а система «зависает» на несколько минут. Разберем по шагам, почему возникает эта проблема, проанализируем узкие места в инфраструктуре и СУБД, а также настроим сервер для стабильной работы.
Для того чтобы эффективно решить проблему, нам необходимо понять физику процессов, происходящих на стыке платформы «1С:Предприятие», СУБД MS SQL Server и аппаратного обеспечения. На основе представленных симптомов выделим ключевые факторы деградации производительности:
Physical Disk Queue Length), а нехватка ОЗУ заставляет СУБД постоянно сбрасывать кэш планов и данных в файл подкачки, нагружая процессор операциями ввода-вывода.SystemSettings и регистры истории работы). Когда 13 человек работают под единым именем, СУБД сталкивается с постоянной конкуренцией за запись в одни и те же строки. Возникают транзакционные ожидания блокировок (класса LCK_M_X), которые парализуют выполнение любых других операций, включая проведение документов. Кроме того, кэш ограничений доступа (RLS) для одного пользователя постоянно сбрасывается и перестраивается заново из-за параллельных транзакций записи, вызывая лавинообразный рост нагрузки на CPU.SELECT TOP 30 в сочетании с многочисленными LEFT OUTER JOIN к регистрам сведений БСП (таким как ключи доступа пользователей _InfoRg69997, _InfoRg55530, _InfoRg54854) однозначно указывает на работу механизма RLS (Row-Level Security) в динамическом списке. На устаревших версиях СУБД (например, MS SQL Server 2008) оптимизатор запросов часто не справляется с автоматическим расчетом плана выполнения для таких сложных конструкций со множеством параметров. Происходит эффект «залипания параметров» (Parameter Sniffing), из-за которого сервер выбирает неоптимальный план выполнения (например, полное сканирование таблиц Index Scan вместо точечного поиска Index Seek), уводя процессор в 100% нагрузку.Для работы современных конфигураций 1С использование HDD допускается исключительно для хранения резервных копий (бэкапов). Для рабочих баз данных необходимо внедрить скоростные накопители SSD (желательно класса Enterprise с интерфейсом NVMe или SAS). Перестроим дисковую систему по следующему правилу:
.mdf)..ldf). Поскольку запись в лог транзакций происходит последовательно, вынос его на отдельный накопитель исключит взаимное влияние операций чтения из базы данных и записи лога.tempdb, которая активно используется платформой 1С при формировании отчетов, проведении документов и расчете механизмов RLS.Категорически запретим групповую работу под одной учетной записью 1С. Создадим в конфигураторе или в режиме «1С:Предприятие» (в справочнике «Пользователи») индивидуальные карточки для каждого сотрудника. Это позволит:
Для устранения конфликтов блокировок между читающими и пишущими транзакциями, а также для оптимизации планов выполнения тяжелых запросов, выполним ряд настроек на уровне MS SQL Server.
Активация режима версионирования строк (RCSI). По умолчанию MS SQL Server использует пессимистичный режим блокировок. Если один пользователь проводит документ (запись в базу), остальные пользователи не могут открыть журнал документов или отчет (чтение данных) и ждут окончания транзакции. Включение режима Read Committed Snapshot Isolation решает эту проблему. Читающие пользователи будут получать согласованную версию данных из базы tempdb, не накладывая блокировок на читаемые таблицы.
Для включения RCSI выполним следующий скрипт в MS SQL Server Management Studio (SSMS):
USE [master];
GO
-- Переводим базу данных в однопользовательский режим, завершая активные сессии
ALTER DATABASE [ИмяВашейБазыERP] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO
-- Включаем режим snapshot isolation
ALTER DATABASE [ИмяВашейБазыERP] SET READ_COMMITTED_SNAPSHOT ON;
GO
-- Возвращаем базу данных в многопользовательский режим
ALTER DATABASE [ИмяВашейБазыERP] SET MULTI_USER;
GO
Настройка степени параллелизма (MAXDOP). Параметр Max Degree of Parallelism определяет максимальное количество ядер процессора, которое СУБД может выделить на выполнение одного запроса. При значении по умолчанию (0) СУБД может попытаться распараллелить один сложный RLS-запрос на все доступные ядра процессора (в нашем случае — все 4 ядра). В результате один тяжелый запрос полностью парализует работу сервера. Для баз данных 1С настоятельно рекомендуется установить значение MAXDOP = 1.
Выполним настройку через T-SQL:
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
GO
EXEC sp_configure 'max degree of parallelism', 1;
RECONFIGURE;
GO
Борьба с Parameter Sniffing на SQL Server 2008. Чтобы предотвратить зависание планов выполнения для параметризованных запросов 1С, включим глобальный флаг трассировки 4136. Он заставит оптимизатор использовать среднюю избирательность параметров вместо жесткой привязки к первому переданному значению.
Для включения флага выполним команду:
DBCC TRACEON (4136, -1);
GO
Важно: Для того чтобы флаг трассировки автоматически активировался при перезапуске службы SQL-сервера, добавьте параметр -T4136 в параметры запуска службы (SQL Server Configuration Manager -> SQL Server Services -> Свойства службы SQL Server -> вкладка Startup Parameters).
Оптимизация базы TempDB и авторасширения файлов базы. Настроим количество файлов данных базы tempdb равным количеству логических ядер процессора (в нашем случае — 4 файла) и зададим им фиксированный одинаковый размер и шаг авторасширения. Это позволит распределить нагрузку ввода-вывода равномерно.
Также проверим параметры авторасширения (Autogrow) основной базы данных. По умолчанию они могут быть настроены в процентах (например, 10%). При достижении лимита СУБД полностью заблокирует работу пользователей на время выделения нового дискового пространства. Установим фиксированный шаг расширения: например, 512 МБ или 1024 МБ для файлов данных и 256 МБ для файлов лога транзакций.
Если сервер СУБД и сервер приложений 1С развернуты на виртуальной машине VMware, проанализируем следующие критически важные показатели:
CPU Ready. Если значение превышает 5%, это означает, что виртуальная машина простаивает в очереди в ожидании выделения физического процессорного времени от хоста (из-за переподписки процессоров другими виртуальными машинами). Разместим ВМ с СУБД на менее нагруженном хосте или настроим резервирование ресурсов процессора (CPU Reservation).В современных конфигурациях 1С:ERP на платформе 8.3 настроим автоматический перезапуск рабочих процессов кластера (rphost), чтобы исключить деградацию производительности из-за постепенного накопления кэша и фрагментации памяти.
В консоли администрирования кластера 1С зайдем в свойства нашего локального кластера и зададим следующие параметры:
Также проанализируем регламентные задания в режиме «1С:Предприятие» (раздел Администрирование -> Обслуживание -> Регламентные операции). Найдем и оптимизируем расписание для задания «Обновление ключей доступа к данным». По умолчанию оно может запускаться каждые несколько секунд, вызывая жесткие блокировки таблиц RLS. Перенесем ресурсоемкие процедуры обновления ключей доступа на нерабочее время, а частоту запуска ограничим разумными пределами (например, раз в час в периоды минимальной активности пользователей).
Проанализировав ситуацию и выполнив указанные шаги по модернизации железа, разделению учетных записей пользователей и тонкой настройке СУБД, мы сможем полностью устранить зависания и обеспечить стабильное и быстрое проведение документов в нашей системе 1С:ERP.