Ситуация, когда мощное серверное оборудование выдает крайне низкие результаты в тестах производительности (например, около 9–10 баллов по тесту Гилева), часто встречается при использовании связки 1С + PostgreSQL + Windows. Проанализируем типовой кейс: двухпроцессорный сервер Intel Xeon E5-2620v4 с объемом ОЗУ 128 ГБ, где развернута база объемом 50 ГБ. Мы разберем по шагам, как выжать максимум из этой конфигурации, настроить СУБД и операционную систему.
Первое, на что мы должны обратить внимание — это модель процессора. Серия E5-2620v4 имеет достаточно низкую базовую тактовую частоту (2.1 ГГц). Для 1С, которая критично зависит от производительности одного потока, это "бутылочное горлышко". Рассмотрим меры по исправлению ситуации:
Turbo Boost. Без него процессор будет работать на базовой частоте, что для 1С губительно. Также проанализируем настройки энергосбережения в BIOS (C-States, P-States) — их лучше перевести в режим Maximum Performance или OS Control.Hyper-Threading. Это позволяет физическим ядрам не делить ресурсы конвейера с виртуальными потоками, что дает прирост в однопоточных задачах 1С.Проанализируем ситуацию с дисковой подсистемой. Использование SSD RAID-1 на программных или дешевых интегрированных контроллерах может не давать ожидаемого прироста и даже мешать работе TRIM. Однако для надежности RAID-1 оправдан. Важно убедиться, что контроллер не кэширует записи без батарейки (BBU), так как это может привести к повреждению базы данных PostgreSQL при сбое питания.
Стандартные настройки PostgreSQL не подходят для работы с 1С. Разберем ключевые параметры, которые помогут нам ускорить работу.
Параметры памяти:
Важный нюанс PostgreSQL на Windows — работа с системным кэшем. Выясним причину, почему нельзя ставить огромный shared_buffers. В Windows PostgreSQL не имеет прямого доступа к дискам и использует системный кэш. Если выделить слишком много памяти под буферы СУБД, возникнет эффект двойного кэширования. Оптимально для Windows — от 512 МБ до 2 ГБ, остальное ОС заберет под кэш файлов.
shared_buffers = 512MB # Для Windows это "золотая середина"
work_mem = 128MB # Память для сортировок, увеличиваем при сложных отчетах
maintenance_work_mem = 1GB # Ускоряет индексацию и очистку
Настройки записи и журналов (WAL):
Для ускорения проведения документов изменим стратегию записи логов транзакций. Установка synchronous_commit = off существенно повышает скорость записи, хотя и несет минимальный риск потери последних нескольких секунд транзакций при жестком крахе сервера (не базы!).
checkpoint_completion_target = 0.9 # Растягиваем запись на диск
max_wal_size = 4GB # Увеличиваем, чтобы избежать частых чекпоинтов
min_wal_size = 1GB
synchronous_commit = off
Планировщик запросов (Optimizer):
Чтобы 1С правильно строила планы запросов на SSD, нужно скорректировать стоимость доступа к страницам данных. Установим random_page_cost в значение от 1.1 до 1.5, так как время поиска на SSD практически равно времени последовательного чтения.
seq_page_cost = 1.0
random_page_cost = 1.1 # Для SSD дисков
effective_cache_size = 96GB # Примерно 75% от свободной ОЗУ
В рассматриваемом случае терминальный сервер вынесен в Hyper-V, а SQL стоит на физическом хосте. Рассмотрим, какие задержки это вносит:
Сетевые задержки: Трафик между тонким клиентом в ВМ и сервером 1С/SQL на хосте проходит через виртуальный коммутатор. Проанализируем настройку VMQ (Virtual Machine Queues). На многих сетевых картах эта функция работает некорректно, вызывая микро-фризы. Попробуем отключить ее в свойствах сетевого адаптера.
Дисковая очередь: Если диски терминального сервера находятся на том же RAID-массиве, что и база данных, возникнет конкуренция за ввод-вывод. Рекомендуется разносить файлы VHDX терминального сервера и файлы базы данных на разные физические диски (или разные группы дисков).
Версия платформы играет огромную роль. Рассмотрим переход с версии 8.3.13 на более современные 8.3.15 или выше. В новых версиях оптимизирована работа с памятью и механизмы взаимодействия с PostgreSQL.
Режим совместимости: Обратите внимание, что многие механизмы оптимизации платформы (например, использование новых типов данных в SQL) не включатся, пока в конфигурации стоит старый режим совместимости. Однако даже простая замена исполняемых файлов платформы на 8.3.15.XXXX часто дает прирост в 10–15% за счет оптимизации кода rphost.
Одной из скрытых причин зависаний 1С на PostgreSQL под Windows является проблема с обновлением статистики. Выясним причину: в версиях PostgreSQL для Windows иногда возникает ошибка доступа к временным файлам статистики (Permission denied). Это приводит к тому, что планировщик начинает строить неверные планы запросов, и база "зависает" на простых операциях.
Рекомендации по регламентам:
ANALYZE базы данных средствами pgAdmin или через скрипт.autovacuum. Для 1С лучше сделать его более агрессивным, чтобы он чаще очищал мелкие таблицы.*.db) и журналы транзакций (pg_wal). Это одна из самых частых причин "зависаний" в режиме бездействия.Посмотрим на финальный список действий для реанимации производительности:
shared_buffers до 512МБ-2ГБ, выключаем synchronous_commit, подстраиваем random_page_cost под SSD.После выполнения этих шагов показатель в тесте Гилева должен вырасти с 9.33 до минимум 25–30 баллов, что обеспечит комфортную работу пользователей в базе объемом 50 ГБ.