← На главную

При сборке серверов для 1С многие администраторы сталкиваются с парадоксальной ситуацией. Приобретая современные, дорогие и высокоскоростные NVMe SSD (например, Kingston KC3000 или Samsung 980 PRO), которые в синтетических тестах вроде CrystalDiskMark показывают феноменальные 7000 МБ/с, в реальных задачах 1С или специализированных тестах (например, тест Гилёва) скорость оказывается удручающе низкой. При этом более дешевые или старые модели дисков могут показывать результаты в разы лучше. Давайте разберемся в причинах этого явления, проанализируем техническую подоплеку и рассмотрим способы решения.

Суть проблемы: синтетика против реальности 1С

Рассмотрим типичный сценарий. Мы устанавливаем высокопроизводительный диск Kingston KC3000 или Samsung 980 PRO. Запускаем стандартные бенчмарки — видим отличные показатели линейного чтения и записи. Однако при запуске теста производительности Гилёва (TPC 1C) мы наблюдаем следующую картину:

1. Скорость записи в тесте падает до 100-200 МБ/с (вместо ожидаемых тысяч).
2. В диспетчере задач загрузка SSD отображается на уровне 100%, при этом процессор простаивает (загрузка 15-20%).
3. Время отклика диска становится огромным.
4. При клонировании системы на более простой или старый SSD (например, WD SN740) скорость в тесте 1С возрастает в несколько раз, а диск перестает быть "узким горлышком".

Мы видим, что проблема не в процессоре, не в оперативной памяти и не в настройках BIOS по умолчанию. Проблема кроется в том, как именно современные потребительские контроллеры SSD и операционная система обрабатывают специфические команды записи, характерные для баз данных.

Техническая причина: команда FUA и отсутствие PLP

Чтобы понять, почему "быстрый" диск работает медленно в 1С и SQL, нам нужно углубиться в механизм записи данных. Системы управления базами данных (MSSQL, PostgreSQL), используемые 1С, критически относятся к сохранности данных. Чтобы гарантировать, что транзакция не пропадет при внезапном отключении питания, СУБД отправляет команду записи с флагом FUA (Force Unit Access).

Этот флаг говорит диску: "Не держи эти данные в своем быстром кэше (DRAM), запиши их сразу в постоянную память, чтобы они точно сохранились".

Здесь и кроется фундаментальное различие между серверными (Enterprise) и потребительскими (Consumer) SSD:

1. Серверные SSD оснащены защитой от потери питания (PLP — Power Loss Protection, конденсаторы на плате). Получив команду FUA, такой диск пишет данные в свой быстрый кэш, но система знает, что при сбое питания конденсаторы дадут достаточно энергии, чтобы сбросить кэш в память. Поэтому диск рапортует системе "Записано!" практически мгновенно, не теряя скорости.
2. Потребительские SSD (даже топовые PRO версии) обычно не имеют PLP. Получив команду FUA, контроллер диска обязан честно сбросить данные из быстрого кэша в медленную NAND-флеш память перед тем, как подтвердить запись ОС. Это вызывает резкий рост задержек и падение скорости до физической скорости прямой записи во флеш-память, минуя кэш.

Тест Гилёва, как и реальная работа 1С, генерирует множество мелких транзакций. На потребительских дисках это приводит к тому, что очередь записи забивается ожиданием физического сброса данных, и производительность падает.

Роль драйверов NVMe

Еще один важный фактор — драйверы. Ранее производители (например, Samsung для серии 970) выпускали собственные NVMe-драйверы. Они могли оптимизировать обработку команд, иногда игнорируя строгие требования FUA в угоду производительности.

Однако, начиная с моделей 980 PRO, Samsung и другие вендоры отказались от своих драйверов в пользу стандартного драйвера Microsoft NVMe, встроенного в Windows. Стандартный драйвер Microsoft очень строго соблюдает протокол: если пришла команда FUA, он требует честной записи на диск. Именно поэтому на новых ОС (Windows Server 2022, 2025) и новых дисках мы видим просадку производительности, которой не было на старых связках.

