В процессе эксплуатации систем на базе 1С:Предприятие 8.3 часто возникает ситуация, когда привычное железо перестает справляться с возросшими аппетитами современных конфигураций, таких как Бухгалтерия предприятия 3.0. В этой статье мы подробно разберем реальный кейс анализа производительности сервера BladeCenter HS22 и выясним, почему даже при наличии двух процессоров система может "задыхаться" при работе 15-20 пользователей. Мы проанализируем аппаратные узкие места, программные настройки СУБД PostgreSQL и методики тестирования.
Рассмотрим конфигурацию оборудования, которая стала предметом обсуждения:
Проанализируем ситуацию: для современной "Бухгалтерии 3.0", работающей на управляемых формах, ключевым показателем является тактовая частота одного ядра. Процессор Xeon E5504 с частотой 2.0 ГГц и отсутствием технологии Turbo Boost является главным "бутылочным горлышком". 1С — это система, где многие критические операции (проведение документов, закрытие месяца) выполняются в один поток. Частота 2 ГГц для этих задач сегодня считается критически низкой. Минимально рекомендуемый порог для комфортной работы начинается от 3.0 ГГц, а в идеале — 3.5 ГГц и выше.
Вторым важным моментом является объем оперативной памяти. 22 Гб на связку из ОС, сервера 1С и сервера базы данных — это крайне мало для 15-20 активных пользователей. Учитывая, что каждый рабочий процесс rphost.exe может потреблять значительные объемы памяти, система неизбежно начнет использовать файл подкачки, что при медленных дисках приведет к "зависаниям", на которые жалуются пользователи.
Чтобы перевести субъективные жалобы пользователей в объективные цифры, используем стандартный нагрузочный тест (Тест Гилева). В нашем рассматриваемом случае тест показал результат 4.72.
Разберем, что означает эта цифра:
Показатель 4.72 подтверждает, что сервер работает на пределе своих физических возможностей или настроен некорректно. Одной из причин такого низкого балла часто является включенный режим энергосбережения в BIOS сервера. Рекомендация: обязательно переключите профиль электропитания в BIOS в режим Maximum Performance (или аналогичный), а в самой ОС Windows выберите схему "Высокая производительность". Это позволит процессору всегда работать на своей максимальной частоте без попыток снизить вольтаж в моменты простоя.
Если аппаратная модернизация временно невозможна, попробуем выжать максимум из имеющегося железа через тонкую настройку файла конфигурации postgresql.conf. По умолчанию PostgreSQL поставляется с очень консервативными настройками, рассчитанными на совместимость с любым слабым железом, что губительно для 1С.
Разберем по шагам ключевые параметры, которые необходимо изменить (путь к файлу обычно: C:\Program Files\PostgreSQL\X.X-X.1C\data\postgresql.conf):
# Основные настройки памяти
max_connections = 40
shared_buffers = 4096MB
work_mem = 128MB
maintenance_work_mem = 512MB
effective_cache_size = 12GB
# Настройки записи на диск
fsync = on
synchronous_commit = off
checkpoint_completion_target = 0.9
# Планировщик и вакуум
autovacuum = on
max_files_per_process = 1000
Проанализируем эти параметры:
Чтобы понять, является ли проблемой связка "Сервер 1С + SQL", проведем эксперимент: создадим пустую файловую базу на том же сервере и запустим тест производительности в ней. Если в файловом варианте количество "попугаев" Гилева значительно выше (например, 15-20), значит, текущие настройки PostgreSQL или производительность дисковой подсистемы под нагрузкой SQL являются слабым местом.
Важно помнить про диски. В серверах BladeCenter HS22 часто используются классические HDD. Замена их на SSD (даже через переходники в старые корзины) дает колоссальный прирост скорости для базы данных. Также проверьте состояние батарейки (BBU) на RAID-контроллере. Если батарейка вышла из строя, контроллер отключает кэш записи (переходит в режим Write-Through), что снижает скорость работы с базой данных в разы.
Автор вопроса упоминает, что выгрузка в .dt весом 1.8 Гб занимает 14 минут, а загрузка на домашнем ПК происходит быстрее. Это прямое следствие низкой частоты процессора на сервере и медленной дисковой записи. Процесс выгрузки/загрузки .dt — это интенсивная работа с временными файлами и распаковка/запаковка данных, что критично к скорости одного ядра.
Полезный совет: в клиент-серверном варианте для создания резервных копий вместо .dt лучше использовать средства самого PostgreSQL (утилита pg_dump). Это работает быстрее и надежнее, так как .dt предназначен в первую очередь для миграции между разными СУБД, а не для регулярного бэкапа.
Подводя итог нашему анализу, можно составить следующий план действий для оживления работы 1С на данном сервере:
shared_buffers, work_mem и особенно synchronous_commit = off.Рассмотренный случай наглядно показывает, что количество ядер процессора (в данном случае их 8 на два сокета) не компенсирует их низкую индивидуальную мощность при работе с бизнес-логикой 1С.