Переход со старых и проверенных временем платформ (таких как 8.2.18) на современные ветки 8.3.14, 8.3.15 и выше часто становится для администраторов и разработчиков настоящим испытанием. Вместо ожидаемого прироста производительности пользователи сталкиваются с «дампами» (аварийным завершением работы), ошибками СУБД и странным поведением интерфейса. В рамках данной статьи мы подробно разберем, почему «падает» 14-я и 15-я платформы, как бороться с ошибками дублирования таблиц и что нужно знать про новый движок отображения форм.
Одной из главных причин внезапных «дампов» при работе с обычными формами и специфическими интерфейсными решениями стал переход платформы с движка Internet Explorer на WebKit. Это произошло начиная с версии 8.3.14.1565. Рассмотрим подробнее, к чему это привело.
Многие тиражные решения и самописные конфигурации (например, на базе УТ 10.3 или продуктов 1С:БИТ) используют макеты типа HTML-документ для отображения графиков, подсказок или интеграции с внешними сервисами. Старый движок прощал многие ошибки в верстке и специфические вызовы JS. WebKit гораздо строже к синтаксису. Если программа падает в дамп при открытии формы или нажатии на кнопки внутри поля HTML, проанализируем следующие моменты:
window.external, это может вызвать крах процесса.В качестве решения рекомендуется переписывать формы, отказываясь от сложной HTML-логики, либо принудительно обновляться до ветки 8.3.16, где многие ошибки взаимодействия с новым движком были исправлены. Также полезно проверить настройки совместимости интерфейса.
При переходе на 8.3.15 (например, на популярный релиз 15.1565) многие столкнулись с ошибкой: «Для одного ссылочного кода существует более одной таблицы в базе данных». Эта проблема блокирует обновление конфигурации базы данных и делает невозможной дальнейшую разработку.
Выясним причину этого поведения. Ошибка возникает из-за некорректной работы механизма Data History (История данных) и сервиса менеджера кластера. Рассмотрим пошагово ситуацию, в которой она проявляется:
rmngr.exe кэширует последний номер таблицы.Enum1598), что вызывает конфликт SDBL.Как решить эту проблему? Экспериментальным путем выяснено, что «Тестирование и исправление» в данном случае бессильно. Помогает следующая последовательность действий: сразу после восстановления базы средствами СУБД необходимо полностью перезапустить службу сервера 1С:Предприятия. Это заставит rmngr сбросить кэш идентификаторов таблиц и инициализировать их заново на основе актуальных данных из SQL.
В ветке 8.3.14 был зарегистрирован и подтвержден критический баг (ошибка 10208437). Проанализируем ситуацию: если внутри блока Попытка ... Исключение вызывается метод ЗаписьЖурналаРегистрации, и в этот момент происходит восстановимая ошибка базы данных (например, конфликт блокировок), платформа игнорирует оператор Исключение и аварийно завершает работу.
Это объясняет, почему пользователи «отлетают» из базы в моменты высокой нагрузки. Рассмотрим пример опасного кода:
Попытка
// Какое-то действие, вызывающее блокировку
ДокументОбъект.Записать();
Исключение
// В 14-й платформе это может вызвать дамп, если база занята
ЗаписьЖурналаРегистрации("Ошибка записи", УровеньЖурналаРегистрации.Ошибка,,, ОписаниеОшибки());
КонецПопытки;
Для устранения этой проблемы рекомендуется либо избегать записи в журнал в критических секциях на 14-й платформе, либо перейти на релизы 8.3.16.869 и выше, где эта ошибка официально исправлена.
При переходе на новые платформы нельзя забывать о важном изменении в системе лицензирования, которое произошло осенью 2019 года. Платформы выше 8.3.12.1855 стали строго проверять тип лицензии (ПРОФ или КОРП).
Разберем основные ограничения для лицензий уровня ПРОФ:
Если ваша информационная база работает на мощном сервере, и вы заметили деградацию производительности после обновления, проверьте настройки кластера. На лицензиях ПРОФ теперь допустимы только дефолтные настройки. Любая попытка изменить параметры расхода памяти на процесс или количество соединений может привести к нестабильной работе или отказу системы запускать новые сеансы.
Чтобы жизнь на нетиповых конфигурациях (вроде УПП или сильно перепиленной УТ 10.3) на платформе 8.3 была возможной, выполним следующие рекомендации:
8.3.12 без крайней необходимости. Это поможет избежать сегментации памяти (segmentation fault) при отрисовке сложных элементов.snaccxt в профиле пользователя, под которым работает служба сервера..xls (вызывает дамп). Попробуйте сменить формат аттача на .pdf или .zip, если обновление платформы сейчас невозможно.Сдвинуть у ФорматированногоДокумента. В некоторых релизах 14 и 15 платформ вызов этого метода на последнем элементе гарантированно валит сессию в дамп.Подводя итог, можно сказать, что наиболее стабильной стратегией на текущий момент является либо использование проверенной ветки 8.3.12.х (если не требуются механизмы ЭДО и маркировки), либо прыжок сразу на актуальные релизы 8.3.16 и выше, минуя «переходные» и наиболее проблемные 14-ю и 15-ю ветки.