Каждый системный администратор и разработчик 1С рано или поздно сталкивается с ситуацией, когда сервер СУБД или сервер приложений 1С начинает работать на пределе своих возможностей. Типичный сценарий: запускается штатное групповое перепроведение документов в конфигурации «1С:Управление торговлей» (или любой другой современной конфигурации на управляемых формах), и загрузка процессора мгновенно взлетает до 100%. При этом пользователи начинают жаловаться на жуткие зависания, а консоль администрирования показывает странную картину — даже при заблокированных регламентных заданиях сервер продолжает плодить десятки фоновых процессов.
В этой статье мы подробно разберем, почему так происходит, как взаимосвязаны переполнение диска SSD и последующий ступор процессора, а также по шагам настроим СУБД SQL Server для оптимальной работы с платформой «1С:Предприятие 8.3».
---
Проанализируем сначала одну из главных странностей, которая часто вводит в заблуждение администраторов. В консоли администрирования 1С установлена галочка «Блокировка регламентных заданий», но в списке активных сеансов все равно отображается множество фоновых заданий.
Выясним причину этого поведения платформы. Дело в том, что в архитектуре 1С понятия «регламентное задание» и «фоновое задание» не тождественны:
Современные конфигурации, такие как «1С:Управление торговлей 11», «1С:ERP» или «1С:Комплексная автоматизация», активно используют асинхронную модель работы и многопоточность. При групповом перепроведении документов или расчете себестоимости система не выполняет все операции в один поток. Вместо этого программный код делит массив документов на пакеты и инициализирует их параллельную обработку.
Для этого в коде вызывается метод ФоновыеЗадания.Выполнить(). Эти задания создаются программно «на лету» непосредственно из сеанса пользователя, который запустил обработку. Платформа считает их интерактивными действиями пользователя, поэтому блокировка регламентных заданий по расписанию на них никак не влияет. В результате сервер приложений создает множество потоков rphost, каждый из которых нагружает свое ядро процессора.
---
Рассмотрим ситуацию, когда перед возникновением проблемы на сервере временно заканчивалось свободное место на SSD-диске, где расположены файлы баз данных. Казалось бы, после очистки диска и удаления лишних файлов производительность должна вернуться в норму, но процессор продолжает работать на 100%. Почему так происходит?
В работе СУБД SQL Server при критическом уменьшении свободного места на диске запускается цепочка негативных факторов:
1. Проблема автоприроста файлов (Autogrow)
Когда СУБД пытается записать новые данные (или расширить системную базу tempdb при формировании временных таблиц 1С), а свободного места на диске физически нет, транзакции начинают ожидать выделения дискового пространства. Если в настройках базы данных шаг автоприроста (Autogrow) задан в процентах (например, по умолчанию 10%), то для крупной базы SQL Server пытается мгновенно занять сразу десятки гигабайт. В этот момент операционная система тратит колоссальные ресурсы на выделение и инициализацию файлов на диске (в логах СУБД это отражается как ожидание типа PREEMPTIVE_OS_WRITEFILEGATHER). Потоки процессора уходят в режим бесконечного ожидания ответа от дисковой подсистемы, утилизируя процессорное время впустую.
2. Сбой планов запросов и деградация статистик
Из-за невозможности записать транзакции СУБД начинает массово аварийно прерывать операции и выполнять откат транзакций (Rollback). Это приводит к колоссальной фрагментации индексов таблиц. Более того, встроенная статистика распределения данных мгновенно теряет актуальность. СУБД строит планы выполнения запросов на основе устаревшей статистики. В итоге вместо быстрого поиска по индексу (Index Seek) SQL Server начинает выполнять полное сканирование огромных таблиц (Table Scan), задействуя все доступные ядра процессора для перебора строк. Даже после освобождения места на SSD старые неоптимальные планы выполнения запросов остаются в кэше СУБД (Plan Cache), и сервер продолжает использовать их, бесконечно перегружая процессор.
---
Для предотвращения подобных коллапсов и снижения нагрузки на CPU необходимо выполнить правильную конфигурацию SQL Server. Разберем ключевые параметры.
Параметр Max Degree of Parallelism (MAXDOP) определяет максимальное количество ядер процессора, которое может быть задействовано для выполнения одного запроса. По умолчанию в SQL Server этот параметр равен 0 (это означает, что тяжелый запрос может захватить вообще все доступные ядра процессора, парализовав работу остальных пользователей).
Для баз данных 1С настоятельно рекомендуется ограничивать параллелизм:
MAXDOP = 1 (полное отключение параллелизма для одного запроса) или 2.2 или 4.Настроить этот параметр можно через SQL Server Management Studio (SSMS) в свойствах сервера на вкладке "Advanced" либо с помощью следующего скрипта:
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'max degree of parallelism', 1;
RECONFIGURE;
Этот параметр указывает СУБД, при какой расчетной «стоимости» запроса стоит начинать дробить его на параллельные потоки. По умолчанию значение равно 5. Для современных процессоров это ничтожно малая величина. Практически любой типовой запрос 1С (особенно при проведении документов) оценивается сервером выше 5, из-за чего SQL Server начинает дробить простейшие операции на несколько потоков, тратя больше ресурсов процессора на координацию этих потоков, чем на само выполнение запроса.
Рекомендуется установить значение Cost Threshold for Parallelism равным 50. Это позволит легким и средним запросам гарантированно выполняться на одном ядре процессора.
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'cost threshold for parallelism', 50;
RECONFIGURE;
При перепроведении документов 1С активно использует временные таблицы, которые физически создаются и обрабатываются в базе tempdb. Если эта база настроена некорректно, она становится «бутылочным горлышком», вызывая затыки процессора.
Выполним правильную настройку tempdb (особенно актуально для SQL Server 2012):
1117 заставляет все файлы базы данных расти одновременно и равномерно, исключая перекосы. Флаг 1118 отключает выделение смешанных экстентов, существенно снижая состязание (contention) за страницы распределения памяти в tempdb. В SQL Server 2012 эти флаги нужно включать вручную в параметрах запуска службы SQL Server (параметры -T1117 и -T1118).---
Если сбой уже произошел, место на диске очищено, но процессор все еще загружен под 100%, выполним регламентные процедуры по реанимации производительности СУБД.
Нам необходимо принудительно заставить SQL Server пересчитать статистику распределения данных в таблицах, чтобы оптимизатор мог строить адекватные планы запросов. Для этого выполним в контексте нашей рабочей базы данных команду:
USE [Имя_Вашей_Базы_1С];
GO
EXEC sp_updatestats;
GO
После обновления статистики старые «плохие» планы выполнения все еще могут оставаться в оперативной памяти сервера. Чтобы СУБД не использовала их, очистим процедурный кэш:
DBCC FREEPROCCACHE;
GO
Обратите внимание: эта операция вызовет кратковременное повышение нагрузки на CPU сразу после запуска, так как все новые запросы начнут компилироваться заново, но это необходимо для очистки зависших неэффективных планов.
Для устранения физической фрагментации таблиц после аварийных отмен транзакций запустим процедуру реиндексации. В зависимости от размера базы и доступного времени (индексация — ресурсоемкий процесс) можно выполнить полное перестроение индексов:
USE [Имя_Вашей_Базы_1С];
GO
-- Пример команды перестроения индекса для конкретной тяжелой таблицы
ALTER INDEX ALL ON [Имя_Таблицы] REBUILD WITH (ONLINE = ON);
GO
Для автоматизации этого процесса на регулярной основе рекомендуется настроить планы обслуживания (Maintenance Plans) в SQL Server.
Очень частая и неочевидная системная проблема: в операционной системе Windows Server по умолчанию может быть включена «Сбалансированная» (Balanced) схема электропитания. В этом режиме операционная система искусственно занижает тактовую частоту ядер процессора в моменты простоя или умеренной нагрузки.
Когда 1С начинает ресурсоемкую операцию проведения, процессор физически не успевает быстро поднять частоту до номинала. В результате в диспетчере задач мы видим пугающие 100% загрузки процессора, хотя фактически он работает на 30-50% от своей реальной максимальной мощности. Обязательно переключите схему электропитания Windows в режим «Высокая производительность» (High Performance).
---
Для стабильного и быстрого проведения документов в связке 1С и SQL Server без пиковых нагрузок на процессор придерживайтесь следующих правил:
MAXDOP и Cost Threshold for Parallelism.