Проблема низкой производительности и нестабильности платформы 1С:Предприятие 8.3 — одна из самых обсуждаемых среди системных администраторов и программистов. Особенно остро этот вопрос встал с выходом ветки 8.3.18, где многие пользователи столкнулись с существенными задержками в работе интерфейса и серверных процессов. Разберем детально, почему версия 8.3.18.1208 часто вызывает нарекания, и проанализируем, какие альтернативные релизы можно считать «золотым стандартом» для высоконагруженных систем.
Прежде чем принимать решение о переходе, проанализируем ситуацию, сложившуюся с релизом 8.3.18.1208. Пользователи часто жалуются на «тормоза», которые проявляются даже при наличии мощного оборудования. Выясним основные технические причины такого поведения:
rphost и rmngr. Это особенно заметно в конфигурациях 1С:ERP или ЗУП 3.1, где активно используются фоновые задания.8.3.18, разработчики 1С изменили механизмы отрисовки форм интерфейса «Такси». Это привело к увеличению сетевого трафика между клиентом и сервером. Если ваша сеть имеет задержки (высокий ping), работа в программе станет визуально медленнее.Рассмотрим стратегию выбора платформы, основанную на опыте облачного сервиса 1cfresh.com. Поскольку в этом сервисе работают тысячи баз данных с колоссальной нагрузкой, специалисты фирмы «1С» устанавливают туда только самые проверенные сборки. Посмотрим на статистику: долгое время, даже после выхода 18-й и 19-й веток, облачный сервис оставался на 8.3.17.2498 и 8.3.17.2206. Это явный индикатор того, что ветка 8.3.17 обладает большей стабильностью серверной части.
Если ваше руководство категорически против «даунгрейда» до 8.3.17.1851, аргументируйте необходимость перехода на последние сборки 17-й ветки (например, 8.3.17.2760), которые включают в себя важные исправления безопасности.
Важно помнить, что обсуждение стабильности любого релиза ниже определенного порога потеряло смысл в конце 2022 года. Рассмотрим ситуацию с критической уязвимостью. Для обеспечения работоспособности систем необходимо использовать сборки не ниже следующих:
Использование обсуждаемой версии 8.3.18.1208 в современных условиях недопустимо не только из-за производительности, но и по соображениям безопасности.
Проанализируем более современные альтернативы для тех, кто не хочет возвращаться на 17-ю платформу. Ветку 8.3.19 часто называют переходной и проблемной (зафиксировано много падений кластера), поэтому ее мы пропустим. Посмотрим на 8.3.21 и 8.3.22:
8.3.21.1622 хорошо показывают себя в связке с тяжелыми конфигурациями.8.3.22.1704) «новой 8.3.15». Она вобрала в себя исправления ошибок предыдущих трех веток и демонстрирует высокую предсказуемость серверной части.Разберем ситуацию, когда платформа 1С работает в связке с SQL Server 2012. Учтем, что современные платформы (начиная с 8.3.20) оптимизированы под более новые стандарты SQL. Если вы используете старую СУБД, механизмы построения планов запросов 1С могут работать неэффективно. Проанализируем настройки:
При использовании старых версий SQL Server рекомендуется проверить параметр Legacy Cardinality Estimation. Иногда принудительное включение старого оптимизатора запросов на уровне БД помогает убрать «тормоза» после обновления платформы. В консоли SQL это выглядит примерно так:
ALTER DATABASE [Имя_Вашей_Базы]
SET COMPATIBILITY_LEVEL = 110; -- Соответствует SQL Server 2012
GO
ALTER DATABASE SCOPED CONFIGURATION SET LEGACY_CARDINALITY_ESTIMATION = ON;
GO
Выясним, что еще, кроме смены версии платформы, поможет ускорить работу системы, если в базе одновременно работают более 100 человек:
rphost и sqlservr.rphost потреблять всю память сервера. Установите лимиты: "Безопасный расход памяти за один вызов" и "Критический объем памяти".Прежде чем устанавливать новую платформу на рабочий сервер, выполним следующие шаги:
Развернем тестовый контур, полностью идентичный рабочему. Используем замер производительности для ключевых операций (например, проведение документа «Реализация товаров и услуг» или формирование оборотно-сальдовой ведомости). Сравним время выполнения на текущей платформе 8.3.18.1208 и на целевой (например, 8.3.22.1704).
Важный нюанс: Если вы используете хранилище конфигурации, помните о баге в 18-й ветке, который может приводить к его порче. Перед любыми манипуляциями обязательно делайте резервную копию не только баз данных, но и файлов хранилища.
Подведем итоги нашего анализа. Если ваша цель — максимальная стабильность и вы готовы к небольшому откату назад по функционалу, выбирайте последние релизы ветки 8.3.17. Если же конфигурация требует новых возможностей платформы или вы хотите использовать современные механизмы оптимизации, наиболее надежным вариантом на данный момент является переход на ветку 8.3.22. Избегайте «сырых» промежуточных релизов (8.3.18.1208, 8.3.19.х) и всегда следите за рекомендациями техподдержки в части обновлений безопасности.