Моделировали не синтетическую нагрузку, а профиль крупной ERP-системы: 30 000 пользователей, 15 сценариев от закупок до бюджетирования, база на 1 ТБ и 11 часов непрерывной работы.
Что показал тест:
☑️ Postgres Pro Enterprise выдержала профиль нагрузки 1С:ERP на 30 000 пользователей.
☑️ СУБД прошла тест с запасом по CPU: утилизация не превышала 30%.
☑️ Узкие места оказались не в процессоре, а в хранении, временных объектах, статистике, памяти, NUMA и настройках ОС.
☑️ Часть найденных решений уже помогает настраивать Postgres Pro Enterprise под 1С через
pgpro_tune и пресетом 1c.tune.⚠️ Результат получили на типовом серверном оборудовании — без экзотической конфигурации под один бенчмарк.
Как шли к результату:
На 10 000 пользователей получили APDEX 0,853, но увидели очереди на диске с
pg_data. Вынесли pg_wal на отдельный NVMe.На 20 000 пользователей APDEX снизился до 0,790, а 1С получила более 800 невыполненных задач. Одного переноса WAL не хватило: перевели диски на 4K-блоки, собрали
RAID0 под pg_data и исправили пересечения CPU affinity.На 30 000 пользователей тест сначала упал: сервер БД перестал отвечать серверам 1С. Причина — активная работа с временными объектами и лавинный сброс кэшей.
Затем включили
enable_temp_memory_catalog, skip_temp_rel_lock и enable_background_freezer, вынесли временные файлы и таблицы в tmpfs, настроили work_mem и hash_mem_multiplier, уточнили статистику для проблемной колонки.📖 Подробнее о настройках читайте в документации.
Финальные правки сделали на уровне инфраструктуры: ограничили
C-state процессора и разместили PostgreSQL на одном NUMA-узле, чтобы снизить задержки CPU и памяти.После этого тест прошел успешно. Очередей на дисках не было, отклик на чтение держался в пределах 1 мс, на запись — в среднем до 2,5 мс.
🔗 Подробный разбор читайте на Хабре: там весь путь от первых запусков и проваленного APDEX до финальной конфигурации Postgres Pro Enterprise для 1С.
📢 Читайте нас в MAX