Особенности работы платформы с сеансовыми данными

За работу с сеансовыми данными отвечает менеджер кластера – rmngr.exe Если в кластере несколько рабочих серверов, то сеансовые данные будут расположены в соответствии с требованиями назначения функциональности.

Если требования не заданы, то сеансовые данные распределятся равномерно по всем рабочим серверам.

Сеансовые данные растут блоками по 64 Мб. Когда заканчивается блок, то менеджер кластера выделяет следующий блок в 64Мб.Блоки большего объема возможны в результате помещения объемных данных во временные хранилища.

Для обеспечения скорости работы, платформа всегда пишет новые данные в конец, аналогично transaction log в СУБД. Таким образом, размер сеансовых данных постоянно растет. Во всем объеме сеансовых данных, существуют как актуальные, так и устаревшие данные. Актуальность данных определяется способом их помещения:

  • Если сеансовые данные помещены из формы и в качестве идентификатора передается идентификатор формы (ЭтаФорма.УникальныйИдентификатор), то данные считаются актуальными, пока открыта форма.
  • Если в качестве идентификатора передан УникальныйИдентификатор, не являющийся уникальным идентификатором формы (Новый УникальныйИдентификатор), то значение перестанет быть актуальным после завершения сеанса пользователя.
  • Если ничего не передано, то значение перестанет быть актуальным при любом следующем серверном вызове.

Перед выделением следующего блока на диске, проверяется, прошло ли 5 секунд с момента выделения предыдущего блока. Если 5 секунд прошло, то запускается «сборщик мусора» (key value garbage collector). Сборщик оценивает процент актуальных сеансовых данных в общем объеме. Если актуальные данные занимают менее 25% от общего объема, то все актуальные данные копируются в новые файлы, а затем все старые.

Так как каждый сеанс (клиенты, фоновые задания, web-сервисы) в своей работе постоянно пишет информацию в сеансовые данные, то при большом количестве пользователей, скорость дисковой подсистемы, на которой расположены файлы сеансовых данных, играет очень важную роль. При большом количестве пользователей, рекомендуется располагать файлы сеансовых данных на максимально быстрых дисках. Желательно RAM-drive. Отказоустойчивость дисков не важна, т.к. при потере сеансовых данных, никакой важной информации утеряно не будет.

Следует отметить порядок размещения сеансовых данных. Если поместить во временное хранилище двоичные данные или файл, то эти данные пройдут в качестве потока байт через rphost, затем в rmngr, который сбросит этот поток на диск. Если же, в качестве помещаемого значения,  будет выступать коллекция (таблица значений, результат запроса, массив…), то сначала вся эта коллекция разместиться в памяти rphost, а только затем преобразуется в поток байт и будет передана в rmngr.

сеансовые данные 1С

Сеансовый кэш (по правильному — «сеансовые данные») как правило находится в расположении C:\Program Files\1cv8\srvinfo\reg_1541\snccntx + уникальный идентификатор. В этой папке (название папки может быть наподобие такого: snccntx23a3c417-bab8-43a5-9df9-8ba437f4523c) лежат файлы вида: snccntx.000057F1.dat . Это и есть сеансовые данные.

С этих файлах хранится служебная информация, необходимая для работы сеанса , например, все, что введено в поля ввода на форме, при серверных вызовах сбрасывается в сеансовые данные.

При вызове методов: ПоместитьВоВременноеХранилище, ПоместитьФайл, НачатьПомещениеФайла, значения указанные в параметрах, записываются в сеансовые данные.

При фоновом исполнении отчетов СКД, результат отчета помещается в сеансовые данные, а затем передается в клиентскую часть.

Сам файл *.dat является местом хранения  noSQL база данных (key-value storage).

Нам нужно удалить эти файлы чтобы повысить стабильность и предсказуемость работы платформы в некоторых случаях (например перед важным длительным расчетом). Прежде чем это сделать, останавливаем службу сервера 1С. А после удаления файлов, снова запускаем сервер.
При остановке службы сервера 1С бывают случаи, что отдельные процессы остаются висеть нештатно. Тогда такие процесс сервера 1С надо завершить принудительно.

Примечание. Путь кластера сервера 1С (C:\Program Files\1cv8\srvinfo\) может быть переопредлён ключом -D при запуске службы.

Подкаталог reg_1541 соответствует конкретному кластеру, совпадая в наименовании по номеру порта кластера. Если у вас несколько кластеров, или они расположены по нестандартным портам, то учитывайте это, просматривая соответствующие reg_… каталоги.

Рестарт службы сервера 1С с очисткой временных файлов

Пример скрипта рестарта службы сервера 1С с очисткой временных файлов.

set LOG_FILE="scripts.log"
set SERVICE_1C_NAME="1C:Enterprise 8.3 Server Agent (x86-64)"
set SERVICE_RAS_NAME="1C:Enterprise 8.3 Remote Server"
set CNTX_PATH="C:\srvinfo\reg_1541"
set PFL_PATH="C:\ProgramData\1C\1cv8"
set TEMP_PATH="%TEMP%"
echo %DATE% %TIME% stop service %SERVICE_1C_NAME% >> "%~dp0"%LOG_FILE%
sc stop %SERVICE_1C_NAME%
sc stop %SERVICE_RAS_NAME%
timeout 5
taskkill /f /im "rphost.exe"
taskkill /f /im "rmngr.exe"
taskkill /f /im "ragent.exe"
taskkill /f /im "ras.exe"
timeout 5
echo %DATE% %TIME% done stop service %SERVICE_1C_NAME% >> "%~dp0"%LOG_FILE%
echo %DATE% %TIME% start clean temp >> "%~dp0"%LOG_FILE%
DEL /Q /F /S %CNTX_PATH%\snccntx*
DEL /Q /F %PFL_PATH%\*.pfl
DEL /Q /F /S %TEMP_PATH%\*.*
echo %DATE% %TIME% done clean temp >> "%~dp0"%LOG_FILE%
echo %DATE% %TIME% start service %SERVICE_1C_NAME% >> "%~dp0"%LOG_FILE%
sc start %SERVICE_1C_NAME%
sc start %SERVICE_ RAS _NAME%
echo %DATE% %TIME% service %SERVICE_1C_NAME% restarted >> "%~dp0"%LOG_FILE%

Чтобы правильно определилась переменная %TEMP%, скрипт необходимо запускать от имени пользователя, под которым работает служба сервера 1С.

ошибка совместного доступа к файлу snccntx.dat

Эта ошибка порождается сервером под Windows, если в момент запуска сервера 1С:Предприятия в памяти уже имеется процесс rmngr, использующий этот же каталог реестра кластера.

Остановите службу Агента 1С:Предприятие 8.

Откройте Task manager.

Принудительно завершите все процессы (ragent, rmngr, rphost) кластера.