Перенос информационной базы «1С:Предприятие» на новый, более мощный сервер — стандартная процедура, от которой все ожидают мгновенного прироста скорости работы. Однако на практике технические специалисты нередко сталкиваются с парадоксальной ситуацией: отчеты, которые на старом «слабом» железе формировались за считанные секунды, на новом сервере начинают выполняться в несколько раз медленнее. Особенно ярко эта деградация проявляется при использовании классического ПостроителяОтчета.
В этой статье мы подробно разберем, почему возникает эта проблема, проанализируем неочевидные системные факторы и настроим серверное окружение так, чтобы выжать максимум из нового оборудования.
Это первая и самая распространенная причина низкой скорости работы «1С» на новом серверном оборудовании. Современные многоядерные процессоры по умолчанию настроены на жесткое энергосбережение.
Выясним физику процесса: построение отчета (особенно компиляция тяжелого запроса построителем и расчет итогов) — это преимущественно однопоточная задача. Когда один рабочий процесс rphost.exe начинает грузить одно ядро процессора на 100%, операционная система и BIOS видят, что остальные 30–40 ядер простаивают. Для СУБД и ОС общая нагрузка на процессор выглядит незначительной (всего 2-3%), поэтому процессор не переходит в турбо-режим и продолжает работать на минимальной базовой частоте (например, 1.2 ГГц вместо возможных 3.5 ГГц).
Для решения этой проблемы выполним следующие шаги:
C-States, Intel SpeedStep (или AMD Cool'n'Quiet), а режим управления питанием самого процессора (CPU Power Management) переведем в положение Maximum Performance / OS Controlled.Когда сервер «1С:Предприятия» и MS SQL Server установлены на одном физическом компьютере, передача данных между ними по сетевому протоколу TCP/IP (даже через локальный петлевой интерфейс loopback) создает огромные и совершенно ненужные накладные расходы.
Использование протокола Shared Memory (Общая память) позволяет процессам обмениваться данными напрямую через оперативную память сервера, минуя сетевой стек ОС. Однако просто включить этот протокол в диспетчере конфигурации SQL Server недостаточно.
Проанализируем частую проблему безопасности: если служба сервера «1С» запущена от имени одного пользователя (например, локального USR1CV8), а служба MS SQL Server — от имени другого (например, NT Service\MSSQLSERVER), операционная система Windows из соображений безопасности заблокирует создание общих именованных каналов в оперативной памяти. В результате система молча откатится на медленный протокол TCP/IP.
Чтобы гарантировать работу Shared Memory, выполним настройку локальной политики безопасности Windows:
secpol.msc).USR1CV8), и учетную запись службы MS SQL Server.ПостроительОтчета под капотом генерирует сложные, многоуровневые запросы с обилием временных таблиц. Все временные таблицы (имеющие префикс #tt) физически создаются, записываются и обрабатываются в системной базе данных TempDB СУБД SQL Server.
Если на новом сервере база TempDB оставлена с настройками по умолчанию (имеет всего один файл данных), то при одновременной работе пользователей и формировании тяжелых отчетов возникает критическое узкое горлышко — конкуренция за системные страницы распределения памяти (возникают ожидания типов PAGELATCH_UP и PAGELATCH_EX). Мощнейший сервер начинает простаивать в очередях на запись во временную таблицу.
Настроим TempDB правильно:
TempDB на несколько файлов данных одинакового размера. Количество файлов должно быть равно количеству физических ядер одного процессора (но не более 8 файлов на один экземпляр СУБД).TempDB и зададим одинаковый шаг авторасширения (например, 256 МБ или 512 МБ), чтобы файлы увеличивались синхронно.TempDB (как файлы данных .mdf/.ndf, так и файл журнала транзакций .ldf) на самый производительный дисковый массив — высокоскоростные твердотельные накопители SSD NVMe.По умолчанию MS SQL Server настроен на максимальное распараллеливание сложных запросов. Получив тяжелый запрос от построителя отчетов, оптимизатор СУБД решает задействовать все доступные ядра процессора для его выполнения.
Однако накладные расходы на разделение задачи между ядрами, координацию потоков и последующую сборку результирующей выборки на многоядерных процессорах часто превышают время самого выполнения запроса. В мониторе производительности это проявляется огромными ожиданиями типа CXPACKET или CXCONSUMER.
Рекомендуется жестко ограничить параллелизм для баз данных, работающих под управлением «1С:Предприятия»:
1. Это полностью исключит распараллеливание запросов и избавит систему от взаимных блокировок потоков. Для большинства баз «1С» на платформе 8.2 и 8.3 это наиболее стабильная рекомендация.MAXDOP в значение, равное половине ядер одного физического процессора (но не более 4). При этом обязательно изменим параметр Cost Threshold for Parallelism (порог стоимости для параллелизма) со стандартного значения 5 на 50 или 80. Это предотвратит попытки СУБД распараллеливать некрупные и средние запросы.Когда вы переносите базу данных на новый сервер методом резервного копирования и восстановления (Backup/Restore), кэш планов запросов СУБД полностью очищается. При первом обращении к отчету SQL Server вынужден строить план выполнения с нуля.
Если при этом статистика распределения данных устарела, оптимизатор может построить крайне неэффективный план выполнения (например, выберет сканирование всей таблицы Index Scan вместо точечного поиска Index Seek) или вовсе «зависнет» на этапе компиляции плана (что и вызывает паузы в 10–11 секунд при первом запуске отчета или просмотре через Shift+F9 в отладчике).
Сразу после разворачивания базы на новом сервере выполним принудительное обновление статистики с полным сканированием таблиц. Для этого в среде SQL Server Management Studio (SSMS) выполним следующий скрипт:
USE [ИмяВашейБазыДанных];
GO
EXEC sp_updatestats;
GO
Для критически важных таблиц (например, таблиц итогов регистров накопления и бухгалтерии) рекомендуется выполнить ручное обновление с максимальной точностью:
UPDATE STATISTICS [ИмяТаблицыРегистра] WITH FULLSCAN, COLUMNS;
Если ваша конфигурация использует управляемые блокировки, критически важно убедиться, что для базы данных включен режим изоляции транзакций через версии строк — Read Committed Snapshot Isolation (RCSI).
В современных версиях платформы «1С» (начиная с 8.3.3) этот режим включается автоматически при создании базы, но при ручном переносе или использовании старых платформ (таких как 8.2.16) этот параметр может оказаться выключенным (значение FALSE).
Проверим текущее состояние и принудительно активируем RCSI. Для этого выполним следующий SQL-запрос:
-- Проверяем текущий статус режима RCSI
SELECT name, is_read_committed_snapshot_on FROM sys.databases WHERE name = 'ИмяВашейБазыДанных';
-- Если значение 'is_read_committed_snapshot_on' равно 0, включаем его
ALTER DATABASE [ИмяВашейБазыДанных] SET ALLOW_SNAPSHOT_ISOLATION ON;
ALTER DATABASE [ИмяВашейБазыДанных] SET READ_COMMITTED_SNAPSHOT ON WITH ROLLBACK IMMEDIATE;
Применение этого режима позволит читающим транзакциям (построению отчетов) не блокировать записывающие транзакции и наоборот. Отчеты будут строиться по мгновенным снимкам данных из TempDB, что полностью устранит взаимные блокировки при формировании тяжелых ведомостей.
На новых серверах системные администраторы часто устанавливают самые свежие пакеты безопасности и антивирусы с максимальным уровнем сканирования. При этом антивирус начинает сканировать каждый временный файл, создаваемый процессами «1С» и SQL Server, «на лету» блокируя доступ к ним.
Настроим правила исключения в антивирусном ПО на сервере приложений «1С» и сервере СУБД. Исключим из сканирования:
rphost.exe, rmngr.exe, ragent.exe.sqlservr.exe..mdf, .ldf, .ndf).TempDB.%ProgramFiles%\1cv8\srvinfo).Последовательное выполнение указанных шагов позволит устранить скрытые задержки в работе оборудования, оптимизировать взаимодействие программных компонентов и ускорить формирование отчетов в несколько раз, обеспечив стабильную и плавную работу пользователей.