Перешли на новую версию 1С, и она зависает при проведении документов: чья вина и как решить проблему производительности

← На главную

Переход на новую конфигурацию или обновление крупного релиза 1С частенько преподносит неприятные сюрпризы в виде внезапных зависаний системы. Ситуация выглядит классически: пользователи жалуются, что при проведении документов система «намертво» замирает на 30–60 секунд, а иногда и вовсе требует принудительного завершения работы через диспетчер задач. При этом системный администратор, глядя на показатели производительности сервера, разводит руками — нагрузка на процессоры не превышает 20%, дисковая подсистема практически простаивает, а оперативная память распределена стандартным образом.

В этой статье мы подробно разберем, почему возникает подобный диссонанс между низкими показателями утилизации «железа» и реальной скоростью работы пользователей. Мы выясним, на чьей стороне находится проблема — администратора сервера или разработчиков-внедренцев, и пошагово рассмотрим методы диагностики и устранения подобных зависаний.

Выясняем причину: почему «железо» не нагружено, а 1С виснет

Для начала проанализируем ситуацию, когда общие графики производительности сервера показывают полный штиль, а пользователи не могут работать. Это ключевой симптом, указывающий на две основные системные проблемы: избыточные ожидания на блокировках СУБД и ограничение производительности одного потока процессора.

Рассмотрим подробнее каждый из этих факторов:

Очередь на транзакционных блокировках. Когда один пользователь проводит документ, платформа 1С открывает транзакцию и накладывает эксклюзивные блокировки на таблицы СУБД (например, таблицы регистров накопления или сведений), чтобы гарантировать согласованность данных. Если в этот же момент другие пользователи пытаются прочитать эти таблицы (например, открывая динамические списки документов или формируя отчеты) с помощью тяжелых, неоптимальных запросов, СУБД выстраивает их в очередь ожидания. В этот момент физическая нагрузка на диски и процессоры падает до нуля, поскольку процессы просто «спят», ожидая освобождения ресурса.
Эффект одного ядра (ядерное ограничение). Бизнес-логика проведения документов в 1С выполняется преимущественно в один поток. Если сервер оснащен многоядерными процессорами с относительно низкой тактовой частотой (например, старыми моделями процессоров Xeon с частотой около 2.6 ГГц), то выполнение сложного запроса полностью загрузит лишь одно логическое ядро. В системе с 24 потоками загрузка одного ядра на 100% отобразится в диспетчере задач как общая утилизация процессора всего в 4%. Администратор видит свободные ресурсы, хотя фактически одно ядро работает на пределе возможностей, замедляя всю операцию проведения.

Таким образом, отсутствие видимой физической нагрузки на сервер не означает отсутствие проблем с настройкой оборудования или качеством программного кода.

Шаг 1. Оптимизация и распределение оперативной памяти на сервере

Проанализируем параметры сервера, описанные в исходной теме: 48 Гб оперативной памяти, на сервере совместно работают MS SQL Server и сервер приложений 1С. При этом под нужды SQL Server выделено 43 Гб.

Выясним, почему такое распределение памяти является критической ошибкой администрирования. При ограничении SQL Server в 43 Гб операционной системе и процессам 1С остается всего 5 Гб. Служба сервера 1С:Предприятия (процессы rphost) крайне требовательна к оперативной памяти. В процессе работы пользователи открывают тяжелые отчеты, динамические списки, выполняют регламентные операции, из-за чего кэш каждого процесса rphost может разрастаться до нескольких гигабайт.

Когда операционная система понимает, что физическая память исчерпана, она начинает активно сбрасывать данные процессов 1С в файл подкачки (pagefile.sys) на диск. Это приводит к резкому падению производительности и зависанию клиентских сессий, даже если сами диски работают на SSD.

Решение: пересмотрим лимиты оперативной памяти. Для совмещенного сервера с 48 Гб RAM рекомендуется применить следующую схему распределения ресурсов:

Операционная система: зарезервируем минимум 4 Гб.
Сервер 1С:Предприятия: зарезервируем не менее 10–12 Гб (из расчета работы 30–40 пользователей и возможности запуска нескольких процессов rphost).
MS SQL Server: ограничим параметр max server memory на уровне 32–34 Гб.

Для изменения лимита памяти SQL Server выполним в среде SQL Server Management Studio (SSMS) следующий сценарий:


EXEC sys.sp_configure N'show advanced options', N'1'  RECONFIGURE WITH OVERRIDE;
GO
EXEC sys.sp_configure N'max server memory (MB)', N'34816' RECONFIGURE WITH OVERRIDE;
GO
EXEC sys.sp_configure N'show advanced options', N'0' RECONFIGURE WITH OVERRIDE;
GO

