Рассмотрим классическую, но очень специфическую задачу для системного администратора 1С: сборку и настройку терминального сервера для одновременной работы 10 пользователей с большим пулом файловых баз (до 120 баз всего, из которых активно запущены 40–50 штук). Главная цель такой сборки — получить максимальное быстродействие интерфейса и проведения документов, преодолев планку в 90–100 баллов в известном тесте производительности Гилёва.
В этой статье мы подробно разберем физику процессов, происходящих при работе файловой СУБД 1С, выясним причины неэффективности некоторых популярных дисковых конфигураций, проанализируем выбор комплектующих и предложим оптимальные архитектурные решения.
Часто при попытке оптимизировать файловую 1С администраторы совершают стандартную ошибку: они пытаются нарастить линейную скорость чтения и записи дисковой подсистемы. В ход идет объединение быстрых NVMe-накопителей в массив RAID 0 (получая скорость свыше 6000 МБ/с) или даже создание RAM-диска в оперативной памяти (со скоростью обмена более 12000 МБ/с). Однако тест производительности Гилёва упорно показывает прежний результат — около 68–72 баллов. Выясним, почему это происходит.
Тест Гилёва работает в один поток. Он симулирует последовательное проведение документов и запись транзакций в базу данных. В этот момент глубина очереди запросов к накопителю равна единице (Queue Depth = 1). Специфика файловой базы 1С заключается в том, что СУБД блокирует файл таблицы, записывает порцию данных, проверяет целостность и только после этого переходит к следующей операции. Пропускной способности обычного качественного SSD NVMe в несколько сотен мегабайт в секунду здесь более чем достаточно.
Узким местом становится не пропускная способность шины передачи данных, а задержка доступа (Latency) и скорость обработки одной этой операции центральным процессором. Более того:
Поскольку файловая СУБД 1С крайне чувствительна к скорости обработки одного потока, главным критерием выбора процессора является его частота и показатель IPC (количество инструкций, выполняемых за один такт). Проанализируем варианты, обсуждавшиеся в теме, а также современное развитие линеек CPU.
Ранее популярные серверные процессоры семейства Intel Xeon часто уступали потребительским процессорам в задачах 1С из-за своей низкой базовой частоты (обычно около 3.0–3.6 ГГц). Они рассчитаны на высокую параллельную нагрузку (много ядер), но одно ядро у них работает медленнее десктопного.
Для нашей задачи идеальным решением станут высокочастотные десктопные процессоры с возможностью авторазгона (Turbo Boost / Precision Boost):
При выборе платформы для 600 или даже 120 баз 1С возникает серьезная дилемма: стоит ли использовать обычные «игровые» платформы с высокой частотой работы памяти (но без поддержки коррекции ошибок) или надежные серверные платформы с поддержкой ECC (Error-Correcting Code)?
Критический риск работы без ECC: Файловая база данных 1С (файл 1Cv8.1CD) очень уязвима. Если в оперативной памяти из-за нагрева или внешних наводок произойдет незаметная ошибка записи бита (bit flip), поврежденная транзакция будет записана прямо в файл базы данных. Пользователь может заметить это лишь спустя недели, когда база перестанет открываться, а архивные копии уже будут содержать ту же ошибку. Для компании с десятками баз потеря данных из-за отсутствия ECC — это непозволительный риск.
К счастью, сегодня выбирать между высокой частотой процессора и ECC больше не нужно:
ECC UDIMM). Вы получаете высокую частоту ядер процессора и защиту данных.W680) позволяют использовать стандартные процессоры Core i7/i9 с поддержкой оперативной памяти ECC DDR5.Для достижения максимальных результатов в тесте Гилёва (90–120 баллов) недостаточно просто установить быструю память. Огромное значение имеет латентность (Memory Latency). Настоятельно рекомендуется провести ручную настройку таймингов в BIOS материнской платы:
tRFC (Row Refresh Cycle Time) напрямую влияет на задержку обращения к ячейкам памяти. Снижение этого параметра способно поднять скорость работы 1С на 10–15%.tREFI (Refresh Interval) отвечает за интервал между циклами регенерации памяти. Его увеличение снижает простои шины памяти.Организовывать RAID 0 из потребительских NVMe накопителей (например, Samsung EVO) для баз данных категорически запрещено. Дело в том, что обычные диски используют кэширование записи в ОЗУ накопителя для демонстрации высоких скоростей в тестах. При внезапном отключении электропитания или зависании операционной системы данные из кэша SSD не успевают физически записаться на флеш-память, что моментально приводит к необратимому разрушению файлов баз 1С.
Для размещения рабочих баз 1С следует использовать исключительно накопители класса Enterprise SSD (например, серии Intel D7, Samsung PM9A3 или Micron). Они обладают встроенными конденсаторами для аппаратной защиты кэша от потери питания — PLP (Power Loss Protection).
Для оптимизации дисковой нагрузки при наличии 120 баз мы рекомендуем распределить их по нескольким физическим Enterprise NVMe дискам (например, по 30–40 баз на каждый накопитель). Это позволит распределить нагрузку ввода-вывода (IOPS) и минимизировать конфликты блокировок на уровне операционной системы.
Мы можем контролировать среднее время отклика диска на запись с помощью простого скрипта PowerShell. Регулярно запускайте его для мониторинга производительности ваших накопителей:
$DiskStats = Get-Counter -Counter "\PhysicalDisk(*)\Avg. Disk sec/Write" -SampleInterval 2 -MaxSamples 3
$DiskStats.CounterSamples | Select-Object InstanceName, CookedValue | Format-Table -AutoSize
Значение CookedValue отражает задержку записи в секундах. На качественных Enterprise-накопителях под базой 1С это значение не должно превышать 0.002–0.005 секунд (2–5 миллисекунд).
Запуск 40–50 файловых баз 1С в режиме удаленного рабочего стола (RDP) силами 10 пользователей — это колоссальный перерасход ресурсов сервера. Каждая запущенная сессия «тонкого» или «толстого» клиента 1С внутри RDP-сессии потребляет отрисовку графического интерфейса Windows, съедая от 150 до 350 МБ оперативной памяти. В результате сервер тратит гигабайты ОЗУ на поддержание визуальной оболочки операционной системы.
Мы предлагаем кардинально изменить архитектуру доступа к файловым базам:
Проанализируем преимущества такого подхода:
Таким образом, правильная комбинация современного высокочастотного процессора (с поддержкой памяти ECC UDIMM), Enterprise NVMe дисков с технологией PLP и перенос файловых баз на веб-публикацию позволяет получить невероятно быструю, стабильную и отказоустойчивую систему 1С без перехода на дорогостоящую клиент-серверную модель СУБД SQL.