При проектировании сервера под управлением MS SQL Server для работы с базами 1С:Предприятие часто возникает вопрос: насколько критична скорость системного диска (тома C:) и может ли обычный массив из SATA-дисков стать узким местом, если основные базы данных перенесены на быстрый накопитель NVMe/PCIe SSD. Разберем подробно, какие процессы могут нагружать системный диск, как правильно разнести компоненты СУБД по дисковым массивам и как диагностировать узкие места в подсистеме ввода-вывода.
Если файлы рабочих баз данных (.mdf) и журналов транзакций (.ldf) размещены на выделенном быстром SSD, системный диск не должен испытывать прямой рабочей нагрузки от запросов пользователей. Однако при неверной конфигурации операционная система и сопутствующие службы могут создавать на диск C: существенную скрытую нагрузку. Проанализируем ключевые источники такой нагрузки:
pagefile.sys): если в настройках экземпляра MS SQL Server не ограничен параметр Max Server Memory (максимальный объем памяти сервера), СУБД способна занять практически весь объем RAM. В моменты нехватки памяти Windows начинает принудительно сбрасывать данные других процессов в файл подкачки на системном диске, вызывая лавинообразные задержки всей системы.%TEMP% / %TMP%): рабочие процессы сервера 1С (rphost) и фоновые задания при формировании тяжелых отчетов или обработке больших массивов данных могут активно писать промежуточные файлы в системную папку Temp.srvinfo): журналы регистрации (особенно в формате SQLite или текстовом .lgf), кэш сеансов и данные полнотекстового поиска по умолчанию хранятся в каталоге %PROGRAMDATA%\1C\1CE\ на диске C:. Это порождает непрерывный поток случайных операций записи.master, model, msdb, а также журнал ошибок ERRORLOG по умолчанию находятся на системном диске. Раздувание msdb из-за истории резервного копирования или частая запись событий в журнал создают дополнительную нагрузку.База данных TempDB является общим ресурсом для всех баз экземпляра MS SQL. В среде 1С временные таблицы (#tt...), сортировки, хеш-соединения и версионирование строк (при включенном механизме RCSI) интенсивно обращаются именно к TempDB. Размещение TempDB на медленном диске гарантированно снижает общую отзывчивость системы.
Рассмотрим вопрос надежности накопителя с TempDB. Поскольку TempDB пересоздается заново при каждом перезапуске службы SQL Server, выход из строя отдельного SSD под TempDB не приводит к потере данных пользовательских баз. В случае аварии достаточно остановить службу, переконфигурировать пути к файлам TempDB через команду запуска или реестр и запустить экземпляр заново.
Чтобы выяснить, насколько активно 1С использует TempDB и имеются ли задержки на дисках, выполним диагностику через динамические административные представления (DMV). Посмотрим на статистику задержек ввода-вывода с помощью следующего скрипта:
SELECT
DB_NAME(vfs.database_id) AS [DatabaseName],
mf.name AS [LogicalFileName],
mf.physical_name AS [PhysicalPath],
vfs.num_of_reads AS [ReadsCount],
vfs.num_of_writes AS [WritesCount],
vfs.io_stall_read_ms / NULLIF(vfs.num_of_reads, 0) AS [AvgReadLatencyMs],
vfs.io_stall_write_ms / NULLIF(vfs.num_of_writes, 0) AS [AvgWriteLatencyMs],
vfs.size_on_disk_bytes / 1024 / 1024 AS [SizeMB]
FROM sys.dm_io_virtual_file_stats(NULL, NULL) AS vfs
JOIN sys.master_files AS mf
ON vfs.database_id = mf.database_id
AND vfs.file_id = mf.file_id
ORDER BY [AvgReadLatencyMs] DESC;
Проанализируем результаты выполнения: если показатели AvgReadLatencyMs или AvgWriteLatencyMs для файлов tempdb превышают 10–15 мс, дисковая подсистема является узким местом и требует оптимизации.
Для выяснения того, чем именно занято пространство внутри TempDB, выполним запрос к sys.dm_db_file_space_usage:
SELECT
SUM(user_object_reserved_page_count) * 8 / 1024 AS [UserObjectsMB],
SUM(internal_object_reserved_page_count) * 8 / 1024 AS [InternalObjectsMB],
SUM(version_store_reserved_page_count) * 8 / 1024 AS [VersionStoreMB],
SUM(unallocated_extent_page_count) * 8 / 1024 AS [FreeSpaceMB]
FROM tempdb.sys.dm_db_file_space_usage;
Разберем наиболее эффективные схемы разделения дисков в зависимости от бюджета и количества доступных накопителей:
.mdf), журналы транзакций (.ldf) и TempDB..mdf) и журналы транзакций (.ldf).TempDB..mdf)..ldf) и TempDB (разделение последовательной записи логов и случайного доступа к данным).Разберем ключевые правила, позволяющие исключить деградацию производительности:
.ldf) и быстро изнашиваются под нагрузкой 1С. Для рабочих серверов следует выбирать только накопители корпоративного класса.tempdb, равное количеству физических ядер процессора (но не более 8 на начальном этапе), с одинаковым размером и фиксированным шагом авторасширения в мегабайтах (например, 512 MB). Это устраняет очереди блокировок страниц PFS и SGAM.Perform volume maintenance tasks (Выполнение задач по обслуживанию томов) в локальных политиках безопасности. Это исключит задержки обнуления файлов при расширении баз данных и TempDB.C: приведет к полной остановке операционной системы.