Переход с файлового варианта базы данных на клиент-серверный (MS SQL Server) часто воспринимается как автоматический способ ускорения системы. Однако на практике многие пользователи сталкиваются с обратным эффектом: проведение документов становится «вязким», а отчеты формируются дольше. Разберем подробно, почему так происходит, и проанализируем шаги, которые помогут вернуть и превзойти прежнюю скорость работы.
Проанализируем сначала саму структуру обмена данными. В файловом варианте работа происходит напрямую с файлом базы данных 1Cv8.1CD. Накладные расходы на передачу данных минимальны. В серверном же варианте появляется целая цепочка посредников: клиентское приложение передает запрос серверу 1С, сервер 1С формирует запрос к СУБД (MS SQL), СУБД обрабатывает данные и возвращает их серверу 1С, а тот — клиенту. Если в базе работает всего 5 пользователей, как в нашем случае, сетевые и протокольные задержки могут «съедать» весь выигрыш от мощности SQL-сервера.
Рассмотрим ситуацию, когда сервер 1С и MS SQL стоят на одной физической машине. В этом случае крайне важно исключить сетевой стек из обмена. Для этого настроим протокол Shared Memory. Использование TCP/IP внутри одного сервера создает лишнюю нагрузку. В «SQL Server Configuration Manager» убедимся, что протокол Shared Memory включен, а в строке подключения к базе в кластере 1С укажем локальное имя сервера.
Одной из главных причин торможения в серверном варианте являются настройки параллелизма. Рассмотрим параметр MAXDOP (Max Degree of Parallelism). По умолчанию в SQL Server он равен 0, что означает использование всех доступных ядер для выполнения одного запроса. Для 1С это часто оборачивается блокировками. Рекомендуется установить значение 1 (отключить параллелизм для запроса) или, в крайнем случае, 2 или 4, если ядер очень много. Это предотвратит ситуацию, когда один сложный запрос «парализует» работу всей СУБД.
Вместе с MAXDOP проанализируем параметр Cost Threshold for Parallelism. Если вы все же разрешили использование нескольких ядер, установите порог стоимости не менее 50. Это заставит SQL Server не расходовать ресурсы на распараллеливание мелких запросов, где накладные расходы на управление потоками выше, чем польза от них.
При проведении документов по партиям (процедура ДвижениеПартийТоваров), 1С активно создает временные таблицы. Все они живут в системной базе TempDB. Если эта база настроена неверно, она становится «бутылочным горлышком». Разберем, как ее ускорить:
TempDB равного размера. Оптимально — по количеству логических ядер процессора (но обычно не более 8).TempDB на самый быстрый диск (SSD или NVMe), желательно отдельно от основных данных и логов транзакций.T1117 и T1118, которые оптимизируют выделение страниц в TempDB и уменьшают конкуренцию между процессами.Выясним причину зависаний в процедуре ДвижениеПартийТоваров. В УТ 10.3 часто используется вспомогательный регистр накопления Списанные товары. Он нужен для отложенного проведения по партиям. Если этот регистр переполнен или по нему не закрыты остатки, система будет тратить колоссальное время на его обработку при каждом проведении чека или возврата.
Рассмотрим рекомендации опытных специалистов: если вы не планируете массовое перепроведение за старые периоды, этот регистр можно и нужно очищать. Также важно проверить актуальность итогов. Выполним в консоли или через стандартные процедуры пересчет итогов и установим актуальный период рассчитанных итогов на начало текущего месяца. Это значительно ускорит получение остатков партий.
В файловой базе 1С сама управляет индексами. В SQL-варианте это забота администратора. После миграции данных индексы могут быть сильно фрагментированы, а статистика — неактуальна. SQL Server будет строить неверные планы запросов, что приведет к тормозам.
Настроим регулярный Maintenance Plan, который должен включать:
Иногда причина кроется не в коде, а в базовых настройках «железа». Посмотрим на настройки электропитания. По умолчанию Windows Server часто стоит в режиме «Сбалансированный», что заставляет процессор сбрасывать частоты в моменты простоя. Для 1С это критично. Переключим схему питания в режим «Высокая производительность» (High Performance). Это касается как гостевой ОС, так и настроек самого хоста виртуализации (BIOS/UEFI).
Разберем вопрос оперативной памяти. SQL Server очень жаден до ресурсов. Если не ограничить Max Server Memory, он заберет всё под себя, не оставив памяти процессам 1С (rphost). Это приведет к свопингу (сбросу данных на диск), и скорость упадет в десятки раз. Оставьте операционной системе и серверу 1С минимум 4-8 ГБ, ограничив аппетиты SQL в его настройках.
В УТ 10.3 на старых платформах часто используются автоматические блокировки. В SQL-варианте это может приводить к тому, что при проведении одного документа блокируется вся таблица регистра. Проанализируем возможность включения режима Read Committed Snapshot (RCSI) на уровне базы данных SQL. Это позволит читающим запросам не ждать завершения пишущих транзакций, работая с версиями данных. Для включения выполним запрос:
ALTER DATABASE [Имя_Вашей_Базы] SET ALLOW_SNAPSHOT_ISOLATION ON;
ALTER DATABASE [Имя_Вашей_Базы] SET READ_COMMITTED_SNAPSHOT ON;
Важно: Перед включением этого режима убедитесь, что конфигурация корректно работает с версионностью (для УТ 10.3 на платформе 8.3 это обычно безопасно и дает отличный прирост скорости при многопользовательской работе).
Подводя итог, можно сказать: серверный вариант требует тонкой настройки. Если файловая база прощает отсутствие обслуживания, то SQL Server — нет. Проверьте Shared Memory, настройте MAXDOP, почистите регистр Списанные товары и не забудьте про регламентные задания по обновлению статистики. Только комплексный подход позволит получить ту производительность, ради которой затевался переход на клиент-серверную архитектуру.