Каждый специалист по автоматизации крупных предприятий на платформе 1С рано или поздно сталкивается с аномалиями в работе системы, которые на первый взгляд кажутся мистическими. Представьте стандартную рабочую ситуацию: бухгалтеры формируют отражение документов в регламентированном учете в конфигурации 1С:Комплексная автоматизация 2.4 или 1С:ERP. Документ успешно проводится, внутри самого документа проводки видны сразу же, но при попытке сформировать отчет Оборотно-сальдовая ведомость (ОСВ) бухгалтер видит пустоту. Сколько бы раз пользователь ни нажимал кнопку «Сформировать», данные не обновляются. Проходит ровно 10–15 минут, и суммы «чудодейственным» образом появляются в отчете без каких-либо дополнительных действий.
В этой статье мы подробно разберем, почему возникает этот неприятный эффект, проанализируем внутренние механизмы платформы 1С:Предприятие 8.3 и СУБД MS SQL Server, которые вызывают подобные задержки, и рассмотрим пошаговые методы устранения данной проблемы.
Давайте сначала проанализируем техническую среду, в которой чаще всего воспроизводится этот сбой:
8.3.13, например, 8.3.13.1644).Ключевая странность заключается в том, что в базе данных проводки уже физически существуют (так как они отображаются в форме самого документа), но глобальные отчеты их игнорируют. Это указывает на рассинхронизацию между транзакционным уровнем записи данных и уровнем построения агрегированной отчетности.
---
Основная техническая причина, по которой ОСВ выдает пустой или устаревший результат в течение первых 10–15 минут — это **сбой механизма инвалидации (очистки) кэша** на сервере приложений 1С в рабочих процессах rphost.
Для ускорения работы отчетов платформа 1С активно использует кэширование итогов и запросов к виртуальным таблицам регистров (таких как РегистрБухгалтерии). Когда пользователь формирует ОСВ, платформа не всегда делает «тяжелый» прямой запрос к физическим таблицам СУБД. Вместо этого она считывает готовые данные из оперативной памяти сервера приложений 1С.
В нормальных условиях, как только транзакция записи проводок фиксируется в СУБД, сервер приложений получает системный сигнал о том, что данные регистра изменились, и кэш по этому регистру необходимо немедленно сбросить (инвалидировать). Однако в релизах платформы 8.3.13 содержался известный баг: при определенных нагрузках на MS SQL Server рабочие процессы 1С теряли или задерживали обработку сигналов об изменении данных. В итоге сервер приложений продолжал отдавать пользователям устаревший снимок данных из своего кэша. Время жизни такого кэша по умолчанию составляет около 10–15 минут. Как только этот таймаут истекал, кэш очищался по времени, и отчет наконец-то читал актуальные данные из SQL.
---
Второй важный фактор — совместное использование одного сервера СУБД несколькими тяжелыми базами. Если на одном сервере SQL крутятся, например, Комплексная автоматизация 1.1 и Комплексная автоматизация 2.4, они начинают жестко конкурировать за общую системную базу данных TempDB.
Платформа 1С очень интенсивно использует TempDB для создания временных таблиц при проведении документов, расчете себестоимости и формировании отчетов. При одновременной работе пользователей в двух базах в TempDB возникает критическое взаимное блокирование страниц памяти — так называемый **Latch Contention** на системных служебных страницах (PFS, GAM, SGAM).
В результате этого транзакции по расчету итогов и фоновому отражению документов в регламентированном учете начинают «зависать» в очередях СУБД. Хотя сам документ успел записать свои движения, итоговые таблицы регистра бухгалтерии не могут завершить обновление из-за дефицита ресурсов TempDB. Задержка как раз может составлять те самые 10–15 минут, пока соседняя база не освободит системные страницы СУБД.
Чтобы проверить наличие этой проблемы на вашем сервере SQL, администраторы могут выполнить следующий диагностический запрос:
SELECT session_id, wait_duration_ms, wait_type, resource_description
FROM sys.dm_os_waiting_tasks
WHERE wait_type LIKE 'PAGELATCH_%' OR wait_type LIKE 'PAGEIOLATCH_%';
Если в результатах запроса вы регулярно видите ожидания на ресурсах типа 2:1:1 (база данных 2 — это TempDB, файл 1, страница 1), ваш сервер страдает от нехватки производительности временной базы данных.
---
В конфигурациях 1С:КА 2.4 и 1С:ERP 2.4 механизмы проведения документов и отражения их в бухгалтерском учете разделены. По умолчанию система настроена на асинхронное фоновое отражение проводок. Когда пользователь нажимает кнопку проведения, документ записывается, но задача на создание проводок встает в очередь к специальному регламентному заданию.
Если сервер загружен или платформа работает со сбоями, фоновое задание по отражению в регл. учете выполняется с большой задержкой. В самом документе проводки могут отображаться как предварительные или кэшироваться в рамках локального сеанса создавшего его пользователя, тогда как в глобальном регистре бухгалтерии фактическая запись данных завершается значительно позже.
---
Для минимизации блокировок при одновременной записи документов множеством пользователей в 1С используется механизм Разделения итогов. Вместо обновления одной записи общего итога система пишет движения в параллельные субтаблицы (сплинты). Слияние этих сплинтов в единое итоговое значение происходит либо регламентным заданием в фоне, либо «на лету» при формировании отчета.
Если дисковая подсистема сервера SQL перегружена из-за работы нескольких баз данных на одном диске, процесс слияния разделенных итогов начинает сильно тормозить. При попытке сформировать ОСВ система натыкается на таймауты и блокировки СУБД, в результате чего выдает старый рассчитанный итог без учета только что сделанных движений.
---
Рассмотрим подробнее варианты решения этой проблемы, начиная от оперативных мер и заканчивая фундаментальной оптимизацией серверной инфраструктуры.
Наиболее эффективным и быстродействующим решением в условиях совмещенного использования серверов является физический или логический перенос базы данных на другой экземпляр SQL Server.
TempDB, исключит взаимные блокировки страниц памяти и распределит нагрузку на дисковые накопители. Как показала практика автора темы на форуме, это мгновенно решает проблему с задержкой появления проводок в ОСВ.Поскольку проблема напрямую связана с багами кэширования в рабочих процессах rphost на 13-й ветке платформы, необходимо пересмотреть используемую версию технологической платформы.
8.3.12 (например, рекомендуемую разработчиками 8.3.12.1855). На этой версии механизмы работы с кэшем виртуальных таблиц работают корректно.8.3.14, 8.3.16 или современных LTS-версий), в которых ошибки синхронизации кэша метаданных и виртуальных таблиц под нагрузкой SQL были успешно исправлены разработчиками 1С.Если вы не можете прямо сейчас разнести базы на разные SQL-серверы, настройте системную базу TempDB так, чтобы минимизировать конкуренцию за ее ресурсы:
TempDB одинакового размера. Количество файлов должно соответствовать числу ядер процессора (но не более 8 файлов, если ядер больше). Это позволит распределить запись временных таблиц параллельно по разным файлам и уберет блокировки страниц PFS/GAM.-T1117 (равномерное расширение всех файлов в группе) и -T1118 (выделение полных экстентов вместо смешанных). В MS SQL Server 2016 и выше эти механизмы работают по умолчанию.TempDB на самых быстрых доступных накопителях (желательно NVMe SSD), изолировав их от файлов основных баз данных.Для профилактики проблем со слиянием разделенных итогов и актуализации рассчитанных периодов в регистрах бухгалтерии, можно периодически выполнять принудительное обновление итогов с помощью встроенного языка 1С. Например, можно запустить обработку со следующим кодом:
// Установка актуального периода рассчитанных итогов для регистра бухгалтерии
РегистрыБухгалтерии.Хозрасчетный.УстановитьПериодРассчитанныхИтогов(КонецМесяца(ТекущаяДата()));
// Принудительное включение использования итогов для пересчета агрегатов
Если Не РегистрыБухгалтерии.Хозрасчетный.ПолучитьИспользованиеИтогов() Тогда
РегистрыБухгалтерии.Хозрасчетный.УстановитьИспользованиеИтогов(Истина);
КонецЕсли;
Этот несложный шаг помогает актуализировать таблицы итогов СУБД, сводя к минимуму необходимость динамического расчета остатков "на лету" при открытии ОСВ пользователями.
Задержка появления проводок в отчетах на 10–15 минут — это комплексная проблема, лежащая на стыке багов платформы 1С (кэширование процессов rphost) и неоптимального распределения ресурсов СУБД MS SQL (перегрузка TempDB и дисков). Наилучшим решением является изоляция баз данных на уровне экземпляров SQL в сочетании с переходом на стабильную, рекомендованную разработчиками версию платформы 1С:Предприятие.