Многие системные администраторы и разработчики сталкиваются с парадоксальной ситуацией: при переходе с файлового варианта базы на клиент-серверный (SQL) производительность системы, измеряемая в «попугаях» (тест Гилева), резко падает. Если файловая база на современном «железе» может выдавать 80–100 единиц, то свежеустановленный SQL-сервер часто показывает скромные 10–15 единиц. Рассмотрим подробнее, почему так происходит, и разберем по шагам, как сократить этот разрыв.
Для начала проанализируем ситуацию. В файловом варианте 1С работает напрямую с данными в рамках одного процесса. Нет сетевых задержек, нет накладных расходов на передачу данных между процессом rphost и процессом СУБД (postgres.exe или sqlservr.exe). Однако файловый вариант имеет жесткие ограничения по количеству пользователей и объему базы (блокировки всей таблицы при записи).
Переход на SQL решает проблему блокировок, но вводит новые переменные: задержки (latency) при взаимодействии между сервером приложений и сервером баз данных. Если железо настроено на режим энергосбережения, каждая такая микрооперация заставляет процессор «просыпаться», что выливается в катастрофическое падение производительности в синтетических тестах. Выясним, как это исправить.
Как показывает практика, основной причиной низких показателей на SQL являются настройки энергосбережения центрального процессора. Разберем, что нужно сделать в BIOS сервера:
Maximum Performance или System Controlled (в зависимости от вендора). Как мы видим из опыта, переключение управления питанием на сторону системы или, наоборот, жесткая фиксация в BIOS может поднять производительность с 12 до 38–40 попугаев.Hyper-Threading позволяет получить более стабильный результат в однопоточных тестах, так как физическое ядро не делится между двумя логическими потоками.После настройки BIOS необходимо убедиться, что Windows или Linux не ограничивают ресурсы программно. Проанализируем настройки электропитания в ОС:
В Windows необходимо зайти в «Панель управления» -> «Электропитание» и выставить схему «Высокая производительность». Но этого недостаточно. Рекомендуется использовать утилиты для отключения парковки ядер (Core Parking). Когда ядра «паркуются», операционная система тратит время на их активацию при поступлении нагрузки от rphost.
Также важно настроить исключения антивируса. Проверьте, что процессы postgres.exe и rphost.exe, а также папки с данными баз данных и временными файлами 1С исключены из сканирования в реальном времени.
Стандартные настройки PostgreSQL ориентированы на безопасность данных и универсальность, а не на максимальную скорость 1С. Рассмотрим основные параметры в файле postgresql.conf, которые помогут нам ускорить работу:
Параметр synchronous_commit:
По умолчанию он установлен в on. Это означает, что сервер ждет подтверждения записи транзакции на диск. Для теста Гилева и общей отзывчивости системы это самое узкое место. Попробуем установить:
synchronous_commit = off
Это позволит серверу подтверждать транзакцию сразу после записи в кэш, не дожидаясь физического сброса на диск. Риск потери данных при сбое питания минимален при наличии ИБП, но прирост скорости будет колоссальным.
Настройка памяти:
Для эффективной работы shared_buffers должен составлять около 25-40% от общего объема ОЗУ. Рассмотрим пример настройки для сервера с 32 ГБ оперативной памяти:
shared_buffers = 8GB
work_mem = 64MB
maintenance_work_mem = 512MB
effective_cache_size = 24GB
Автовакуум:
1С создает и удаляет множество временных таблиц. Чтобы база не «раздувалась» и не тормозила, сделаем autovacuum более агрессивным:
autovacuum_naptime = 20s
autovacuum_vacuum_scale_factor = 0.01
autovacuum_analyze_scale_factor = 0.005
Если вы используете NVMe-диски, обратите внимание на драйверы. Стандартные драйверы Windows иногда показывают худшие результаты в операциях случайной записи (Random Write), чем специализированные драйверы от производителя (например, Samsung или Intel). Проанализируем ситуацию с диском: если в системе диск отображается как стороннее устройство, попробуйте обновить прошивку и установить родное ПО для управления SSD.
Также убедитесь, что база данных и файлы логов транзакций (pg_wal) по возможности разнесены на разные физические диски. Это снизит конкуренцию за головки чтения/записи (в случае HDD) или за контроллер (в случае SSD).
Если сервер 1С и PostgreSQL установлены на одной физической или виртуальной машине, убедитесь, что они общаются через Shared Memory, а не через сетевой протокол TCP/IP. Обращение через localhost (127.0.0.1) все равно проходит через сетевой стек ОС, что добавляет задержки. В настройках подключения к базе данных в консоли администрирования 1С попробуйте указать имя сервера, которое разрешается в локальный протокол, или проверьте настройки shm в конфигурации PostgreSQL.
Мы выяснили, что разрыв между 80 «попугаями» в файловой базе и 12 в SQL — это не приговор, а следствие неоптимизированных настроек железа и софта. Выполнив следующие шаги, вы сможете добиться результатов в 35–50 единиц на SQL, что является отличным показателем для клиент-серверного режима:
synchronous_commit = off в PostgreSQL.Помните, что синтетические тесты — это лишь индикатор. Реальная производительность в многопользовательской среде на SQL всегда будет выше за счет правильной работы с блокировками, даже если «попугаев» в одиночном тесте меньше, чем в файловом варианте.