← На главную

Подбор серверного оборудования для высоконагруженной информационной системы «1С:Предприятие» требует детального расчета каждого аппаратного компонента. Рассмотрим типовую задачу: обеспечение стабильной и быстрой работы двух основных баз данных объемом по 80 Гб под управлением СУБД PostgreSQL с одновременной работой около 150 активных пользователей. Разберем ключевые требования к архитектуре, процессору, подсистеме оперативной памяти и дисковым массивам.

1. Архитектурное разделение ролей

Для обслуживания 150 пользователей совмещение роли сервера приложений «1С:Предприятие» и сервера СУБД PostgreSQL на одной физической машине крайне не рекомендуется. Проанализируем причины:

1. Конкуренция за ресурсы: рабочие процессы кластера 1С rphost и процессы СУБД postgres будут непрерывно конкурировать за кэш процессора, оперативную память и дисковый ввод-вывод.
2. Оптимизация операционной системы: PostgreSQL традиционно показывает более высокую производительность под управлением 64-разрядных дистрибутивов Linux, тогда как сервер 1С может быть развернут как на Linux, так и на Windows Server.
3. Сетевое взаимодействие: при разделении серверов на два физических или изолированных виртуальных хоста необходимо объединить их выделенным сетевым линком со скоростью не менее 10 Гбит/с для исключения сетевых задержек при передаче выборок данных.

2. Требования к процессору (CPU)

Бизнес-логика платформы 1С и транзакционная обработка в СУБД в значительной степени завязаны на однопоточную производительность (Single-Core IPC). Выясним основные критерии выбора CPU:

1. Тактовая частота: выбираем процессоры с максимально высокой базовой и турбо-частотой (от 3.5–4.0 ГГц). Высокая частота обеспечивает быстрое проведение документов и выполнение алгоритмов перерасчета.
2. Количество ядер: для 150 пользователей серверу приложений 1С требуется не менее 16–24 физических ядер (из расчета 1 ядро на каждые 6–10 активных пользователей). Для сервера СУБД оптимально иметь от 12 до 16 высокочастотных ядер.
3. NUMA-архитектура: в двухсокетных системах межсокетное обращение к оперативной памяти вызывает задержки. В настройках BIOS сервера рекомендуется включить режим чередования узлов (Node Interleaving) либо средствами операционной системы жестко изолировать процессы по конкретным NUMA-нодам.

3. Расчет объема оперативной памяти (RAM)

Представление о том, что для 150 пользователей и баз суммарным объемом более 160 Гб достаточно 16–32 Гб RAM, ошибочно. Рассчитаем реальную потребность в оперативной памяти:

1. Память для сервера СУБД PostgreSQL: для эффективной работы СУБД необходимо удерживать «горячие» страницы данных и индексов в памяти. С учетом двух баз по 80 Гб серверу СУБД требуется от 64 до 128 Гб RAM. Параметр shared_buffers настраивается на уровне 25% от всей памяти машины, а параметр effective_cache_size — на уровне 50–75%.
2. Память для сервера 1С: каждый рабочий сеанс в среднем потребляет от 300 до 800 Мб оперативной памяти в процессах rphost. Для 150 сеансов требуется: 150 * 500 Мб = 75 Гб плюс запас на фоновые задания, регламентные процедуры и нужды ОС. Таким образом, серверу 1С необходимо от 96 до 128 Гб RAM.
3. Итоговая рекомендация: при совмещенной схеме требуется от 192 до 256 Гб оперативной памяти стандарта DDR4/DDR5 с поддержкой ECC. При раздельной схеме: 128 Гб под СУБД и 128 Гб под сервер 1С.

4. Организация дисковой подсистемы

Дисковый ввод-вывод — самое узкое место в работе 1С. Использование обычных жестких дисков SATA или SAS без SSD не обеспечит достаточного количества операций ввода-вывода (IOPS). Разберем оптимальную схему построения дисковой подсистемы:

1. Тип накопителей: применяем исключительно серверные твердотельные накопители (Enterprise SSD / NVMe) с аппаратной защитой от внезапного отключения питания (Power Loss Protection, PLP). Наличие PLP критически важно для производительности СУБД при сбросе журнала упреждающей записи (WAL) через системный вызов fsync.
2. Разделение данных по массивам:
   • Массив 1 (RAID-1): накопители под операционную систему и системные логи.
   • Массив 2 (RAID-10 или RAID-1 из быстрых NVMe): выделенный массив под каталоги баз данных PostgreSQL.
   • Массив 3 (RAID-1): отдельный массив под журнал транзакций СУБД (WAL), временные файлы и журнал регистрации 1С. Разрастание журнала регистрации в активных базах может превышать 30 Гб в месяц.
   • Массив 4 (HDD SATA в RAID-1/RAID-10): емкие механические диски для локального хранения резервных копий с последующей репликацией на внешнее сетевое хранилище.
3. Файловая система: накопители под СУБД в среде Linux форматируются в ext4 или xfs с обязательным флагом монтирования noatime, чтобы исключить накладные расходы на постоянную запись времени доступа к файлам таблиц.

5. Тонкая настройка кластера «1С:Предприятие» и PostgreSQL

Для надежного функционирования 150 сеансов выполним профилирование программной среды:

1. Сборка СУБД: используем только специализированную версию PostgreSQL, адаптированную для платформы «1С:Предприятие» (с поддержкой специфических блокировок и алгоритмов пересчета статистики).
2. Архитектура платформы: применяем строго 64-разрядный сервер «1С:Предприятие», исключающий ограничения адресации памяти в 32-битных процессах.
3. Настройка рабочих процессов: в консоли администрирования кластера серверов 1С распределяем нагрузку, задавая запуск нескольких рабочих процессов rphost (оптимально 1 процесс на каждые 25–30 пользователей или по одному на 2–4 ядра CPU).
4. Ограничение расхода памяти: в свойствах кластера 1С настраиваем параметры «Интервал перезапуска рабочих процессов» и «Безопасный расход памяти за один вызов», чтобы предотвратить зависание сервера при запуске неоптимальных пользовательских отчетов.
5. Оптимизация ядра Linux: задаем параметры ядра vm.swappiness = 1 и отключаем механизм Transparent Huge Pages (THP), что исключает деградацию производительности СУБД при активном выделении блоков памяти.