Переход в клиент-серверный режим обычно ускоряет 1С, но не всегда и не сам по себе. Если 1С с SQL тормозит, причина чаще всего не в самой связке, а в настройках сервера баз данных, которые остались по умолчанию: памяти выделено сколько досталось, обслуживание не настроено, а диски работают на пределе.
Разберём, что проверить в MS SQL Server и PostgreSQL, чтобы клиент-серверная база работала так, как от неё ждут.
Три уровня, где теряется время
В клиент-серверном режиме между пользователем и данными стоят три звена, и тормозить может любое:
- клиент — компьютер пользователя и канал до сервера;
- сервер 1С:Предприятия — рабочие процессы, память, распределение сеансов;
- сервер СУБД — MS SQL или PostgreSQL, где лежат данные.
Начинать нужно с замера, чтобы понять, какое звено виновато: тест Гилёва покажет общую картину, а журнал ожиданий СУБД — конкретные операции, которые ждут ресурсов дольше остальных. Без этого настройка превращается в перебор.
MS SQL Server: что проверить в первую очередь
Настройки, которые чаще всего оказываются виноваты:
- Максимальная память сервера. По умолчанию SQL Server готов забрать всю память машины, включая ту, что нужна операционной системе и серверу 1С. Ограничение задаётся явно, с запасом для остальных служб.
- Модель восстановления базы. Полная модель без регулярного резервного копирования журнала транзакций приводит к тому, что журнал разрастается на десятки гигабайт и съедает диск.
- Файл tempdb. На нём выполняются временные таблицы, которых в 1С очень много. Его стоит вынести на быстрый диск и разбить на несколько файлов по числу ядер.
- Автоприрост файлов. Прирост «на 1 МБ» или «на 10 %» приводит к постоянным паузам при росте базы. Задаётся фиксированный разумный шаг.
- Уровень изоляции и блокировки. Для 1С включается управляемый режим блокировок и снимок версий строк — иначе пользователи ждут друг друга на ровном месте.
- Обслуживание индексов и статистики. План обслуживания с реиндексацией и обновлением статистики по расписанию, ночью.
Отдельно: сервер 1С и SQL на одной машине конкурируют за память. Это рабочая схема для небольших внедрений, но тогда лимиты памяти нужно расставить руками, а не надеяться, что службы договорятся.
PostgreSQL: особенности сборки для 1С
PostgreSQL для 1С — это не обычный дистрибутив, а специальная сборка с патчами. Установка «ванильного» PostgreSQL приводит к странным ошибкам и потере производительности на ровном месте, поэтому первое, что стоит проверить, — какая именно сборка стоит.
Дальше — параметры конфигурации, которые по умолчанию рассчитаны на скромную машину:
- объём разделяемой памяти и памяти под операции сортировки и соединения;
- параметры автоочистки: в базах 1С таблицы меняются интенсивно, и вакуум должен успевать за нагрузкой;
- настройки контрольных точек — редкие контрольные точки дают всплески записи на диск;
- параметры планировщика, которые зависят от типа дисков.
Как и в случае с MS SQL, обслуживание должно быть регулярным и ночным: сбор статистики, очистка, переиндексация.
Диски: чаще всего дело в них
Клиент-серверная 1С требовательна к дискам. Если база лежит на обычном жёстком диске, никакие настройки памяти не спасут: система будет ждать ввод-вывод.
Что проверить:
- база и журнал транзакций на SSD, а не на HDD;
- журнал транзакций желательно отдельно от файлов данных;
- tempdb (для MS SQL) на самом быстром носителе;
- загрузка диска в диспетчере ресурсов во время типичной работы — если она держится у ста процентов, дальше можно не искать.
Сетевые хранилища и виртуальные диски с тонким выделением места дают неприятный эффект: скорость плавающая, и «иногда тормозит» становится постоянным диагнозом.
Сеть между сервером 1С и СУБД
Про этот участок забывают чаще всего. Сервер 1С:Предприятия и сервер баз данных обмениваются очень интенсивно, и любая задержка между ними умножается на количество обращений.
Признаки проблемы: процессор и диски на обеих машинах свободны, а операции всё равно долгие. Что проверить:
- сервер 1С и СУБД в одной сети, а не через маршрутизатор или туннель;
- скорость канала между ними — гигабит и выше;
- нет ли инспекции трафика между машинами;
- если серверы виртуальные, не конкурируют ли они за ресурсы одного хоста.
Для небольших внедрений проще держать оба сервера на одной машине — тогда сетевого участка нет вовсе, но нужно вручную развести память между службами.
Типовые ошибки, которые мы находим
- Обычный PostgreSQL вместо сборки для 1С. Работает, но с ошибками и медленно.
- Резервное копирование средствами СУБД в рабочее время. Полный бэкап днём даёт всплеск нагрузки на диски.
- Одновременно бэкап 1С и бэкап виртуальной машины. Две системы копируют одно и то же и мешают друг другу.
- Антивирус проверяет файлы базы данных. Каталоги данных СУБД должны быть в исключениях.
- Журнал регистрации в файловом формате при большой нагрузке. Стоит переводить в формат SQLite или ограничивать глубину хранения.
- Тестирование и исправление годами не запускалось. Клиент-серверный режим не отменяет обслуживания базы, о нём — в статье про оптимизацию 1С.
Когда SQL не нужен вовсе
Клиент-серверный режим стоит денег: лицензия сервера 1С, лицензия СУБД (для MS SQL) и более требовательное железо. При небольшом числе пользователей эти вложения часто не окупаются.
Ориентир простой: если пользователей немного, а база небольшая, обычно достаточно терминального сервера с файловой базой — все работают на одной машине, сеть перестаёт быть узким местом, а платить за СУБД не нужно. Подробное сравнение вариантов — в статье про работу 1С по сети.
Клиент-серверный режим оправдан, когда пользователей много, база выросла, идут тяжёлые обмены и отчёты, нужны надёжные блокировки и восстановление на точку во времени.
Что смотреть в мониторинге каждый день
Клиент-серверная 1С требует наблюдения — иначе о проблеме узнаёшь от бухгалтерии в день сдачи отчётности. Минимальный набор показателей, который стоит держать под рукой:
- Свободное место на дисках с данными, журналом транзакций и резервными копиями. Заполнение диска под сто процентов останавливает работу мгновенно.
- Загрузка процессора сервера СУБД в рабочие часы: постоянные сто процентов означают, что запас исчерпан.
- Память рабочих процессов сервера 1С — регулярные перезапуски процессов видны как «выкидывает из базы».
- Длительность резервного копирования. Если бэкап перестал укладываться в ночное окно, он поедет в рабочее время.
- Ошибки регламентных заданий — их удобно смотреть раз в день, а не когда что-то сломается.
Отдельно — проверка восстановления. Резервная копия, которую ни разу не разворачивали, это не копия, а надежда. Раз в месяц стоит поднимать копию базы на тестовом сервере и убеждаться, что она открывается.
Порядок диагностики
- Замерить производительность и записать исходные цифры.
- Посмотреть загрузку процессора, памяти и дисков на сервере СУБД во время работы.
- Проверить лимит памяти SQL Server (или параметры памяти PostgreSQL).
- Проверить модель восстановления и размер журнала транзакций.
- Убедиться, что обслуживание индексов и статистики выполняется и выполняется ночью.
- Проверить размещение файлов по дискам, вынести tempdb и журнал.
- Посмотреть журнал ожиданий: чего именно ждут запросы.
- Если ждут блокировок — разбирать код доработок, а не настройки сервера.
- Повторить замер и сравнить.
Что делаем мы
Разворачиваем и настраиваем 1С в клиент-серверном режиме — с MS SQL или PostgreSQL, с обслуживанием базы по расписанию и резервным копированием. Если у вас уже есть сервер, разбираем текущие настройки и показываем, что именно исправить.
Готовый сервер для 1С в аренду обходится от 29 900 ₽ в год за минимальную конфигурацию; вариант с MS SQL для веб-доступа к 1С — 5 500 ₽ в месяц. Перед оплатой разворачиваем вашу базу на тестовом сервере на 7 дней, чтобы вы сравнили скорость на своих данных. Работы по сопровождению считаются почасово, от 4 000 ₽ за час.
Позвоните по номеру +7 495 780-66-50 или оставьте заявку — посмотрим, где именно теряется время в вашей системе.
