← На главную

При администрировании систем на базе 1С:Предприятие часто возникает классическая дилемма: синтетические тесты (например, тест Гилёва) показывают значительное преимущество файлового режима работы перед клиент-серверным (SQL). Ситуация, когда файловая база выдает 60-70 «попугаев», а SQL-сервер на том же оборудовании едва дотягивает до 25-30, может вызвать ложное желание «откатиться» на файловый вариант. Рассмотрим подробнее, почему так происходит, и проанализируем, почему для 15 пользователей это решение может стать фатальным.

Разберем природу теста Гилёва и причину лидерства файловой базы

Для начала выясним причину такого разрыва в показателях. Тест Гилёва в его базовом варианте является однопоточным. Он имитирует работу одного пользователя, выполняющего последовательные операции записи и проведения документов.

В файловом режиме 1С работает с данными практически напрямую. Процесс 1cv8.exe (или rphost.exe в некоторых случаях) сам обращается к файлу базы данных 1Cv8.1CD. Здесь отсутствуют посредники, данные не нужно упаковывать для передачи по сети или между процессами. Проанализируем, на что тратит время SQL-вариант:

1. Сериализация данных: Данные должны быть преобразованы в формат, понятный SQL-серверу.
2. Передача между процессами: Даже если 1С и SQL стоят на одном физическом сервере, данные передаются между процессом 1С (rphost) и процессом SQL (sqlservr).
3. Управление транзакциями: SQL-сервер тратит ресурсы на ведение лога транзакций и обеспечение сложной логики блокировок.

Таким образом, высокая скорость файловой базы в тесте — это «чистая скорость» при отсутствии конкуренции за ресурсы. Как только мы добавляем второго, третьего и тем более пятнадцатого пользователя, ситуация в корне меняется.

Проанализируем риски файлового режима для 15 пользователей

Если в терминальном режиме работают 15 человек, переход на файловую базу крайне не рекомендуется. Рассмотрим основные причины, по которым SQL остается предпочтительным:

1. Механизм блокировок данных. В файловой базе при записи данных часто блокируется вся таблица целиком (а иногда и вся база на короткие промежутки). Это означает, что пока один пользователь проводит тяжелый документ, остальные 14 будут ждать освобождения ресурса. В SQL-варианте реализованы блокировки на уровне строк. Пятнадцать человек могут одновременно записывать разные документы в одну таблицу, не мешая друг другу. В реальной эксплуатации «медленный» SQL (25 попугаев) обеспечит более комфортную работу коллектива, чем «быстрая» файловая база (65 попугаев).

2. Технологическое ограничение в 4 Гб. В файловом формате .1CD существует жесткое ограничение: размер любой внутренней таблицы не может превышать 4 Гб. Если ваша база активно растет, вы рискуете в один момент получить критическую ошибку, когда база просто откажется принимать новые данные, хотя место на диске еще есть. В SQL-варианте размер таблиц ограничен только дисковым пространством и файловой системой сервера.

3. Надежность и восстановление. SQL-сервер обладает механизмом журналов транзакций (Transaction Logs). В случае внезапного отключения питания или сбоя системы SQL гарантирует целостность данных. Файловая база в таких условиях часто «бьется», что требует запуска утилиты chdbfl.exe, которая может просто удалить поврежденные записи для восстановления работоспособности файла.

Выясним причины низкой производительности SQL и способы оптимизации

Если SQL показывает всего 25 единиц в тесте Гилёва на SSD, это повод не для перехода на файловую базу, а для глубокой настройки сервера. Посмотрим на параметры, которые помогут сократить разрыв:

Настройка Shared Memory. Если сервер 1С и MS SQL Server установлены на одном компьютере, обязательно убедитесь, что используется протокол Shared Memory вместо TCP/IP. Это исключит накладные расходы на сетевой стек и значительно поднимет результат теста. Для этого в строке подключения сервера 1С к базе данных SQL можно использовать формат lpc:ИмяСервера или настроить приоритеты протоколов в SQL Server Configuration Manager.

Режим электропитания. Проанализируем настройки операционной системы. 1С крайне чувствительна к частоте процессора на одном ядре. В настройках Windows Server необходимо выставить схему «Высокая производительность» (High Performance). Также стоит проверить настройки BIOS/UEFI сервера: функции энергосбережения (C-States, SpeedStep) должны быть отключены или переведены в режим максимальной производительности.

Использование RLS (Row Level Security). Как отмечают эксперты, если в вашей конфигурации включено ограничение прав на уровне записей (RLS), файловая база начнет катастрофически тормозить даже при одном пользователе. SQL-сервер обрабатывает сложные запросы с RLS гораздо эффективнее за счет мощного оптимизатора запросов.

Как правильно сравнивать варианты базы

Для объективной оценки не стоит полагаться только на однопоточный тест. Рассмотрим более релевантные методы сравнения:

1. Запустите тест Гилёва одновременно в двух-трех сессиях. Вы увидите, как показатели файловой базы мгновенно упадут, в то время как SQL сохранит стабильность.
2. Проведите замер времени выполнения конкретной тяжелой операции (например, отчет «Ведомость по запасам» за год) в обеих базах.
3. Используйте встроенный в 1С механизм «Оценка производительности» (APDEX) для мониторинга реальных действий пользователей в течение рабочего дня.

Подведем итог

Переходить на файловую базу при наличии 15 пользователей и работающего SQL-сервера — это шаг назад. Файловая база — это решение для 1-3 пользователей с небольшим объемом данных. Для коллектива из 15 человек критически важны стабильность, надежность и возможность параллельной работы, которые обеспечивает только клиент-серверный режим.

Вместо смены режима работы рекомендуем сосредоточиться на тюнинге SQL-сервера и регламентных операциях: обновлении статистики, дефрагментации индексов и выносе TempDB на максимально быстрый диск (NVMe или RAM-диск). Это позволит поднять производительность SQL до комфортных значений, сохранив при этом все преимущества промышленного решения.