Какую версию платформы 1С:Предприятие выбрать для стабильной работы УПП в 2024 году?

← На главную

Вопрос выбора стабильной версии платформы для 1С:Управление производственным предприятием (УПП) остается одним из самых острых для системных администраторов и разработчиков. Конфигурация УПП, построенная на «обычных формах» и использующая старые механизмы работы с блокировками, начинает вести себя непредсказуемо на свежих релизах платформы 8.3. В этой статье мы подробно проанализируем, почему новые версии (8.3.22 и выше) могут вызывать деградацию производительности, и выясним, какую версию стоит считать «золотым стандартом» для УПП в конце 2024 года.

Разбор проблемы: Почему современные платформы «тормозят» УПП?

Разберем ситуацию, с которой сталкиваются многие специалисты. При переходе на платформы версии 8.3.22, 8.3.23 и выше пользователи начинают жаловаться на «задумчивость» системы, участившиеся взаимоблокировки (deadlocks) и ошибки SDBL. Проанализируем причины этого явления:

Изменение работы с временными таблицами. Начиная с версии 8.3.22, механизмы платформы по взаимодействию с TempDB в MS SQL Server были существенно переработаны. Для современных конфигураций (ERP, КА 2.5) это дает прирост, но для УПП, работающей в режиме совместимости 8.2.13 или 8.2.16, это часто оборачивается конфликтами на уровне метаданных SQL.
Отказ от страничных блокировок. В новых релизах платформа агрессивнее навязывает свои правила управления транзакциями. Если в коде УПП не настроены управляемые блокировки, система полагается на автоматический режим СУБД, который в новых версиях платформы транслируется менее эффективно для старого кода.
Полнотекстовый поиск и фоновые задания. Проанализируем работу планировщика: в новых релизах rphost более активно потребляет ресурсы на обслуживание индекса полнотекстового поиска и управление сеансами. Для огромных баз УПП это создает паразитную нагрузку.

Выбор оптимальной версии платформы: Рекомендации экспертов

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

Ветка 8.3.21 — Последний оплот стабильности. Для большинства систем на базе УПП именно релизы ветки 8.3.21 (например, 8.3.21.1622) считаются наиболее удачными. Выясним почему: в этой ветке еще не внедрены радикальные изменения в ядро работы с SQL, которые появились в 8.3.22. Она поддерживает современные требования безопасности, работу с КЭП, но при этом корректно обрабатывает запросы старого образца.

Проблема релизов 8.3.24 и 8.3.25. Рассмотрим ситуацию с самыми свежими версиями. Несмотря на исправления багов, в них замечена критическая ошибка: невозможность загрузки конфигурации (файла .cf) в пустую базу данных для некоторых релизов УПП. Это связано с изменением структуры хранения индексов. Если вам необходимо использовать эти версии (например, для требований ЭДО), будьте готовы к «шаманству» с промежуточной конвертацией базы на версии 8.3.21.

Оптимизация MS SQL Server под нужды УПП

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

Настройка параллелизма (MAXDOP)

Для старых конфигураций крайне важно ограничить уровень параллелизма. Взаимоблокировки часто возникают, когда SQL Server пытается распараллелить тяжелый запрос от 1С. Установим параметр Max Degree of Parallelism:


-- Установка MAXDOP в значение 1 для исключения параллельных планов, 
-- вызывающих блокировки в УПП
EXEC sys.sp_configure N'show advanced options', N'1';
RECONFIGURE;
EXEC sys.sp_configure N'max degree of parallelism', N'1';
RECONFIGURE;

Параметр Legacy Cardinality Estimation

Проанализируем ситуацию с планами запросов. Новые версии SQL Server используют современный оценщик стоимости запросов, который иногда ошибается на структурах данных УПП. Мы рекомендуем включить режим совместимости со старым оценщиком в свойствах базы данных (флаг Legacy Cardinality Estimation). Это часто «лечит» внезапные тормоза отчетов, которые раньше летали.

Регламентные операции

Не забудем про обязательный минимум, который должен выполняться ежедневно. Посмотрим на список необходимых процедур:

Обновление статистики: Платформа 1С очень чувствительна к актуальности статистики SQL.
Очистка процедурного кэша: Помогает, если сервер «задумался» из-за неоптимального плана, застрявшего в памяти.
Дефрагментация и реиндексация: Для УПП с ее огромными таблицами движений (Регистры бухгалтерии, Регистры накопления) это критично.


-- Пример команды для очистки процедурного кэша при резком падении производительности
DBCC FREEPROCCACHE;
-- Обновление статистики по всей базе данных
EXEC sp_updatestats;

Борьба с ошибками SDBL и блокировками в коде

Выясним причину возникновения ошибок SDBL при обмене данными или проведении документов. Часто это связано с тем, что новые платформы более строго проверяют целостность структуры таблиц. Если вы столкнулись с такой проблемой на релизах выше 8.3.22, попробуйте следующее:

Выполните Тестирование и исправление с включенными опциями «Реорганизация таблиц» и «Сжатие таблиц».
Проверьте наличие дублей в индексах на уровне СУБД (иногда возникают при аварийном завершении реструктуризации).
Если проблема в блокировках при проведении, проанализируем возможность перевода конкретного документа на Управляемые блокировки. Не обязательно переписывать всю УПП — достаточно оптимизировать самые нагруженные узлы (например, РеализацияТоваровУслуг или ТребованиеНакладная).

Рассмотрим пример кода для установки управляемой блокировки в модуле объекта при проведении:


Блокировка = Новый БлокировкаДанных;
ЭлементБлокировки = Блокировка.Добавить("РегистрНакопления.ЗаказыПокупателей");
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
ЭлементБлокировки.УстановитьЗначение("Организация", Организация);
Блокировка.Заблокировать();

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

Подведем итоги

Проанализировав текущую ситуацию, мы приходим к следующим выводам. Если ваша цель — максимальная стабильность без лишних трудозатрат, оставайтесь на платформе 8.3.21.1622. Это наиболее сбалансированное решение для УПП в 2024 году.

Если же внешние обстоятельства (требования законодательства, обновление ЭДО) вынуждают вас перейти на 8.3.24/8.3.25, обязательно проведите предварительную настройку SQL Server (MAXDOP, Legacy CE) и будьте готовы к точечной оптимизации кода в местах возникновения блокировок. Помните, что простое наращивание мощностей сервера («железа») редко решает проблемы производительности УПП, так как корень бед обычно кроется в логических ожиданиях и неоптимальных планах запросов в режиме совместимости.