Переход на новые версии платформы 1С:Предприятие — это всегда ответственный шаг, который нередко сопровождается неожиданными трудностями в администрировании. В этой статье мы подробно разберем, почему после обновления на релизы 8.3.15.1830, 8.3.16.1048 и более поздние версии пользователи сталкиваются с критическим падением производительности, зависаниями системы и регулярными падениями сервера из-за нехватки оперативной памяти. Мы проанализируем техническую сторону этих проблем и предложим проверенные практические решения.
Начнем с базового, но крайне важного действия. При обновлении платформы внутренние структуры кэша могут конфликтовать со старыми файлами метаданных, сохраненными на компьютерах пользователей. Это приводит к аномальным задержкам интерфейса и зависаниям сразу после первого запуска новой платформы. Практика показывает, что удаление временных файлов решает существенную часть локальных проблем.
Для гарантированной очистки выполним следующие шаги:
%LOCALAPPDATA%\1C\1Cv8%APPDATA%\1C\1Cv8Agent 1C:Enterprise.Также полезно использовать параметр запуска /ClearCache в дополнительных параметрах запуска информационной базы для автоматической очистки кэша при старте клиентского приложения.
Одной из наиболее частых причин падения серверной части 1С на новых платформах является использование 32-разрядного сервера (x86). Современные типовые конфигурации (такие как ERP, Комплексная автоматизация или Управление торговлей) стали чрезвычайно требовательными к ресурсам.
Разберем, почему происходят аварийные завершения процессов:
rphost физически не может адресовать более 2 ГБ оперативной памяти (в редких случаях при настройке операционной системы — до 4 ГБ).8.3.15.1830) разработчики изменили механизмы работы с динамической памятью. Потребление ОЗУ процессами незначительно выросло, но для 32-битных процессов этот «прирост» оказался критическим порогом.rphost моментально упирается в лимит памяти и падает, аварийно завершая сеансы всех подключенных к нему пользователей.Единственным надежным и стратегически верным решением в данном случае является переход на 64-разрядный сервер 1С:Предприятие. Лицензия x64 снимает ограничения на адресацию памяти, позволяя рабочим процессам эффективно использовать весь объем ОЗУ сервера.
Начиная с платформы 8.3.15, разработчики изменили политику распределения функций между лицензиями уровней ПРОФ и КОРП. В частности, контроль за расходом памяти рабочими процессами был существенно ограничен для владельцев лицензий ПРОФ.
Однако мы можем облегчить жизнь серверу, используя доступные настройки кластера:
Уменьшая количество соединений на один процесс rphost, мы заставляем сервер 1С автоматически плодить новые рабочие процессы. Это распределяет нагрузку: если один из процессов заполнит свои 2 ГБ памяти и упадет (в случае x86), пострадает лишь небольшая группа пользователей, а не вся компания. Для x64 серверов это также полезно, так как снижает фрагментацию памяти внутри отдельного процесса.
Разработчики и администраторы часто сталкиваются с тем, что при попытке сравнения, объединения или обновления конфигураций на новых платформах Конфигуратор внезапно «схлопывается» без каких-либо ошибок. Причина кроется в той же нехватке памяти.
Современные конфигурации в процессе компиляции метаданных требуют огромных объемов адресного пространства. Если вы используете 32-разрядную версию платформы для разработки, Конфигуратор неизбежно упадет. Решением является обязательная установка и использование 64-разрядного тонкого и толстого клиента 1С на рабочих местах администраторов и разработчиков.
Если ваши базы работают в файловом варианте, обратите внимание на известную проблему релиза 8.3.16.1048. В оптимизаторе встроенной СУБД этой версии была допущена ошибка построения планов запросов. При выполнении сложных левых соединений или запросов с виртуальными таблицами СУБД игнорировала существующие индексы и переходила к полному сканированию таблиц (Full Table Scan). Это приводило к тому, что простейшие операции выполнялись минутами. При возникновении подобных симптомов рекомендуется обновить платформу до более стабильных последующих релизов 8.3.16 или 8.3.17.
Проанализируем техническую изнанку платформы под глубокой нагрузкой. С помощью системных профайлеров (например, VerySleepy) можно зафиксировать, что при высокой многопоточности стандартная системная куча Windows/Linux начинает испытывать жесткие блокировки.
Процессы rphost написаны на C++ и активно используют стандартные функции выделения и освобождения динамической памяти (malloc и free). Поскольку стандартная системная куча часто работает в один поток, возникает точка конкуренции за ресурс с блокировками и ожиданием системных вызовов.
Для серверов под управлением ОС Linux эту проблему можно эффективно решить без вмешательства в код платформы путем подмены стандартного распределителя памяти на альтернативный (например, mimalloc от Microsoft или tcmalloc от Google). Эти библиотеки оптимизированы для многопоточной работы и практически полностью исключают взаимные блокировки потоков.
Рассмотрим пример настройки использования альтернативного аллокатора mimalloc для сервера 1С на Linux. Для этого перед запуском службы агента необходимо переопределить переменную среды LD_PRELOAD:
# Открываем файл конфигурации службы 1С (путь может отличаться в зависимости от дистрибутива)
# Например: /etc/sysconfig/srv1cv83 или /etc/default/srv1cv83
# Добавляем строку предзагрузки библиотеки mimalloc
export LD_PRELOAD=/usr/local/lib/libmimalloc.so
# Перезапускаем службу сервера 1С
systemctl restart srv1cv83
Использование этого метода позволяет снизить фрагментацию оперативной памяти, устранить микрозависания рабочих процессов под высокой нагрузкой и повысить общую производительность системы в среднем на 10-15%.
Если переход на x64 выполнен, параметры процессов настроены, но система продолжает работать медленно, необходимо провести комплексную оптимизацию на уровне базы данных СУБД SQL.
Выполним обязательный регламентный минимум:
.lgd). При больших объемах записей этот файл начинает жутко тормозить транзакции базы данных. Рекомендуется настроить регулярное сокращение ЖР, архивирование старых записей и хранение журнала на быстрых SSD-накопителях.Max Degree of Parallelism (MAXDOP) = 1, настроим ограничение максимального объема памяти для SQL-сервера, чтобы он не конфликтовал за ресурсы с процессами 1С на одном сервере).Соблюдение этих рекомендаций в комплексе позволит полностью устранить негативные последствия обновления платформы, обеспечит стабильность и максимальную скорость работы пользователей в программах 1С:Предприятие.