← На главную

При переходе на новую версию 1С:Комплексная автоматизация (КА2), особенно в высоконагруженных системах с большим количеством пользователей (более 300), многие администраторы и разработчики сталкиваются с серьезными проблемами производительности, несмотря на использование мощного современного оборудования. Частой причиной таких проблем становится неоптимальная настройка кластера серверов 1С, в частности, распределение пользовательских соединений между рабочими процессами (rphost). В этой статье мы подробно разберем, как решить эту проблему и значительно улучшить скорость работы системы 1С.

Настройка количества соединений на рабочий процесс (rphost)

Изначальная гипотеза, что возможность гибко управлять количеством соединений на один рабочий процесс доступна только в КОРП-лицензиях, оказалась ошибочной. Эта ключевая настройка доступна и для ПРОФ-лицензий, что является отличной новостью для многих компаний. Давайте рассмотрим подробнее, как эта настройка влияет на производительность и как ее применить.

Суть проблемы: В конфигурации по умолчанию или при неоптимальных настройках, один рабочий процесс rphost может обслуживать слишком большое количество пользовательских соединений (например, 128 и более). Хотя 1С и умеет распараллеливать потоки внутри одного rphost, слишком большая нагрузка на один процесс приводит к "зависаниям" и замедлениям работы всей системы. Процесс rphost становится "узким горлом", даже если сервер баз данных (SQL) и само оборудование не перегружены.

Решение: Уменьшение допустимого количества соединений на один рабочий процесс rphost. Это приводит к тому, что при достижении установленного лимита запускаются дополнительные рабочие процессы rphost. Каждый из них будет обслуживать меньшее количество соединений, что улучшает распределение нагрузки, повышает стабильность и сокращает время реакции на запросы.

Как настроить:

1. Откройте консоль управления серверами 1С Предприятия.
2. Перейдите в свойства рабочего сервера или кластера.
3. Найдите настройку "Количество соединений на процесс" или аналогичную.
4. Установите меньшее значение. Для высоконагруженных систем (300+ активных сеансов), рекомендуется начинать эксперименты со значениями в диапазоне 15-20 соединений на процесс. Однако, оптимальное число может варьироваться от 64 до 128 в зависимости от конкретного оборудования и конфигурации.
5. Важно: Проведите тестирование с различными значениями. Оптимальное количество соединений на рабочий процесс напрямую зависит от характеристик вашего оборудования (процессора, памяти), а также специфики используемой конфигурации и нагрузки. Мы рекомендуем методом перебора найти то значение, при котором время реакции системы будет наименьшим.

Результат: После применения этой настройки многие пользователи отмечают существенное улучшение производительности — "как небо и земля". Система становится намного более отзывчивой, а зависания значительно сокращаются.

Комплексный подход к оптимизации производительности 1С

Несмотря на то, что настройка количества соединений на процесс может дать быстрый и заметный эффект, для достижения максимальной производительности и стабильности в долгосрочной перспективе требуется комплексный подход. Рассмотрим другие важные аспекты.

Анализ производительности и диагностика

Прежде чем приступать к изменениям, важно точно определить, где находятся "узкие места".

1. Использование журнала регистрации (ТЖ): Мы рекомендуем использовать событие ТЖ CALL в журнале регистрации 1С. Это позволяет отследить самые долгие вызовы сервера и точно определить, какие именно операции работают дольше всего. Такой анализ поможет нацелиться на наиболее критичные участки кода или функционала.
2. Мониторинг счетчиков производительности: Всегда проверяйте стандартные счетчики производительности операционной системы. Обратите внимание на:
   • ЦПУ: Если ЦПУ простаивает или отдельные ядра нагружены на 100%, это может указывать на медленные однопоточные запросы или неэффективное распределение нагрузки.
   • Оперативная память (RAM): Мониторьте свободную память. Ее нехватка вынуждает систему использовать жесткий диск для временного хранения, что критически замедляет работу.
   • Диски: Особое внимание уделите нагрузке на диски со стороны rphost и SQL-сервера (скорость чтения/записи, IOPS). Активный обмен с дисками может быть причиной тормозов.
3. Центр управления производительностью (ЦУП): Для глубокого анализа и выявления узких мест в коде, блокировок и других проблем, используйте "Центр управления производительностью" (ЦУП). Он позволяет собирать детальную информацию о проблемах и их влиянии на производительность.

Особенности лицензий ПРОФ и КОРП

