← На главную

Казалось бы, классический сценарий: старый сервер с медленными жесткими дисками заменяется на современное «железо», оснащенное быстрыми твердотельными накопителями (SSD). Руководство выделяет бюджет, системные администраторы монтируют сервер, программисты переносят базы данных, запускается тестовое перепроведение документов — и... ничего не меняется. Время проведения пакета документов остается прежним, а пользователи не замечают никакого прироста скорости.

С такой ситуацией столкнулся автор темы на форуме. Новый сервер, укомплектованный SSD-накопителями под операционную систему, файлы базы данных и логи транзакций, показал абсолютно идентичное время проведения тестового пакета документов УПП (17 минут на 260 документов). Выясним причину этой проблемы, проанализируем узкие места архитектуры 1С + MS SQL и разберем по шагам, как заставить новое оборудование работать на полную мощность.

Главный виновник — энергосберегающие технологии процессора (CPU Throttling)

Рассмотрим, почему замена дисков на SSD сама по себе часто не дает мгновенного прироста при проведении документов. Проведение документа в 1С — это преимущественно однопоточный процесс. В каждый конкретный момент времени система выполняет последовательные математические расчеты и логические проверки на одном ядре процессора. Дисковая активность при этом носит импульсный характер: короткий запрос к СУБД, ожидание расчета на CPU, запись результатов транзакции.

Современные процессоры (как Intel Xeon, так и AMD EPYC) по умолчанию настроены на жесткое энергосбережение. Когда нагрузка на сервер распределена неравномерно или идет в один поток (как при проведении документов одним пользователем), процессор считает, что система простаивает, и снижает тактовую частоту ядер, а неиспользуемые ядра переводит в так называемые режимы глубокого сна (C-States). Из-за микросекундных задержек на «просыпание» ядер и динамическое изменение частоты производительность 1С падает в разы.

Посмотрим на практический результат автора темы: простое изменение схемы электропитания в операционной системе Windows Server на «Высокую производительность» (High Performance) мгновенно сократило время проведения тестового пакета документов с 17 до 6 минут! Это доказывает, что дисковая подсистема не была главным узким местом в данном сценарии.

Чтобы полностью исключить влияние энергосбережения на аппаратном уровне, настроим параметры BIOS/UEFI сервера. Разберем основные параметры, которые необходимо изменить:

1. Power Profile / Power Technology — установим значение в режим Maximum Performance (Максимальная производительность). Это отключит попытки материнской платы сэкономить электричество за счет производительности СУБД.
2. C-States / C1E / Enhanced Halt State — эти функции переводят ядра процессора в спящий режим при кратковременных простоях. Для высоконагруженных серверов 1С их необходимо полностью отключить (Disable).
3. Intel SpeedStep / AMD Cool'n'Quiet — технологии динамического изменения частоты процессора. Отключаем их, чтобы зафиксировать частоту процессора на максимальном базовом уровне.
4. Intel Turbo Boost / AMD Core Performance Boost — эти технологии, напротив, необходимо обязательно включить (Enable). Они позволяют временно разгонять активное ядро процессора выше базовой частоты при однопоточной нагрузке, что критически важно для проведения документов в 1С.

Специфика работы дисковой подсистемы SSD под управлением MS SQL Server

Твердотельные накопители работают с данными совершенно иначе, чем традиционные HDD. Чтобы СУБД могла эффективно утилизировать скорость SSD, нам необходимо правильно подготовить дисковые разделы. Стандартное форматирование диска средствами Windows по умолчанию использует размер кластера (размер блока) 4 КБ. Однако архитектура MS SQL Server оперирует страницами данных размером 8 КБ, которые объединяются в логические блоки — экстенты по 8 страниц (итого 64 КБ).

Проанализируем последствия несовпадения размеров блоков. Если диск под базы данных форматирован с кластером 4 КБ, то при записи одного экстента размером 64 КБ операционной системе приходится выполнять 16 отдельных операций ввода-вывода вместо одной. Это приводит к избыточной нагрузке на контроллер SSD и ускоряет его износ.

Правильное решение — принудительное форматирование разделов под базы данных (файлы .mdf, .ldf и временную базу tempdb) с размером кластера 64 КБ. Выполнить проверку текущего размера кластера на диске можно с помощью командной строки Windows, запущенной от имени администратора:

fsutil fsinfo ntfsinfo D:

Обратим внимание на строку «Байтов на кластер» (Bytes Per Cluster). Если там указано значение 4096, диск необходимо переформатировать перед размещением на нем баз данных, указав размер блока распределения 64 КБ.

Настройка протокола взаимодействия Shared Memory (Общая память)

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

По умолчанию компоненты 1С общаются с SQL-сервером через сетевой протокол TCP/IP. Даже при обращении к локальному адресу localhost или 127.0.0.1 пакеты данных проходят через весь сетевой стек операционной системы, что создает дополнительную нагрузку на процессор и увеличивает время отклика (latency). Чтобы устранить эти накладные расходы, настроим протокол Shared Memory, который позволяет процессам обмениваться данными напрямую через оперативную память сервера.

