Проблема низкой производительности 1С в связке с СУБД PostgreSQL — одна из самых частых задач, с которыми сталкиваются системные администраторы. Ситуация, когда тест Гилева показывает всего 11 единиц при наличии SSD-массива и 32 ГБ оперативной памяти, сигнализирует о серьезном дисбалансе в настройках системы или аппаратных ограничениях. Разберем пошагово, как выявить "узкие места" и оптимизировать работу сервера.
Проанализируем исходные данные: использование процессора Intel i3 с 2 физическими ядрами для обслуживания 40 баз и 15 пользователей — это критическая архитектурная ошибка. В среде 1С и СУБД распределение нагрузки происходит следующим образом: как минимум одно ядро требуется для процессов операционной системы, одно — для процессов PostgreSQL и еще несколько — для рабочих процессов сервера 1С (rphost.exe).
Рассмотрим ситуацию подробнее: при наличии всего 2 ядер система постоянно находится в состоянии "очереди к процессору". Когда 15 пользователей одновременно открывают по 4-5 баз, количество активных сеансов и регламентных заданий кратно возрастает. Даже замена i3 на Xeon E3-1275 (4 ядра / 8 потоков) является лишь минимально необходимым шагом. Для комфортной работы с таким количеством баз рекомендуется использовать процессоры с 8 и более ядрами, чтобы избежать конкуренции за ресурсы между СУБД и сервером приложений.
Выясним причину, по которой использование 32-битного сервера 1С (x32) на мощном железе не имеет смысла. Процесс rphost в 32-битной версии имеет жесткое ограничение на адресное пространство памяти (не более 3.5 ГБ). В условиях, когда запущено 40 баз, этот лимит исчерпывается мгновенно. Это приводит к следующим последствиям:
Решение: Переходим на 64-битный сервер 1С. Это позволит рабочим процессам использовать все 32 ГБ доступной оперативной памяти, что критически важно для кэширования данных и стабильной работы большого количества информационных баз.
Проанализируем предоставленный конфиг PostgreSQL. В нем содержатся параметры, которые могут не ускорять, а замедлять систему в условиях Windows. Разберем наиболее важные из них:
Параметр work_mem: Указанное значение work_mem = 2024MB является крайне опасным. Этот объем памяти выделяется PostgreSQL на каждую операцию сортировки или группировки внутри одного запроса. Если один запрос выполняет несколько сортировок, он может забрать десятки гигабайт памяти, что мгновенно приведет к краху системы или уходу в глубокий своп.
Рекомендуем установить более безопасное значение:
# Для 15 пользователей и 32 ГБ ОЗУ
work_mem = 64MB
maintenance_work_mem = 512MB
Параметр fsync и синхронизация: У автора fsync = off. Это значительно повышает скорость, но несет риск потери данных при внезапном отключении питания. Поскольку используется RAID-контроллер с батарейкой (BBU), это допустимо, но лучше использовать более безопасные режимы, так как SSD RAID 6 сам по себе имеет задержки на запись.
Особенности Windows: PostgreSQL на Windows чувствителен к механизму переименования файлов и работы со статистикой. Рассмотрим настройку версии СУБД. Рекомендуется использовать сборки Postgres Pro (например, версии 10.5 и выше), где исправлены многие проблемы взаимодействия с файловой системой Windows.
Посмотрим на конфигурацию дисков. Использование RAID 6 для баз данных — спорное решение. RAID 6 имеет так называемый "Write Penalty" (штраф на запись) — для каждой операции записи контроллеру необходимо вычислить и записать две контрольные суммы. Несмотря на то, что используются SSD, при интенсивной записи логов транзакций (WAL) и временных таблиц 1С, контроллер может стать бутылочным горлышком.
Рекомендация: Для высоконагруженных БД 1С классическим стандартом является RAID 10. Он обеспечивает максимальную скорость записи и чтения без вычислительных задержек, характерных для RAID 5/6.
Когда у вас 40 баз, даже если активно используются только 10, остальные 30 продолжают выполнять фоновые задачи в автоматическом режиме. Это обновление индексов полнотекстового поиска, загрузка курсов валют, расчет итогов и классификация контактов. Каждое такое задание запускает фоновый сеанс, который потребляет процессорное время и память.
Выполним оптимизацию регламентных заданий:
ОбновлениеИндексаППД (полнотекстовый поиск) можно запускать реже, если пользователи не пользуются глобальным поиском ежеминутно.online_analyze в Postgres. Постоянный анализ таблиц во время записи может создавать лишнюю нагрузку.В исходных данных указано использование NIC Teaming в динамическом режиме. Для 1С важна не пропускная способность (ширина канала), а минимальные задержки (latency). Объединение карт иногда вносит неразбериху в очередность пакетов TCP. Рассмотрим действия по проверке сети:
Часто системные администраторы забывают про базовые настройки ОС Windows. Разберем их:
Схема электропитания: В панели управления сервером должна быть строго установлена схема "Высокая производительность" (High Performance). В дополнительных параметрах проверим, чтобы минимальное и максимальное состояние процессора было равно 100%. Это предотвратит "засыпание" ядер процессора i3/Xeon, на пробуждение которых уходят миллисекунды, критичные для 1С.
Исключения антивируса: Если на сервере установлен Windows Defender или сторонний антивирус, добавим в исключения:
snccntx в профиле пользователя службы).rphost.exe, rmngr.exe, ragent.exe, postgres.exe.Проанализировав ситуацию, мы видим, что низкий результат теста (11 попугаев) вызван совокупностью факторов. Для исправления ситуации выполним следующие действия:
work_mem в postgresql.conf, снизив его до разумных пределов (64-128MB).Соблюдение этих рекомендаций позволит поднять показатели теста Гилева с 11 до 35-45 единиц даже на текущем оборудовании, что обеспечит комфортную работу пользователей без зависаний системы.