← На главную

При переходе на крупные конфигурации, такие как 1С:ERP Управление предприятием, многие компании сталкиваются с резким падением производительности, даже если оборудование кажется достаточно мощным. В этой статье мы подробно разберем реальный кейс: сервер на 70-100 пользователей, база PostgreSQL и критическая проблема — открытие формы ресурсной спецификации занимает 30 минут. Проанализируем как аппаратную часть (выбор процессора, дисков, памяти), так и программные ошибки, приводящие к таким задержкам.

Диагностика проблемы: 1.3 миллиона запросов

Рассмотрим ситуацию, описанную в исходной задаче. Пользователи жалуются, что при открытии "Дерева" в конструкторе ресурсных спецификаций система зависает на полчаса. Замер производительности в конфигураторе показал, что эта операция генерирует 1 300 000 запросов к базе данных.

Давайте проанализируем, почему это происходит и почему замена сервера на самый мощный в мире не решит эту проблему полностью.

Это классическая архитектурная ошибка, известная как проблема N+1 или «чрезмерная болтливость» (Chatty Interface). В данном случае, вероятно, происходит следующее:

1. Клиентское приложение получает список узлов дерева.
2. Для каждого узла делается отдельный запрос к серверу (или БД), чтобы получить его свойства или подчиненные элементы.
3. Если узлов много, количество запросов растет в геометрической прогрессии.

Почему железо бессильно?
Предположим, у нас есть задержка (latency) при обращении к серверу всего 0.1 миллисекунды (это очень быстро).
1 300 000 запросов * 0.0001 сек = 130 секунд
Это 2 с лишним минуты чистого сетевого времени, не считая времени на выполнение кода. В реальности накладные расходы выше. Даже если мы поставим процессор, который работает в 2 раза быстрее, мы сократим время выполнения кода, но не избавимся от задержек на передачу данных между клиентом и сервером СУБД.

Решение:
Необходимо переписать алгоритм формирования дерева. Данные должны получаться одним (или несколькими крупными) запросами на сервере, дерево должно строиться в памяти сервера и передаваться на клиент уже в виде готовой структуры данных, например, через ДеревоЗначений или структуру, адаптированную для формы. Утверждения программистов о том, что "код максимально оптимизирован", в данном случае требуют независимой проверки.

Выбор процессора: AMD Ryzen 9000 vs Intel

Перейдем к выбору железа. Для сервера 1С и PostgreSQL критически важна однопоточная производительность. Чем выше частота ядра и чем больше инструкций за такт (IPC) оно выполняет, тем быстрее проводятся документы и выполняются транзакции.

Рассмотрим выбор между современными платформами:

1. Intel Core (13-14 поколение):

   Здесь мы сталкиваемся с архитектурой гибридных ядер (P-cores и E-cores). Для сервера 1С это может быть проблемой. Планировщик задач ОС не всегда корректно распределяет процессы rphost или postgres, иногда отправляя их на медленные энергоэффективные ядра (E-cores), что вызывает "фризы". Кроме того, существуют известные проблемы со стабильностью кристаллов в топовых моделях этих поколений.

2. AMD Ryzen 9000 (Zen 5):

   Это отличный выбор для "десктопного" сервера 1С. Все ядра (в рамках одного CCD) равнозначны и обладают высочайшей производительностью на ядро.

   • AVX-512: Процессоры Ryzen 7000/9000 поддерживают инструкции AVX-512. Современные версии PostgreSQL могут использовать их для ускорения некоторых операций (например, работы с JSONB), что дает преимущество.
   • 3D V-Cache (X3D): Технология увеличенного кэша полезна для баз данных, так как позволяет хранить больше страниц данных ближе к процессору. Однако частота таких процессоров обычно ниже. Для 1С чистая частота часто важнее объема кэша L3, поэтому обычные версии (например, Ryzen 9 9950X или 9700X) могут быть предпочтительнее для вычислительных задач 1С, чем X3D версии.

Проблема перегрева:
Поскольку серверная комната отсутствует, важно, чтобы сервер не перегревался. Современные процессоры Ryzen имеют настраиваемый TDP (Eco Mode). Ограничив потребление (например, до 105 Вт), мы потеряем 5-10% производительности в полной нагрузке, но получим холодный и тихий камень, что критично для офисного размещения.