Решение 1: Настройка кэширования в Windows

Самым действенным программным способом решения проблемы на потребительских дисках является изменение политики кэширования. Рассмотрим, как это сделать:

1. Откройте Диспетчер устройств.
2. Найдите ваш NVMe накопитель в разделе Дисковые устройства.
3. Откройте свойства диска и перейдите на вкладку Политика.
4. Установите галочку напротив пункта "Отключить очистку буфера кэша записей Windows для этого устройства" (Turn off Windows write-cache buffer flushing).

После применения этой настройки операционная система перестанет посылать команды принудительного сброса кэша (flush) на диск после каждой транзакции. Результаты тестов (и теста Гилёва в частности) сразу возвращаются к высоким значениям: скорость записи возрастает, загрузка диска падает до 5-10%.

ВАЖНОЕ ПРЕДУПРЕЖДЕНИЕ: Включая эту опцию, вы берете на себя серьезный риск. Если в момент активной записи произойдет сбой питания или зависание системы (BSOD), данные, находящиеся в кэше диска, не успеют записаться в постоянную память. Это с высокой долей вероятности приведет к разрушению базы данных (corruption). Использовать этот метод на продуктивном сервере можно ТОЛЬКО при наличии надежного ИБП (UPS), который корректно завершает работу сервера при отключении электричества, и стабильной аппаратной платформы.

Решение 2: Подбор драйверов

В некоторых случаях, особенно на старых версиях ОС, помогает манипуляция с драйверами. Пользователи отмечают следующее поведение:

• Если удается найти и установить старые драйверы от Samsung (хотя они официально не поддерживают новые модели), устройство может определиться иначе (например, как "NVMe Samsung SSD 980 SCSI Disk Device"), и производительность может вырасти даже без отключения очистки буфера.
• Использование модифицированных драйверов от сообщества (так называемые драйверы от Fernando) позволяет интегрировать поддержку старых алгоритмов работы на новые системы.

Однако на современных ОС (Windows Server 2025, Windows 11 24H2) этот метод работает всё хуже из-за изменений в архитектуре подсистемы хранения данных Microsoft.

Особенности разных контроллеров (Samsung vs WD vs Phison)

В ходе практических тестов выяснилось интересное различие между брендами:

• Samsung (980/990 PRO): Сильно страдают от проблемы FUA на стандартных драйверах. Требуют отключения очистки буфера для высокой скорости в 1С.
• Kingston KC3000 (контроллер Phison E18): Также демонстрирует падение скорости при строгом соблюдении FUA.
• WD (например, модель SN740): В ряде тестов показал себя лучше "из коробки". Это связано с тем, что микрокод (прошивка) контроллеров WD часто имеет алгоритмы кэширования, более близкие к корпоративному сегменту, и лучше справляется с очередью смешанных команд без глубоких просадок, даже если пиковая линейная скорость у него ниже, чем у конкурентов.

Итоги и рекомендации

Подводя итог, можно сказать, что использование топовых потребительских SSD в серверах 1С — это компромисс.

1. Если вы используете диски типа Samsung 980/990 PRO или Kingston KC3000 под базы данных, вы почти гарантированно столкнетесь с низкой скоростью записи мелких блоков в однопоточном режиме из-за команд FUA.
2. Для решения проблемы необходимо поставить галочку "Отключить очистку буфера кэша записей" в свойствах диска. Это вернет высокую производительность (прирост может быть 2-5 кратным).
3. Безопасность данных: Обязательно обеспечьте сервер бесперебойным питанием. Без ИБП отключение очистки буфера на SSD без PLP — прямой путь к потере базы.
4. Правильный выбор: Для критически важных серверов 1С настоятельно рекомендуется использовать Enterprise (серверные) SSD (например, серии Samsung PM9A3, Intel/Solidigm D7 и другие). У них есть аппаратная защита PLP, они игнорируют задержки FUA на аппаратном уровне и обеспечивают высокую скорость и надежность без опасных настроек в Windows.