Хотя мы выяснили, что настройка количества соединений на процесс доступна для ПРОФ-лицензий, важно понимать, что между ПРОФ и КОРП лицензиями есть другие существенные различия, которые могут быть критичны для очень крупных и высоконагруженных систем.

1. Ограничения ПРОФ-лицензий: Лицензии ПРОФ предназначены для информационных баз, где одновременно работает не более 500 сеансов пользователей и/или используется не более 12 ядер процессора. При превышении этих лимитов функциональность платформы уровня КОРП может быть недоступна или использоваться некорректно, что приведет к проблемам производительности и стабильности.
2. Расширенный функционал КОРП: КОРП-лицензии снимают вышеуказанные ограничения по количеству одновременно работающих сеансов и используемых ядер. Они предоставляют расширенный функционал для управления кластером серверов, включая:
   • Более гибкое управление распределением нагрузки по рабочим серверам в разрезе информационных баз, видов клиентских приложений и фоновых заданий.
   • Возможность управлять параметрами, такими как безопасный уровень расхода памяти в рамках одного вызова.
   • Настройка количества информационных баз на процесс.
   • Контроль максимального объема памяти для каждого рабочего процесса.
   • Доступно фоновое обновление конфигурации базы данных, что минимизирует простои.

Для систем, которые стабильно превышают лимиты ПРОФ-лицензий, переход на КОРП может быть необходим для обеспечения масштабируемости и стабильности, предоставляя более тонкие инструменты управления ресурсами.

Расширенная настройка кластера серверов 1С (rphost)

Помимо количества соединений на процесс, существуют другие важные настройки кластера 1С, которые мы можем оптимизировать.

1. Оптимальное количество rphost: В 64-разрядном сервере 1С один rphost может использовать все ресурсы процессора и оперативную память. Мы рекомендуем начинать с одного рабочего процесса на сервер и увеличивать их количество при необходимости, основываясь на данных мониторинга. Слишком большое количество рабочих процессов увеличивает издержки на служебные вызовы между процессами и может снизить общую производительность системы.
2. Интервал перезапуска рабочих процессов: Для минимизации утечек памяти и фрагментации, мы рекомендуем устанавливать интервал перезапуска рабочих процессов кластера на 24 часа (86400 секунд). Настройте автоматический перезапуск рабочих процессов каждые 12-24 часа.
3. Допустимый объем памяти: Мы должны рассчитать максимальный размер памяти, занимаемой процессами rphost, и установить допустимый объем памяти, чтобы предотвратить ее перерасход. Для высоконагруженных систем рекомендуется выделять 80% оперативной памяти для рабочих процессов.
4. Режим балансировки: Для эффективного распределения нагрузки между рабочими процессами, мы рекомендуем использовать режим "По производительности". В этом режиме менеджер кластера направляет новые соединения на процесс с наименьшей загрузкой CPU и памяти.
5. Отказоустойчивость: Для обеспечения бесперебойной работы и отказоустойчивости можно настроить репликацию реестра кластера и использовать несколько серверов рабочих процессов. Рекомендуется уровень отказоустойчивости "1" или выше для автоматического переброса сеансов пользователей между процессами или серверами в случае сбоя.

Оптимизация кода и конфигурации

Часто главной причиной проблем производительности является неоптимальный код. Никакие настройки сервера не исправят код, который выполняет ненужную работу или порождает избыточные блокировки.

1. Неоптимальный код: Мы должны тщательно проверять доработанные участки кода, особенно если используется нестандартная конфигурация. Оптимизация кода может увеличить скорость работы в разы и десятки раз. Используйте инструменты вроде ТЖ CALL и ЦУП для выявления таких участков.
2. Управляемые формы: При переходе на управляемые формы (как в КА2), мы можем почувствовать их определенную "тормознутость" по сравнению с обычными формами толстого клиента. Для их оптимизации мы рекомендуем:
   • Минимизировать количество элементов на форме.
   • Выключать неиспользуемый функционал.
   • Запрещать пользователям менять настройки форм, которые могут приводить к медленной работе.
   • Стремиться к тому, чтобы формы открывались быстро, желательно за полсекунды.
3. Оптимизация отчетов: Медленная работа отчетов (особенно больших, за 20 тыс. строк) часто вызвана неоптимальными SQL-запросами, отсутствием нужных индексов, большими объемами данных без архивации или ошибками в механизме СКД. Мы рекомендуем:
   • Сокращать период формирования отчетов.
   • Оптимизировать запросы к базе данных.
   • Проверять пользовательские настройки отчетов, которые могут приводить к избыточной выборке данных.
   • Использование фонового выполнения запросов позволяет запускать тяжелые отчеты без блокировки пользователей.
