Вопрос разделения файлов данных (.mdf) и журналов транзакций (.ldf) является классическим в среде администраторов баз данных. В контексте работы систем 1С:Предприятие, где интенсивность записи и чтения может быть крайне высокой, эта тема не теряет актуальности. Давайте подробно разберем, имеет ли смысл такое разделение на современном оборудовании, и какие еще шаги можно предпринять для ускорения работы сервера.
Для начала проанализируем, на чем основана рекомендация разделять файлы. Основная причина кроется в различном характере операций ввода-вывода (I/O) для данных и логов:
В эпоху господства жестких дисков (HDD) разделение этих файлов на разные физические устройства позволяло избежать «дерганья» считывающих головок между разными секторами диска. На одном диске головка должна была постоянно перемещаться от последовательной записи лога к случайному чтению данных, что драматически снижало производительность.
Рассмотрим ситуацию, когда в сервере установлены твердотельные накопители. У SSD нет движущихся головок, и скорость случайного доступа у них на порядки выше. Означает ли это, что разделять файлы больше не нужно? Не совсем. Проанализируем нюансы:
tempdb, а под основные базы оставить диски попроще.Выясним, что на самом деле чаще всего является «бутылочным горлышком» в 1С. Опыт показывает, что это не .ldf основной базы, а системная база tempdb. В 1С она используется для временных таблиц, сложных запросов с итогами и внутренних нужд сервера. Рассмотрим шаги по ее оптимизации:
tempdb.tempdb. Рекомендуется создавать количество файлов, равное числу логических ядер процессора (но обычно не более 8). Это позволяет избежать конкуренции за ресурсы внутри самой SQL-базы.tempdb достаточным для работы (например, по 1-2 ГБ на файл), чтобы сервер не тратил время на их расширение в процессе работы пользователей.Проанализируем специфику 1С. Сервер приложений 1С активно пишет данные в каталог srvinfo (где находятся сеансовые данные и журнал регистрации). Если этот каталог расположен на том же диске, что и базы SQL, они начинают конкурировать за I/O. Посмотрим на эффективное решение:
Размещение папки reg_1541 (внутри srvinfo) на отдельном быстром диске или даже RAM-диске (с настройкой резервного копирования при выключении) может значительно уменьшить «фризы» интерфейса у пользователей. Чтобы быстро разобраться в структуре папок и сопоставить их с конкретными ИБ, пригодится выявление списка баз из папки REG_XXXX. Это связано с тем, что 1С блокирует выполнение некоторых операций до момента подтверждения записи в сеансовые данные или журнал.
Давайте научимся измерять производительность. Воспользуемся системным монитором Windows (PerfMon) или попробуйте анализировать SQL сервер глазами 1С-ника для детального изучения ожиданий и запросов. В PerfMon нас интересуют следующие показатели:
.ldf) это значение должно быть менее 0.002 (2 мс). Если оно стабильно выше 0.007–0.010, ваша дисковая подсистема не справляется, и разделение критически необходимо.Если мы решили разносить файлы по разным разделам (буквам дисков), важно правильно их подготовить. Разберем шаги настройки:
Simple (Простая), то нагрузка на .ldf значительно ниже, так как он используется только для обеспечения целостности транзакций и автоматически очищается. В модели Full (Полная) лог пишет всё и растет до тех пор, пока не будет сделан бэкап лога, что создает постоянную нагрузку.Подводя итог нашему анализу, выстроим иерархию действий для оптимизации сервера 1С:
tempdb на отдельный физический массив или NVMe.srvinfo) на отдельный диск (можно использовать диск от tempdb)..mdf и .ldf по разным физическим устройствам.Важное замечание: Разделение файлов на одном и том же физическом RAID-массиве (просто создание разных логических дисков D, E, G) имеет смысл только ради настройки размера кластера. Реального прироста производительности от разделения потоков I/O в этом случае не будет, так как физические головки (в HDD) или контроллер (в SSD) останутся общими.