При организации инфраструктуры для 1С:Предприятия часто возникает дилемма: использовать имеющееся разнородное оборудование, распределяя роли между несколькими машинами, или консолидировать все на одном, более мощном узле. В данной статье мы подробно разберем ситуацию, когда количество пользователей невелико (15–20 человек), но базы данных имеют существенный объем. Мы проанализируем влияние архитектуры на производительность, рассмотрим нюансы работы PostgreSQL на разных операционных системах и обсудим требования к аппаратной части.
Давайте рассмотрим типичную ситуацию. У нас есть два сервера с разной производительностью:
Клиенты работают через тонкий клиент по протоколу HTTPS. Возникает вопрос: стоит ли оставлять такую разнесенную архитектуру или лучше перенести все роли на первый сервер? Давайте разберем это решение по шагам, опираясь на технические детали взаимодействия компонентов системы.
Первое, что нам необходимо понять — как взаимодействуют сервер приложений 1С и сервер баз данных (СУБД). В текущей схеме (разнесенные сервера) взаимодействие происходит по сети.
Почему объединение на одном сервере лучше для малых внедрений?
Когда сервер 1С (процесс rphost) и СУБД (например, postgres) находятся на разных физических машинах, обмен данными идет через сетевой стек (TCP/IP). Платформа 1С:Предприятие генерирует огромное количество мелких запросов к базе данных. Даже в гигабитной сети существуют задержки (latency).
Если мы переносим обе роли на один сервер, включается механизм Shared Memory (Общая память). Это позволяет процессам обмениваться данными напрямую через оперативную память, минуя сетевой интерфейс, даже если это локальный интерфейс localhost. Исключение накладных расходов на упаковку и распаковку сетевых пакетов дает прирост производительности от 10% до 20%, что особенно заметно на «тяжелых» операциях, таких как закрытие месяца или перепроведение документов.
Вывод: При количестве пользователей до 50–100 человек разделение ролей на физически разные серверы часто нецелесообразно, если только это не продиктовано требованиями безопасности. Для 20 пользователей схема «Все на одном» будет работать значительно быстрее.
В исходной ситуации используется связка Windows 10 Pro + PostgreSQL. Давайте проанализируем, почему это не самое оптимальное решение и как его улучшить.
PostgreSQL изначально разрабатывался для Unix-подобных систем. В Linux создание нового процесса (команда fork) — это очень дешевая и быстрая операция. В Windows создание процессов требует значительно больше ресурсов. Поскольку PostgreSQL создает отдельный процесс для каждого подключения, на Windows это может стать узким местом при высокой нагрузке.
Потери производительности: Как отмечают эксперты, PostgreSQL на Windows может работать в 1.5–2 раза медленнее, чем на Linux, на том же оборудовании. Если переход на Linux невозможен, мы рекомендуем выполнить следующие настройки для Windows:
postgres.exe и папку с файлами базы данных (папка data) в исключения антивируса. В противном случае антивирус будет перехватывать каждую операцию записи, что катастрофически снизит скорость.postgresql.conf должны соответствовать объему RAM. Особое внимание уделите параметрам effective_cache_size и shared_buffers.Если инфраструктура построена исключительно на Windows, имеет смысл рассмотреть использование MS SQL Server, так как он лучше оптимизирован для этой ОС, но это повлечет дополнительные лицензионные расходы.
Платформа 1С специфична тем, что она плохо распараллеливает нагрузку одного сеанса по ядрам. Большинство алгоритмов (проведение документа, выполнение отчета) выполняются последовательно одним ядром.
Поэтому при выборе процессора для 1С мы должны руководствоваться правилом: Высокая частота важнее количества ядер.
Давайте сравним процессоры из примера:
Также стоит предостеречь от использования «мощных» мини-ПК или ноутбучных процессоров в качестве серверов. При длительной нагрузке (например, ночное перепроведение) они подвержены троттлингу — принудительному снижению частоты для защиты от перегрева. Сервер должен иметь стабильную систему охлаждения.
В примере фигурируют два типа дисков: пользовательский SSD и серверный SSD (Samsung PM883). Это ключевой момент для надежности базы данных.
Риск использования обычных SSD: Потребительские SSD используют кэш в оперативной памяти диска для ускорения записи. При внезапном отключении питания данные из этого кэша могут не успеть записаться во флеш-память. Для базы данных это означает риск разрушения структуры файла БД (corrupted database), что может привести к полной потере данных.
Преимущества Enterprise SSD: Серверные модели (как упомянутый PM883) оснащены защитой от потери питания (PLP — Power Loss Protection). Это конденсаторы, которые дают диску достаточно энергии, чтобы сбросить кэш в память при аварии. Кроме того, их ресурс записи (TBW) значительно выше, что важно для СУБД, постоянно пишущих логи транзакций.
Рекомендация: Если мы объединяем все на одном сервере, обязательно используйте серверный SSD для файлов базы данных и логов транзакций.
Скорость работы 1С напрямую зависит от того, помещаются ли «горячие» данные (индексы и часто используемые таблицы) в оперативную память. Если памяти мало, СУБД начинает читать данные с диска, что в тысячи раз медленнее.
Давайте рассчитаем потребность для 20 пользователей и базы 60 ГБ:
При 32 ГБ RAM: 32 - 6 - 10 = 16 ГБ под кэш базы. При объеме базы 60 ГБ этого может быть мало для эффективной работы, так как в кэш попадет только 25% базы. Рекомендация увеличить память до 64 ГБ является абсолютно оправданной. Это позволит держать большую часть активных данных в памяти, сводя обращения к диску к минимуму.
Автор использует Apache 2.4 на Windows. Хотя это работоспособная схема, в среде Windows «родным» веб-сервером является IIS (Internet Information Services).
Преимущества IIS для 1С на Windows:
Apache на Windows работает как обычное пользовательское приложение. Если вы консолидируете сервер, рассмотрите возможность перехода на IIS для публикации баз.
Подводя итог, для решения задачи автора и подобных ей ситуаций, мы рекомендуем следующий план действий:
Такая конфигурация обеспечит наилучшую производительность для 20 пользователей и даст запас прочности для роста баз данных в будущем.