С выходом новых релизов платформы 1С:Предприятие 8.3 многие технические специалисты и администраторы баз данных замечают постепенное снижение быстродействия в типовых операциях. Рассмотрим подробнее результаты синтетических тестов и проанализируем причины деградации производительности при переходе с ранних версий (например, 8.3.8) на более современные (8.3.18 и выше). В рамках данной статьи мы разберем влияние аппаратной части, настроек совместимости и системных патчей на общую скорость работы системы.
Проанализируем результаты тестирования на файловых версиях платформы в идентичных аппаратных условиях. При выполнении операций записи и перезаписи элементов справочников наблюдается четкая тенденция к замедлению. Рассмотрим средние показатели задержек для разных версий платформы:
Выясним причину такой разницы: суммарная деградация на операциях записи между версиями 8.3.8 и 8.3.18 достигает порядка 25-28%. Это напрямую влияет на показатели популярных бенчмарков (например, тест Гилева), где итоговый балл снижается просто из-за обновления платформы при неизменном железе. Основная нагрузка в новых версиях ложится на механизмы управления транзакциями и проверки целостности данных.
Одной из ключевых находок в ходе тестирования стало влияние свойства РежимСовместимости. Посмотрим на пример разницы в производительности на платформе 8.3.18.1363 при изменении этого параметра:
Разберем, почему так происходит. При отключении режима совместимости платформа начинает использовать новые механизмы работы с базой данных и менеджером блокировок. В новых версиях 1С часто меняется структура индексов в таблицах СУБД для оптимизации чтения сложных отчетов, однако это создает дополнительный оверхед при обновлении индексных деревьев во время записи элементов. Рекомендуется тщательно тестировать переход на режим "НеИспользовать" в высоконагруженных системах.
Важным фактором замедления 1С на современных процессорах Intel является микрокод, выпущенный после 2018 года для устранения уязвимостей Spectre и Meltdown. Эти исправления критически замедляют системные вызовы (syscalls), которые 1С использует при каждом обращении к файловой базе или СУБД.
Проанализируем ситуацию на примере процессора i7-2600k. При разгоне до 5 ГГц он показывает результаты, сопоставимые со стоковыми современными процессорами, однако значительно проигрывает им в операциях вызова сервера с контекстом. На современных системах 1С оптимизирует код под инструкции AVX2, но общие задержки переключения между режимом пользователя и режимом ядра (Kernel/User mode) в Windows "съедают" до 20-30% чистой производительности в OLTP-сценариях.
Рассмотрим результаты замеров времени вызова сервера. В новых платформах наблюдается увеличение времени на передачу данных между клиентом и сервером. Посмотрим на типовые замеры:
// Пример замера выполнения на сервере без контекста
// Платформа 8.3.18
Вызов сервера без контекста: 187 мсек
Вызов сервера с контекстом: 344 мсек
Вызов сервера с данными: 1 078 мсек
Для минимизации задержек необходимо придерживаться следующих правил:
&НаСервереБезКонтекста.ДанныеФормыСтруктура, если нужны только два реквизита).rphost активно общается с менеджером кластера для получения UUID, что создает дополнительные сетевые задержки даже на shared memory.Заметим, что начиная с определенных версий (ориентировочно 8.3.14+), 1С перешла на сборку платформы с использованием новых стандартов C++17 и компилятора Visual Studio 2019. Это принесло в код платформы больше проверок безопасности (защита от переполнения буфера, проверка типов runtime). Хотя это повышает стабильность системы, выполнение кода 1С (особенно интерпретация встроенного языка) получает небольшой, но стабильный "штраф" к скорости выполнения на каждой итерации цикла.
В современных версиях платформы (8.3.15+) значительно вырос объем временных файлов и кэша, создаваемого в каталоге пользователя %AppData%\Local\1C. Проанализируем влияние средств защиты:
Если папки с базой данных и кэшем не добавлены в исключения Windows Defender, то при каждой записи нового элемента справочника антивирус инициирует проверку измененных файлов БД. Из-за усложнившейся структуры файлов платформы 8.3.18+ этот процесс занимает больше времени, чем на старых версиях, создавая эффект "фризов" интерфейса.
Для сохранения приемлемой производительности на новых версиях платформы следует выполнить следующие действия:
plan_cache_mode и использование Huge Pages в Linux, так как алгоритмы планировщика запросов 1С претерпели значительные изменения.Таким образом, деградация производительности в новых версиях — это комплексная проблема, связанная с усилением мер безопасности (как на уровне компиляции кода 1С, так и на уровне микрокода процессоров) и усложнением внутренних механизмов платформы.