Переход со старой конфигурации «1С:Управление торговлей 10.3» (работающей преимущественно в режиме толстого клиента) на современную «1С:Управление торговлей 11» (построенную на управляемых формах и тонком клиенте) — это не просто обновление прикладного решения. Это кардинальное изменение профиля нагрузки на вашу серверную инфраструктуру. СУБД MS SQL Server, которая годами стабильно работала в связке с УТ 10.3, без правильной предварительной подготовки может начать демонстрировать критические падения производительности, постоянные блокировки транзакций и зависания пользователей при работе в УТ 11.
В этой статье мы подробно разберем по шагам, как подготовить, настроить и оптимизировать вашу СУБД MS SQL Server 2016 (и новее) для успешного и быстрого развертывания новой базы данных «1С:Управление торговлей 11».
Прежде чем перейти к конкретным кликам в консоли СУБД, давайте проанализируем ситуацию и выясним причину, почему настройки СУБД для УТ 10.3 не всегда подходят для УТ 11.
В конфигурации УТ 10.3 (толстый клиент) большая часть вычислений, формирование сложных аналитических отчетов и тяжелые алгоритмы выполнялись на локальных компьютерах пользователей. На сервер 1С и СУБД SQL отправлялись относительно «простые» точечные запросы на чтение и запись. В УТ 11 (тонкий клиент) ситуация меняется диаметрально: клиентское приложение превращается в простой терминал для отображения интерфейса, а абсолютно вся бизнес-логика (проведение документов, расчет себестоимости, распределение партий товаров, выполнение сложных запросов к динамическим регистрам сведений) переносится на сервер приложений 1С и СУБД. Нагрузка на связку «Сервер 1С + SQL» возрастает в разы.
Более того, механизмы проведения документов в УТ 11 активно используют механизм разделения итогов и массовую запись во временные таблицы СУБД. Это создает колоссальную нагрузку на системную базу данных tempdb. Если оставить настройки SQL-сервера по умолчанию, то пользователи сразу же столкнутся с сильными задержками при проведении даже небольших накладных.
Ниже представлен пошаговый комплекс настроек, которые гарантируют стабильную и быструю работу вашей новой информационной системы.
Начнем с базовых настроек параметров хранения файлов создаваемой информационной базы. Нам необходимо правильно задать начальный размер файлов данных (.mdf) и лога транзакций (.ldf), а также настроить шаг их автоматического роста (Autogrowth).
По умолчанию MS SQL Server создает файлы базы данных с очень маленьким размером и шагом автоприроста (например, увеличение на 1 МБ для файлов данных и на 10% для файлов журналов). Это критическая ошибка для высоконагруженных систем 1С. Каждый раз, когда файл заполняется, СУБД приостанавливает все транзакции пользователей, чтобы выполнить физическое расширение файла на диске. Это приводит к микрозависаниям интерфейса 1С.
Выполним правильную настройку:
База данных tempdb используется СУБД MS SQL Server для хранения временных таблиц, создаваемых платформой «1С:Предприятие 8.3» в процессе проведения документов и формирования отчетов. В УТ 11 нагрузка на эту базу возрастает многократно.
Выполним оптимизацию tempdb по рекомендациям экспертов производительности:
tempdb на несколько файлов данных (.mdf и .ndf). Количество файлов должно строго соответствовать числу физических или логических ядер процессора на вашем сервере. Однако, если у вас более 8 ядер, начните с создания 8 файлов данных. Все эти файлы должны иметь строго одинаковый начальный размер и строго одинаковый шаг авторасширения (например, начальный размер — 1024 МБ, автоприрост — 256 МБ). Это позволит SQL Server использовать алгоритм пропорционального заполнения (Proportional Fill) и параллельно писать данные во все файлы, исключая узкое горлышко дисковой подсистемы.tempdb должны обязательно располагаться на самом быстром накопителе сервера. Идеальный вариант — выделенный высокоскоростной NVMe SSD или отдельный RAID-массив из быстрых твердотельных накопителей. Наличие tempdb на медленных HDD-дисках гарантированно парализует работу УТ 11 при одновременной работе более 10 пользователей.Если сервер приложений 1С и служба MS SQL Server физически установлены на одном системном блоке (сервере), мы можем существенно ускорить их взаимодействие, минуя сетевой стек операционной системы TCP/IP. Для этого используется протокол Shared Memory (Общая память), который передает пакеты данных между процессами напрямую в ОЗУ.
Рассмотрим, как настроить данный протокол:
SQL Server Network Configuration (Сетевая конфигурация SQL Server) и выберите Protocols for MSSQLSERVER (Протоколы для вашего экземпляра службы).Shared Memory установлен в положение Enabled.SQL Native Client Configuration (Конфигурация SQL Native Client) -> Client Protocols (Клиентские протоколы).Shared Memory в самый верх списка (присвойте ему приоритет 1). Нажмите кнопку «Применить».Давайте проверим, используют ли процессы 1С этот протокол при работе с СУБД. Для этого выполним в среде SQL Server Management Studio (SSMS) следующий системный запрос:
SELECT program_name, net_transport
FROM sys.dm_exec_sessions AS ses
LEFT JOIN sys.dm_exec_connections AS cons ON ses.session_id = cons.session_id
WHERE ses.program_name LIKE '1C%'
Проанализируем результат запроса: если в колонке net_transport напротив сессий, запущенных от имени приложения 1С, вы увидите значение Shared Memory, значит, настройка выполнена успешно. Это позволит повысить общую скорость обмена данными между сервером 1С и СУБД в среднем на 10–15%.
По умолчанию MS SQL Server настроен так, что он стремится занять всю доступную физическую оперативную память на сервере. В условиях, когда на одной физической машине запущен СУБД SQL, сервер 1С (процессы rphost), а также развернута виртуальная машина с терминальным сервером для пользователей, такое поведение недопустимо.
Если SQL Server заберет под свой кэш всю свободную память, процессам сервера 1С не хватит ОЗУ для обработки тяжелых запросов. Это приведет к их аварийному завершению (падению рабочих процессов), либо операционная система начнет жестко сбрасывать данные в файл подкачки на диск, что мгновенно снизит скорость работы системы до нуля.
Посчитаем и ограничим аппетиты SQL Server по следующей формуле:
Максимальная память SQL (Max Server Memory) = [Общий объем ОЗУ сервера] - [Память под нужды ОС (минимум 4 ГБ)] - [Память, выделенная виртуальным машинам] - [Память под нужды процессов rphost (в среднем по 1,5–2 ГБ на один рабочий процесс)]
Перейдите в свойства сервера SQL в консоли SSMS, откройте вкладку Memory и в поле Maximum server memory (in MB) введите рассчитанное значение. Это гарантирует стабильную работу всех компонентов системы без взаимного вытеснения из оперативной памяти.
По умолчанию операционная система Windows при создании новых файлов или при расширении существующих (например, при автоприросте файла mdf вашей базы 1С или файлов базы tempdb) заполняет выделяемые кластеры нулями. В процессе заполнения нулями диск занят операциями ввода-вывода на 100%, а база данных блокируется.
Чтобы избежать этой проблемы, мы можем включить механизм мгновенной инициализации файлов. В этом случае Windows будет мгновенно выделять дисковое пространство без предварительного заполнения секторов нулями.
Настроим это системное право:
Win + R, введите команду secpol.msc и нажмите Enter для запуска локальной политики безопасности.Локальные политики -> Назначение прав пользователя.NT Service\MSSQLSERVER).Параметр **Max Degree of Parallelism (MAXDOP)** отвечает за то, сколько ядер процессора SQL Server может задействовать для выполнения одного тяжелого запроса. По умолчанию значение равно 0, что означает использование всех доступных ядер процессора.
Для систем, работающих под управлением «1С:Предприятие 8.3», это значение является губительным. Если один пользователь запустит тяжелый и неоптимальный аналитический отчет, SQL-сервер выделит под этот запрос все ядра процессора, загрузив его на 100%. В этот момент остальные 50 пользователей, которые пытаются выписать простые накладные или провести документы, зависнут и будут ждать окончания выполнения отчета.
Для баз данных 1С фирма «1С» рекомендует следующие настройки параллелизма:
Оптимизатор запросов SQL Server строит планы выполнения запросов на основе статистических данных о распределении данных в таблицах. Если статистика устаревает, СУБД начинает строить неоптимальные планы, что приводит к резкому замедлению работы 1С.
По умолчанию в настройках баз данных включено автоматическое обновление статистики (Auto Update Statistics = True). Однако, если параметр асинхронного обновления отключен, то при обнаружении устаревшей статистики первый же пользовательский запрос, обратившийся к этой таблице, будет «подвешен» СУБД. Пользователь будет сидеть перед зависшим экраном 1С до тех пор, пока SQL Server не пересчитает статистику по всей таблице.
Чтобы избежать этого, откройте свойства вашей новой базы данных в SSMS, перейдите в раздел Options (Параметры) и настройте следующие флаги:
True.True.В асинхронном режиме SQL Server выполнит текущий запрос пользователя мгновенно по старому плану, а обновление статистики запустит параллельно в фоновом потоке, не блокируя работу пользователей в интерфейсе 1С.
Поскольку вы разворачиваете новую базу данных с нуля, обратите внимание на разметку ваших дисковых разделов, на которых будут храниться файлы данных (MDF) и файлов логов (LDF) вашей СУБД.
При стандартном форматировании дисков в Windows размер кластера файловой системы NTFS по умолчанию составляет 4 КБ. Однако внутренняя структура страниц данных MS SQL Server оперирует страницами размером 8 КБ, которые логически объединяются в экстенты по 8 страниц (что в сумме составляет ровно 64 КБ).
Рекомендуется форматировать дисковые накопители, выделенные под базы данных SQL Server, с размером кластера (размером единицы распределения) строго равным 64 КБ. Это позволяет существенно снизить нагрузку на дисковую подсистему при интенсивных операциях ввода-вывода (I/O) и выжать максимум производительности из ваших твердотельных SSD-накопителей.
Мы подробно рассмотрели ключевые аспекты настройки связки MS SQL Server 2016 и «1С:Управление торговлей 11». Давайте зафиксируем краткий чек-лист, который поможет вам проверить готовность вашей СУБД перед запуском пользователей в новую базу:
tempdb разбита на файлы по числу процессорных ядер, имеет одинаковые размеры и расположена на быстром SSD.rphost сервера 1С.Соблюдение этих простых, но критически важных правил позволит вам запустить новую систему «1С:Управление торговлей 11» с максимальной производительностью, обеспечив комфортную работу пользователей без зависаний, лагов и технологических сбоев СУБД.