4. Регламентные и фоновые задания: Некоторые регламентные и фоновые задания могут сильно нагружать систему. Мы должны регулярно проверять их и отключать те, которые не являются критически важными, или переносить их выполнение на наименее нагруженное время.
5. Динамические списки: При изменении запроса для динамического списка производительность может резко ухудшиться. Запрос должен быть максимально простым, особенно в сочетании с механизмом РЛС (Разграничение прав доступа на уровне записей).
6. Права пользователей: Избыточные права пользователей могут влиять на скорость открытия списков документов в управляемых формах, так как система тратит время на проверку доступности множества объектов.

Оптимизация серверной инфраструктуры

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

1. Разделение ролей серверов: Для высоконагруженных систем мы настоятельно рекомендуем разделять сервер баз данных (SQL Server, PostgreSQL) и сервер приложений 1С на отдельные физические или виртуальные машины. Это позволяет оптимально распределить ресурсы и предотвратить взаимное влияние нагрузок. При количестве пользователей менее 100 иногда допустимо совмещать эти роли на одном сервере с использованием технологии Shared Memory для увеличения быстродействия.
2. Требования к оборудованию:
   • Диски: Для SQL-сервера критична высокая скорость дисков в МБ/сек (скорость чтения) и IOPS (скорость отклика). SSD-накопители значительно улучшают производительность. Мы рекомендуем использовать NVMe SSD для максимальной скорости.
   • Оперативная память (RAM): SQL Server "любит" оперативную память. Мы рекомендуем выделять не менее 2/3 от размера базы данных для RAM сервера SQL. В идеале объем оперативной памяти должен быть равен или превышать суммарный объем всех баз. Нехватка RAM вынуждает систему использовать жесткий диск для временного хранения, что замедляет работу.
   • Процессор: Слабый процессор может ограничивать скорость выполнения операций. Нагрузка на одно ядро CPU на 100% может указывать на медленные однопоточные запросы, которые процессор не может распараллелить.
3. Сетевое взаимодействие: Размещение всех компонентов 1С (сервер БД, сервер 1С, сервер лицензий, терминальная ферма) близко друг к другу с низкой задержкой сети является критически важным фактором производительности. Задержки в сети могут сильно влиять на скорость работы, особенно с сервером лицензий.
4. Терминальный доступ: Для большого количества пользователей терминальный доступ может быть эффективным. Мы рекомендуем не более 50 пользователей на узел терминального сервера, чтобы избежать проблем с контекстными переключениями процессора. Профили пользователей на терминальном сервере также должны храниться на быстрых дисках.

Обслуживание баз данных

Регулярное обслуживание базы данных SQL также играет ключевую роль в поддержании высокой производительности.

1. Свертка базы данных: Регулярная свертка базы данных за пройденные периоды может значительно уменьшить ее размер и увеличить скорость работы, особенно если база хранит данные за много лет. Это особенно актуально для больших баз КА2.
2. Тестирование и исправление: Мы должны регулярно проводить тестирование и исправление информационной базы средствами 1С с реиндексацией таблиц и проверкой логической целостности. Это помогает устранять ошибки и улучшать производительность СУБД.
3. Сжатие базы в SQL: SQL Server позволяет физически уменьшать размер базы. Однако, мы должны делать это осторожно, так как это может привести к фрагментации. Рекомендуется выполнять сжатие после удаления большого количества данных и последующей реорганизации/перестроения индексов.
4. Индексы: Отсутствие необходимых индексов в базе данных может быть основной причиной медленной работы отчетов и сложных запросов. Мы должны регулярно анализировать план выполнения запросов и создавать или перестраивать отсутствующие/неэффективные индексы.

Заключение

Увеличение производительности 1С:Комплексная автоматизация в высоконагруженной среде — это многогранный процесс, который требует системного подхода. Мы выяснили, что даже простая настройка количества соединений на рабочий процесс rphost в ПРОФ-лицензии может дать колоссальный эффект. Однако, для достижения максимальной и стабильной производительности, мы рекомендуем всегда начинать с диагностики, затем оптимизировать настройки кластера и оборудования, и, что критически важно, не забывать о постоянной оптимизации кода и регулярном обслуживании базы данных. Только такой комплексный подход позволит вашей системе 1С работать быстро и стабильно при любом количестве пользователей.