В данной статье мы подробно разберем задачу подбора оборудования для сервера 1С:Предприятие, работающего в связке с PostgreSQL. Мы проанализируем реальную ситуацию, когда текущее оборудование перестало справляться с нагрузкой (70 пользователей, тест Гилева 8-9 баллов), и рассмотрим, какие характеристики железа являются критичными для производительности системы.
Рассмотрим исходные данные. Имеется сервер на базе двух процессоров Xeon E5-2620 v2 (2.10GHz), 128 Гб ОЗУ и RAID 10 из SATA SSD. Операционная система Windows 2008R2, СУБД PostgreSQL. Пользователи жалуются на медленное проведение документов и формирование отчетов.
Проанализируем результаты синтетического теста Гилева (TPC-1C). Показатель в 8-9 баллов является критически низким ("Плохо"). Это свидетельствует о том, что система не справляется с однопоточной нагрузкой. Основные причины тормозов в данном случае:
При выборе нового процессора часто совершается ошибка: погоня за количеством ядер в ущерб их частоте. Рассмотрим, почему для 1С это неправильный подход.
Архитектура 1С устроена так, что выполнение кода в рамках одной сессии (проведение документа, выполнение запроса) происходит последовательно в одном потоке. Если у вас будет 56 ядер с частотой 2.0 ГГц, один пользовательский процесс все равно будет выполняться медленно, так как он не может "размазаться" по всем ядрам.
Рекомендация: Нам нужны процессоры с максимально высокой базовой частотой (от 3.0 ГГц и выше) и современным техпроцессом (высокий IPC — количество инструкций за такт).
В обсуждении предлагались два варианта:
Вариант 1 (Предпочтительный): 2 процессора Xeon Gold 6334 (8 ядер, 3.6 ГГц).
Вариант 2 (Неподходящий): 2 процессора Xeon Gold 5420+ (28 ядер, 2.0 ГГц).
Первый вариант обеспечит значительно более высокую отзывчивость системы, несмотря на меньшее количество ядер. Для 70 пользователей 16-24 быстрых физических ядер вполне достаточно.
Существует дискуссия о целесообразности использования топовых десктопных процессоров (например, Intel Core i9 или AMD Ryzen 9) в качестве серверов 1С. Разберем плюсы и минусы.
Плюсы десктопных решений:
Минусы и риски:
rphost может попасть на медленное ядро, вызвав фризы. Рекомендуется отключать E-cores в BIOS или использовать утилиты привязки ядер, но это требует дополнительной настройки.Для критически важных систем с 70 пользователями рекомендуется оставаться на серверной архитектуре (Xeon Gold / Platinum) или использовать десктопное железо только при наличии горячего резерва и полной готовности к простоям.
Рассмотрим выбор накопителей. SATA SSD (даже в RAID 10) уже не способны обеспечить необходимую скорость отклика для базы данных на 70 активных пользователей. Узким местом становится сам интерфейс SATA (максимум 600 Мб/с и высокие задержки).
Рекомендация: Переход на NVMe SSD обязателен.
Однако здесь есть важный нюанс — выбор между Consumer (бытовыми) и Enterprise (серверными) SSD:
Если бюджет ограничен и используются бытовые NVMe, обязательно наличие надежного ИБП и регулярных бэкапов (желательно, транзакционных логов). Организация RAID для NVMe возможна программными средствами (VROC, mdraid в Linux) или средствами ZFS, так как аппаратные контроллеры для NVMe очень дороги.
Покупка нового железа — это только половина решения. Без правильной настройки софта прирост может быть незначительным.
1. Операционная система для СУБД
PostgreSQL значительно эффективнее работает в среде Linux. Это связано с:
Разумным решением будет вынести сервер СУБД на отдельную машину (или виртуальную машину) под управлением Linux, оставив сервер приложений 1С на Windows, если это необходимо администраторам, или также перевести его на Linux.
2. Настройка PostgreSQL
Конфигурационный файл postgresql.conf должен быть настроен под имеющееся железо. Стандартные настройки не используют всю доступную память. Обратите внимание на параметры:
shared_buffers = 25% от ОЗУ
effective_cache_size = 50-75% от ОЗУ
work_mem = рассчитывается исходя из кол-ва подключений
random_page_cost = 1.1 (для NVMe дисков)
Если вы выбираете двухпроцессорный сервер, необходимо помнить про NUMA (Non-Uniform Memory Access). Память разделена между процессорами. Если процесс выполняется на процессоре №1, а обращается к памяти процессора №2, возникают задержки.
Для 1С это критично. Решением может быть виртуализация: создание двух виртуальных серверов 1С на одном физическом, где каждая ВМ жестко привязана к своему процессору и его локальной памяти (CPU affinity). Это позволит избежать задержек межпроцессорной шины.
Для решения проблемы производительности на 70 пользователей и обеспечения надежности, рекомендуем следующую конфигурацию:
Такой подход обеспечит комфортную работу, высокий балл в тестах производительности и сохранность данных.