← На главную

Мы рассмотрим распространенную проблему, когда кластер серверов 1С:Предприятие, казалось бы, некорректно распределяет нагрузку, оставляя более мощные серверы незагруженными, в то время как менее мощные обрабатывают большинство соединений. Вместе мы проанализируем принципы работы балансировки в 1С, выявим возможные причины такого поведения и предложим шаги для эффективной диагностики и решения проблемы.

Как 1С:Предприятие определяет производительность серверов?

Первое, что мы должны понять, это как система 1С:Предприятие 8.3 оценивает производительность своих рабочих серверов. В отличие от простого анализа тактовой частоты процессора или объема оперативной памяти, платформа использует внутренний механизм, называемый "эталонным вызовом". Это специальный тест, который измеряет время выполнения типовых операций, включающих в себя не только процессорные вычисления, но и файловые операции, сетевое взаимодействие и обращение к базе данных.

На основании результатов этого эталонного вызова система формирует показатель "доступной производительности" или "средней производительности" для каждого рабочего сервера. Менеджер кластера (rmngr) использует эти данные для выбора наименее загруженного рабочего процесса (rphost) при установке нового клиентского соединения. Таким образом, если в консоли кластера мы видим, что сервер, который по нашим субъективным оценкам мощнее, имеет меньший показатель производительности, значит, кластер считает его менее эффективным для своих задач. Именно это и произошло в нашем случае, где "менеджер кластера" с мощным железом имел "дост. производ. 60", а "рабочий сервер" со слабой начинкой - "среднюю производ. 140".

Факторы, влияющие на реальную производительность рабочего сервера 1С

Давайте подробно рассмотрим, какие факторы, помимо номинальных характеристик CPU и RAM, могут значительно влиять на "доступную производительность", определяемую 1С:

1. Дисковая подсистема: Это один из наиболее критичных аспектов. Скорость дисковой подсистемы, особенно для сервера СУБД и для временных файлов 1С на рабочих серверах, является частым "бутылочным горлышком". Даже самые быстрые процессоры и большой объем ОЗУ будут простаивать, если операции ввода/вывода (IOPS) выполняются медленно. Важны такие параметры, как IOPS, время отклика (Latency) и тип RAID-массива. Мы рекомендуем использовать быстрые SSD-диски, размещая на них как системные разделы, так и папки с временными файлами 1С и кэшем.
2. Сетевая инфраструктура: Скорость и стабильность сетевого соединения между серверами кластера 1С, а также между кластером 1С и сервером СУБД, имеют решающее значение. Высокие задержки или недостаточная пропускная способность сети могут замедлять синхронизацию сеансов, передачу данных и распределение задач. Мы советуем использовать выделенный канал с пропускной способностью 10 Гбит/с и проверять настройки Jumbo Frames для оптимизации сетевого трафика. Убедитесь, что все серверы находятся в одной подсети и используют порты с одинаковой высокой скоростью.
3. Конфигурация СУБД: Настройки системы управления базами данных (СУБД) сильно влияют на производительность 1С. Например, для MS SQL Server или PostgreSQL существуют специфические параметры, такие как shared_buffers, work_mem, max_connections, которые требуют тщательной оптимизации. При размещении 1С и СУБД на одном сервере (что не наш случай, так как СУБД на отдельном сервере), использование Shared Memory в клиент-серверном варианте с SQL может существенно увеличить быстродействие.
4. Оптимизация кода конфигурации 1С: Часто причиной низкой производительности является неэффективный код в самой конфигурации 1С. Медленные запросы, отсутствие или некорректная индексация таблиц объектов, а также общий программный код могут создавать нагрузку, которая не может быть компенсирована никаким "железом".
5. Параметры электропитания: Настройки операционной системы, особенно схемы управления питанием, могут неожиданно влиять на производительность процессора, снижая его тактовую частоту в режиме простоя или при недостаточной нагрузке, что приводит к заниженным результатам эталонного вызова. Мы рекомендуем установить схему питания на "Высокая производительность".
6. Виртуализация: Если серверы 1С развернуты на виртуальных машинах, то правильное распределение ресурсов (ядер CPU, ОЗУ, дисковых ресурсов) между виртуальными машинами 1С и СУБД критично. Убедитесь, что нет "переподписки" ресурсов, и виртуальная среда предоставляет достаточные ресурсы без задержек.
7. Несоответствие реальных и заявленных характеристик: Как показала дискуссия, иногда заявленные характеристики (например, количество ядер CPU) могут не соответствовать действительности, что может вводить в заблуждение относительно ожидаемой производительности. Всегда проверяйте спецификации оборудования.

Особенности балансировки нагрузки в 1С 8.3 ПРОФ