Оперативная память: ECC или Non-ECC?

При планируемом объеме памяти в 192 Гб использование обычной (Non-ECC) памяти несет серьезные риски.

Вероятность возникновения случайной ошибки бита (bit flip) возрастает с увеличением объема памяти. Для игрового ПК это может привести к вылету текстуры, но для сервера базы данных (PostgreSQL) ошибка в памяти может привести к скрытому повреждению данных в таблицах БД. Вы можете узнать об этом только через месяц, когда база перестанет проходить тестирование или не сделается бэкап.

Рекомендация:
Платформа AM5 поддерживает ECC UDIMM (небуферизированную ECC память). Настоятельно рекомендуем найти и использовать именно её. Материнские платы уровня ASUS ProArt или серверные платы на чипсетах AMD обычно поддерживают этот тип памяти.

Дисковая подсистема: SSD для Базы Данных

Использование потребительских SSD (Samsung 970 EVO Plus, 980/990 Pro) для сервера баз данных ERP — это риск потери данных. Основные отличия серверных (Enterprise) SSD:

1. Защита от потери питания (PLP): Серверные SSD имеют конденсаторы, которые позволяют записать данные из кэша в ячейки памяти при внезапном отключении электричества. Обычные SSD могут потерять последние транзакции или повредить файловую систему.
2. Ресурс и стабильность (DWPD): База 1С:ERP активно пишет журналы транзакций (WAL). У обычных SSD быстро переполняется SLC-кэш, и скорость записи падает катастрофически. Серверные диски (например, Samsung PM9A3, Micron 7450) держат стабильную скорость записи 24/7.

Рассмотрим варианты подключения: лучше использовать M.2 Enterprise SSD (22110) или U.2 диски через переходники, если корпус позволяет обеспечить им обдув. Samsung PM1735 — отличный вариант, но требует слота PCIe или кабелей U.2.

Оптимизация хранения файлов

Одной из причин быстрого роста размера базы (100-150 Гб) является хранение присоединенных файлов (сканы договоров, картинки номенклатуры) непосредственно в таблицах базы данных.

Как проверить и исправить:

1. Перейдем в раздел НСИ и администрирование -> Настройка работы с файлами.
2. Убедимся, что установлена настройка Хранить файлы в томах на диске.
3. Если файлы хранятся в базе, необходимо настроить тома (папки на быстром диске сервера) и запустить обработку переноса файлов в тома. Это существенно уменьшит размер самой базы данных (.dt и файлов БД PostgreSQL), ускорит бэкапы и облегчит работу СУБД.

Программная настройка сервера (Linux + PostgreSQL)

Даже самое мощное железо нужно правильно настроить. Для связки Ubuntu 22.04 + PostgreSQL 14 + 1С обратите внимание на следующие параметры:

• Huge Pages: При наличии 192 Гб ОЗУ обязательно настройте Huge Pages. Это снизит нагрузку на процессор при управлении памятью.
• CPU Governor: Убедитесь, что режим управления питанием процессора установлен в performance. В Linux по умолчанию может стоять режим энергосбережения, который снижает частоту ядер при "рваной" нагрузке 1С, вызывая микрофризы.
• Настройки PostgreSQL для SSD: Установите параметр random_page_cost равным 1.1 (для NVMe SSD), чтобы планировщик запросов чаще использовал индексы, понимая, что случайное чтение "стоит" дешево.

Резюме

Для стабильной работы 1С:ERP на 100 пользователей в описанных условиях:

1. В первую очередь: Решить проблему с кодом в "Ресурсных спецификациях". 1.3 млн запросов не вытянет ни один сервер.
2. Процессор: AMD Ryzen 9000 серии — отличный выбор, но следите за охлаждением (используйте Eco Mode) и выбирайте материнскую плату с качественным VRM.
3. Память: Только ECC.
4. Диски: Enterprise SSD с защитой PLP.
5. Настройки: Вынести файлы в тома, настроить PostgreSQL под NVMe и Huge Pages.