Шаг 2. Проверка системных требований и версий платформы

Обратим внимание на используемые версии ПО в рассматриваемом случае. Переход был осуществлен на конфигурацию «Управление торговлей» редакции 11.4.2.123 с использованием платформы версии 8.3.10.2561.

Проанализируем требования правообладателя. Согласно официальной документации к выпуску УТ 11.4, минимально поддерживаемой версией платформы является 8.3.10.2699, а рекомендуемой — 8.3.12.1469 и выше (в режиме совместимости с версией 8.3.10). Запуск современной конфигурации на устаревшей сборке платформы гарантированно приводит к нестабильной работе клиентских приложений, сбоям при отрисовке динамических списков в управляемых формах и утечкам памяти в процессах сервера.

Решение: силами системного администратора необходимо произвести обновление платформы 1С:Предприятие на сервере и клиентских машинах до актуального стабильного релиза (например, старших сборок веток 8.3.12 или 8.3.16, в зависимости от требований конкретного релиза конфигурации).

Шаг 3. Отключение IPv6 на уровне операционной системы

Управляемые формы платформы 1С:Предприятие 8.3 активно используют сетевые вызовы для синхронизации состояния между клиентом и сервером приложений. При активном протоколе IPv6 на серверах под управлением ОС Windows часто наблюдаются микрозадержки при разрешении сетевых имен хостов. Платформа пытается установить соединение по протоколу IPv6, получает таймаут и лишь затем переключается на стандартный IPv4. В масштабах частых мелких запросов это выливается в ощутимые зависания интерфейса.

Решение: отключим использование IPv6 в свойствах сетевого адаптера на сервере 1С, сервере СУБД и сервере терминалов (RDP). Дополнительно рекомендуется зафиксировать предпочтение IPv4 перед IPv6 через реестр Windows, установив параметр DisabledComponents со значением 0x20 в ветке реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters.

Шаг 4. Анализ неоптимального программного кода (Зона ответственности внедренцев)

Если после настройки системных параметров сервера, очистки памяти и обновления платформы зависания при проведении документов продолжаются, то проблема однозначно кроется в некачественной доработке конфигурации. Рассмотрим реальный пример неоптимального запроса, который использовался внедренцами для динамического списка журнала документов АЭ_ЖурналОперацийМФОиКПК:


ВЫБРАТЬ
    АЭ_ЖурналОперацийМФОиКПК.Ссылка КАК Ссылка,
    АЭ_ЖурналОперацийМФОиКПК.Дата КАК Дата,
    АЭ_ЖурналОперацийМФОиКПК.Проведен КАК Проведен,
    АЭ_ЖурналОперацийМФОиКПК.Организация КАК Организация,
    ВЫБОР
        КОГДА АЭ_ЖурналОперацийМФОиКПК.РучнаяКорректировка = ИСТИНА
            ТОГДА ВЫБОР
                    КОГДА АЭ_ЖурналОперацийМФОиКПК.ПометкаУдаления = ИСТИНА ТОГДА 10
                    КОГДА АЭ_ЖурналОперацийМФОиКПК.Проведен = ЛОЖЬ ТОГДА 9
                    ИНАЧЕ 8
                КОНЕЦ
        ИНАЧЕ ВЫБОР
                КОГДА АЭ_ЖурналОперацийМФОиКПК.ПометкаУдаления = ИСТИНА ТОГДА 2
                КОГДА АЭ_ЖурналОперацийМФОиКПК.Проведен = ИСТИНА ТОГДА 1
                ИНАЧЕ 0
            КОНЕЦ
    КОНЕЦ КАК СостояниеДокумента,
    АЭ_ЖурналОперацийМФОиКПК.СуммаДокумента КАК СуммаДокумента
ИЗ
    ЖурналДокументов.АЭ_ЖурналОперацийМФОиКПК КАК АЭ_ЖурналОперацийМФОиКПК
ГДЕ
    АЭ_ЖурналОперацийМФОиКПК.Тип В (ТИП(Документ.АЭ_ВыдачаПоЗаймамПредоставленным), ТИП(Документ.ПриходныйКассовыйОрдер))
{ГДЕ
    (АЭ_ЖурналОперацийМФОиКПК.Ссылка В
            (ВЫБРАТЬ
                ДокументыПоКонтрагенту.Ссылка
            ИЗ
                КритерийОтбора.ДокументыПоКонтрагенту(&ОтборКонтрагент) КАК ДокументыПоКонтрагенту)),
    (ВЫБОР
            КОГДА &ОтборДоговорКонтрагента = НЕОПРЕДЕЛЕНО
                ТОГДА ЛОЖЬ
            ИНАЧЕ АЭ_ЖурналОперацийМФОиКПК.Ссылка В
                    (ВЫБРАТЬ
                        АЭ_ДокументыПоЗаймам.Ссылка
                    ИЗ
                        КритерийОтбора.АЭ_ДокументыПоЗаймам(&ОтборДоговорКонтрагента) КАК АЭ_ДокументыПоЗаймам)
        КОНЕЦ)}