Разберем процесс настройки по шагам:

1. Откроем диспетчер конфигурации SQL Server (SQL Server Configuration Manager).
2. Перейдем в раздел SQL Server Network Configuration (Сетевая конфигурация SQL Server) -> Protocols for MSSQLSERVER (Протоколы для MSSQLSERVER).
3. Убедимся, что протокол Shared Memory находится в состоянии Enabled (Включен).
4. В настройках подключения к базе данных в кластере 1С в качестве имени сервера СУБД укажем локальное имя компьютера, точку . или значение (local). Это заставит платформу использовать быструю общую память вместо сетевых сокетов.

Оптимизация параметров автоувеличения и инициализации файлов

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

1. Быстрая инициализация файлов (Instant File Initialization). По умолчанию при создании или увеличении размера файлов базы данных операционная система физически заполняет выделяемое пространство нулями. В этот момент запись реальных данных приостанавливается, что пользователи 1С ощущают как «зависание» системы при проведении крупных документов. Мы можем разрешить SQL Server мгновенно выделять место без зануления.

Для этого необходимо предоставить учетной записи, от имени которой запускается служба СУБД (например, NT Service\MSSQLSERVER), специальное право в операционной системе Windows:

1. Откроем локальную политику безопасности (выполнить secpol.msc).
2. Перейдем по пути: Локальные политики -> Назначение прав пользователя.
3. Найдем политику «Выполнение задач по обслуживанию томов» (Perform volume maintenance tasks).
4. Добавим в список пользователей учетную запись службы SQL Server и перезапустим службу СУБД.

2. Настройка параметров автоувеличения файлов (Autogrowth). По умолчанию в базах данных часто установлены параметры роста файлов «по 1 МБ» или «на 10%». При интенсивной работе пользователей файлы базы данных будут непрерывно прирастать мелкими порциями, вызывая сильную фрагментацию дискового пространства даже на SSD. Зададим фиксированный шаг увеличения файлов данных в диапазоне от 256 до 512 МБ, а для файлов лога транзакций — от 64 до 128 МБ.

Оптимизация временной базы данных TempDB

База данных tempdb является главным рабочим пространством для платформы 1С:Предприятие. Именно туда записываются все временные таблицы, которые создаются при расчете и проведении документов, формировании сложных отчетов и выполнении запросов.

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

1. Разделение на несколько файлов данных. Создадим несколько файлов данных базы tempdb одинакового размера. Оптимальное количество файлов рассчитывается как 1 файл на каждое физическое ядро процессора, но не более 8 файлов. Это позволит СУБД параллельно записывать временные таблицы, устраняя узкое место на уровне системных страниц распределения дискового пространства.
2. Размещение на быстром SSD. Если архитектура сервера позволяет использовать несколько накопителей, файлы tempdb обязательно должны располагаться на самом быстром SSD (предпочтительно NVMe), отдельно от файлов резервных копий.

Разумное распределение оперативной памяти между СУБД и сервером 1С

В сообщении №5 участник обсуждения абсолютно верно заметил, что MS SQL Server стремится кэшировать все прочитанные таблицы в оперативной памяти (в так называемом буферном пуле). Если объем ОЗУ на сервере достаточен, SQL Server поднимет всю базу данных 1С в память и будет работать с ней там, обращаясь к SSD только для записи транзакций.

Однако, если не ограничить максимальные аппетиты СУБД, SQL Server заберет себе всю доступную оперативную память сервера. Это приведет к тому, что рабочим процессам сервера 1С (rphost) и самой операционной системе перестанет хватать физической памяти, начнется активное использование файла подкачки на диске (swapping), и общая производительность сервера резко упадет.

Разберем формулу правильного расчета лимита памяти для SQL Server:

Max Server Memory = Общий объем ОЗУ сервера - 4 ГБ (под нужды ОС) - (Количество рабочих процессов rphost * 1.5 ГБ)

Например, если на сервере установлено 64 ГБ оперативной памяти и запущено 4 рабочих процесса 1С, то для MS SQL Server рекомендуется выделить максимум 54 ГБ:

64 ГБ - 4 ГБ - (4 * 1.5 ГБ) = 54 ГБ

Настроить этот параметр можно в среде SQL Server Management Studio (SSMS). Нажмем правой кнопкой мыши на корень сервера, выберем пункт «Свойства» (Properties), перейдем в раздел «Память» (Memory) и укажем рассчитанное значение в поле «Максимальный размер памяти сервера» (Maximum server memory) в мегабайтах.

Таким образом, подводя итог нашего анализа, мы видим, что покупка SSD-накопителей — это лишь фундамент производительности. Чтобы получить реальное ускорение работы 1С, необходимо в обязательном порядке отключить аппаратные функции энергосбережения процессора, перевести операционную систему в режим высокой производительности, корректно разметить диски под СУБД с размером кластера 64 КБ, задействовать протокол Shared Memory и жестко разграничить ресурсы оперативной памяти между сервером 1С и СУБД.