Важно отметить, что в версии 1С:Предприятие 8.3 ПРОФ возможности по управлению балансировкой нагрузки несколько ограничены по сравнению с версией КОРП. Например, параметр "Режим распределения нагрузки" (по производительности или по доступной памяти) доступен для настройки только в лицензии уровня КОРП. По умолчанию, менеджер кластера в версии ПРОФ будет выбирать процесс с наименьшей загрузкой CPU и памяти, основываясь на своей внутренней оценке производительности, о которой мы говорили выше.

Кластер серверов 1С может работать как с одним, так и с несколькими рабочими процессами на каждом сервере, обслуживая подключения клиентов на основе анализа и прогнозирования загруженности. Если мы наблюдаем, что новый мощный сервер не используется, это прямое следствие того, что 1С считает его менее производительным по результатам эталонного вызова, независимо от наших ожиданий.

Диагностика и устранение проблем с балансировкой

Чтобы выяснить, почему ваш мощный сервер не используется и как исправить ситуацию, мы предлагаем выполнить комплексную диагностику:

1. Сбор и анализ данных о загрузке оборудования:

   Начните с тщательного мониторинга. Мы должны собирать данные о загрузке CPU, объеме используемой и доступной RAM, интенсивности дисковых операций (IOPS, Latency), а также пропускной способности и задержках в сети на всех задействованных серверах: менеджере кластера 1С, рабочих серверах 1С и сервере СУБД. Используйте встроенные средства ОС (например, "Монитор ресурсов" в Windows, htop/iostat в Linux) или специализированные системы мониторинга.

2. Тестирование производительности компонентов:
   • CPU-Z bench (single thread): Для оценки производительности отдельных ядер процессоров. Мы выполним этот тест на обоих рабочих серверах (менеджере кластера и рабочем сервере) и внимательно понаблюдаем за тем, как ведет себя частота процессора во время теста. Низкие результаты могут указывать на проблемы с настройками электропитания или другие аппаратные ограничения.
   • CrystalDiskMark bench 4k: Мы протестируем дисковую подсистему на обоих серверах, уделяя особое внимание производительности операций случайного чтения/записи блоками 4K. Эти операции наиболее показательны для работы СУБД и 1С.
3. Проверка сетевой инфраструктуры:
   • Ping с большим размером пакета: Мы выполним команду ping -l 8000 с клиентских машин до обоих серверов 1С, а также с серверов 1С до сервера СУБД. Это поможет выявить сетевые задержки и нестабильность соединения.
   • Tracert: Для анализа маршрута пакетов и выявления узких мест в сети мы используем команду tracert с тех же точек.
4. Тестирование производительности 1С:
   • Тест Гилева (Gilev's test): Этот широко используемый инструмент позволит нам оценить производительность всей серверной части системы 1С в условных единицах. Мы можем выполнить тест, принудительно направляя соединения на каждый из рабочих серверов, чтобы сравнить их реальную производительность с точки зрения 1С. Это поможет нам сравнить различные конфигурации и выявить "узкие места".
   • Собственное тестирование: При необходимости, мы можем разработать небольшой регламентный тест, который будет выполнять типовые для вашей конфигурации операции, чтобы более точно оценить производительность каждого рабочего процесса.
5. Настройка кластера 1С:
   • Интервал перезапуска рабочих процессов: Мы рассмотрим настройки автоматического перезапуска процессов rphost. Регулярный перезапуск помогает минимизировать негативные последствия фрагментации и утечек памяти. Рекомендуется связывать частоту перезапуска с технологическим циклом информационных баз (например, каждые 24 часа).
   • Допустимый объем памяти для рабочих процессов: Мы установим ограничения на объем памяти, доступной для рабочих процессов, чтобы предотвратить их перерасход и утечки памяти.
   • Уровень отказоустойчивости: Если отказоустойчивость является приоритетом, мы определим необходимое количество серверов, одновременный выход из строя которых не приведет к аварийному завершению сеансов пользователей. Для обеспечения базовой отказоустойчивости требуется как минимум два центральных сервера.
   • Синхронизация времени: Убедимся, что время между всеми узлами кластера синхронизировано. Рассинхронизация времени более 5 секунд может приводить к ошибкам и некорректной работе. Рекомендуется настроить NTP-сервер на всех узлах.
   • Открытие портов в фаерволе: Мы проверим, что все необходимые порты открыты в фаерволах. Для кластера 1С это обычно TCP порты 1540-1541, для MS SQL Server - 1433, для PostgreSQL - 5432.
6. Работа с СУБД:

   Мы проведем регулярное обслуживание базы данных: проверим целостность, выполним оптимизацию индексов и таблиц, а также обновим статистику. Эти операции критичны для поддержания высокой производительности 1С.

В заключение, мы должны помнить, что простое добавление "железа" не всегда является решением проблемы низкой производительности. Часто причина кроется в неоптимальных настройках, ошибках в коде конфигурации или скрытых "узких местах" в инфраструктуре. Только комплексный подход к диагностике, основанный на анализе всех влияющих факторов, поможет нам добиться эффективной работы кластера 1С:Предприятие и правильной балансировки нагрузки.