← На главную
Переход на новые версии платформы 1С:Предприятие 8.3 часто становится вынужденной мерой из-за требований актуальных релизов типовых конфигураций. Однако администраторы и разработчики нередко сталкиваются с ситуацией, когда сразу после перехода на новую ветку наблюдается деградация скорости, зависание процессов кластера rphost или чрезмерная загрузка аппаратных ресурсов. Разберем по шагам правила выбора надежного релиза платформы, методику корректного обновления и ключевые действия для устранения проблем с быстродействием.
Критерии выбора стабильного релиза платформы
Проанализируем стратегию выбора сборки платформы для продуктивного контура, чтобы свести к минимуму риск столкновения с критическими ошибками:
- Правило нескольких итераций: Не рекомендуется переводить рабочие базы на первые 2–3 сборки новой функциональной ветки (например, первые релизы новой ветки традиционно содержат «детские болезни» нового функционала). Оптимально дождаться этапа стабилизации, когда ветка переходит в режим сервисного сопровождения с исправлением ошибок.
- Оценка периодичности выхода сборок: Обратим внимание на интервалы публикации обновлений. Если после выхода релиза в течение нескольких недель не выпускаются экстренные патчи и хотфиксы, вероятность его стабильной работы значительно выше. Если же сборка заменяется буквально через несколько дней, это сигнализирует об исправлении критических сбоев.
- Разделение веток по назначению: В жизненном цикле платформы чередуются этапы внедрения масштабной новой функциональности и этапы оптимизации и стабилизации кода. Для продуктивных систем критической важности предпочтительнее выбирать релизы из уже устоявшихся веток с максимальным номером сборки.
Очистка служебных данных и кэша при обновлении
Одной из наиболее частых причин нестабильного поведения и падения скорости после смены релиза являются остатки устаревшего кэша конфигурации и служебных файлов. Выполним полную очистку окружения:
- Очистка кэша сеансов на стороне сервера: Служебные данные кэшируются в каталоге профиля пользователя, от имени которого запускается служба сервера 1С. Для Windows это каталоги
AppData\Local\1C\1cv8 и AppData\Roaming\1C\1cv8, а для Linux-систем — домашний каталог пользователя службы (например, /home/usr1cv82/.1cv8). Перед запуском новой службы кластера необходимо остановить службу и удалить временные папки с кэшем.
- Очистка локального кэша на клиентских машинах: На рабочих станциях пользователей также скапливается кэш метаданных предыдущих сборок. Удаление содержимого каталогов
%LocalAppData%\1C\1cv8 и %AppData%\1C\1cv8 исключает конфликты несоответствия метаданных при первом подключении к обновленному серверу.
- Удаление неиспользуемых дистрибутивов: На сервере приложений рекомендуется деинсталлировать старые неиспользуемые версии платформы во избежание конфликтов системных библиотек и некорректной регистрации компонентов кластера.
Регламентное обслуживание СУБД и баз данных
Новая версия платформы может содержать обновленные алгоритмы трансляции запросов языка 1С в команды SQL. Если оптимизатор СУБД опирается на устаревшую статистику распределения данных, он строит неоптимальные планы запросов (вместо поиска по индексам применяется полное сканирование таблиц). Выясним, какие регламентные процедуры необходимо провести сразу после обновления:
- Полное обновление статистик СУБД: Запустим обновление статистик с полным сканированием таблиц (для MS SQL Server —
UPDATE STATISTICS WITH FULLSCAN или процедура sp_updatestats, для PostgreSQL — команда ANALYZE). Это позволит СУБД корректно планировать выполнение запросов под новый транслятор платформы.
- Реиндексация таблиц: Регулярное перестроение и дефрагментация индексов устраняют фрагментацию данных и восстанавливают скорость индексного поиска при интенсивной многопоточной записи.
- Реструктуризация таблиц информационной базы: Выполнение регламентного тестирования и исправления с реструктуризацией таблиц в режиме «Конфигуратор» позволяет привести физическую структуру таблиц к актуальным требованиям текущей версии платформы.
Тонкая настройка параметров кластера серверов
Рассмотрим параметры кластера 1С:Предприятия, которые защищают сервер от деградации скорости и исчерпания оперативной памяти:
- Допустимый объем памяти и интервал его превышения: Зададим порог объема памяти для рабочих процессов
rphost. При достижении заданного лимита кластер автоматически инициирует запуск нового чистого рабочего процесса и плавно переносит на него сеансы без прерывания пользовательской работы.
- Безопасный расход памяти за один вызов: Установка данного ограничения предотвращает падение серверного процесса при формировании пользователями тяжелых отчетов с бесконечной выборкой данных.
- Балансировка процессов: Настроим количество информационных баз на один процесс и максимальное число соединений, чтобы эффективно распределить нагрузку между всеми доступными ядрами процессора.
Настройка операционной системы и электропитания
Проанализируем системные параметры хоста, напрямую влияющие на отзывчивость клиент-серверного взаимодействия:
- Схема электропитания процессора: Установим в операционной системе и BIOS сервера режим «Высокая производительность» (High Performance). Это исключает задержки от динамического переключения тактовой частоты ядер при скачкообразных серверных вызовах.
- Оптимизация параметров ядра Linux: При развертывании сервера на базе Linux отключим механизм Transparent Huge Pages (THP), установив значение
never, так как динамическое выделение сверхбольших страниц памяти вызывает микрозадержки процессов rphost.
- Исключения антивирусной защиты: Добавим служебный каталог кластера
srvinfo, рабочие процессы ragent, rmngr, rphost и каталоги временных файлов в список исключений сканирования в реальном времени.
Проведение тестирования методом Side-by-Side
Чтобы исключить простои предприятия, разберем методику безопасного перехода с помощью параллельной установки кластеров:
- Установим новую версию платформы на сервер без удаления текущей рабочей версии.
- Создадим отдельный экземпляр службы кластера на нестандартном диапазоне сетевых портов (например, 2540, 2541, 2560).
- Развернем на тестовом кластере точную копию рабочей информационной базы.
- Проведем функциональное и нагрузочное тестирование типовых сценариев (проведение документов, закрытие месяца, формирование тяжелых отчетов).
- При подтверждении стабильности и корректности производительности переведем продуктивные базы на обновленную версию.