Выясним, почему этот запрос заставляет СУБД работать неэффективно и вызывает зависания:

Использование критериев отбора в секции ГДЕ динамического списка. Вложенный запрос к КритерийОтбора.ДокументыПоКонтрагенту внутри фигурных скобок компоновщика данных полностью лишает SQL Server возможности использовать стандартную порционную выборку записей. СУБД не может применить индексы оптимально и вынуждена сканировать таблицы документов целиком для проверки условия соответствия критерию отбора.
Конструкция ВЫБОР КОГДА внутри условий ГДЕ. Логические конструкции ветвления в условиях запроса заставляют оптимизатор СУБД строить крайне сложные планы выполнения (чаще всего с использованием соединений типа Nested Loops или полного сканирования таблиц Clustered Index Scan). Каждое открытие списка пользователем генерирует колоссальную нагрузку на дисковую подсистему и процессор, а также накладывает разделяемые блокировки (Shared Locks) на таблицы документов.
В то время как один пользователь проводит документ (накладывая эксклюзивную блокировку на строку или таблицу), динамический список другого пользователя пытается выполнить этот монструозный запрос, натыкается на эксклюзивную блокировку и зависает. Возникает взаимное ожидание (блокировка), приводящая к таймауту и аварийному завершению работы программы.

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

Шаг 5. Настройка регламентных процедур в СУБД

Перенос данных из старой базы данных в новую (особенно когда переносятся остатки и документы за несколько месяцев) приводит к сильной дефрагментации индексов и мгновенному устареванию статистик СУБД. Без актуальной статистики оптимизатор SQL Server строит ошибочные планы выполнения запросов, выбирая неэффективные методы соединения таблиц.

Рекомендуем настроить ежедневный ночной план обслуживания базы данных в MS SQL Server, содержащий следующие обязательные шаги:

Обновление статистик (Update Statistics). Для баз данных 1С это критически важная операция. Ее следует выполнять с параметром FULLSCAN. На высоконагруженных базах обновление статистик рекомендуется проводить дважды в день — ночью и в обеденный перерыв (для наиболее активно изменяющихся таблиц).
Реорганизация индексов (Index Reorganize). Выполняется для индексов с уровнем фрагментации от 10% до 30%. Она не блокирует таблицы и может выполняться даже в рабочее время.
Перестроение индексов (Index Rebuild). Выполняется для сильно фрагментированных индексов (более 30%). Данная операция физически пересоздает индекс заново и требует монопольного доступа к таблицам (или использования опции ONLINE = ON в Enterprise-версиях SQL Server).

Приведем пример SQL-скрипта для быстрого обновления статистик во всей базе данных:


USE [Имя_Вашей_Базы_1С];
GO
EXEC sp_MSforeachtable 'UPDATE STATISTICS ? WITH FULLSCAN';
GO

Резюме: чек-лист распределения зон ответственности

Чтобы оперативно устранить зависания и запустить систему в штатном режиме, распределим задачи между системным администратором организации и разработчиками со стороны внедренца:

Зона ответственности системного администратора:

Ограничить аппетиты SQL Server по потреблению RAM, оставив ОС и процессам 1С (rphost) не менее 12-16 Гб свободной памяти.
Обновить платформу 1С:Предприятие до стабильного релиза, официально рекомендованного разработчиками новой конфигурации.
Настроить электропитание сервера в режим максимальной производительности (High Performance) в BIOS и настройках ОС Windows.
Отключить протокол IPv6 на серверах и рабочих станциях.
Настроить автоматический план обслуживания СУБД (обновление статистик, очистка TempDB, реиндексация).

Зона ответственности разработчиков (внедренцев):

Провести анализ технологического журнала 1С и выявить наиболее длительные транзакции и запросы (события DBMSSQL).
Оптимизировать программный код динамических списков документов (в первую очередь избавиться от критериев отбора и сложных конструкций ВЫБОР в секциях ГДЕ).
Убедиться, что доработки конфигурации, выполняемые при проведении документов (запись в регистры, расчет себестоимости, проверки остатков), не содержат запросов внутри циклов и выполняются с использованием оптимальных индексов.

Только совместная и последовательная работа по оптимизации системной среды и исправлению программных ошибок позволит добиться высокой скорости работы новой конфигурации 1С без зависаний и сбоев.