Links tmp в 1с что это
Обновлено: 25.06.2024
Поиск циклических ссылок
Циклическая ссылка возникает, когда объекты начинают ссылаться друг на друга. Это приводит к ситуации, при которой ни один из объектов, участвующих в циклической ссылке, не будет уничтожен. В свою очередь, это является причиной возникновения утечек памяти (memory leaks).
Классический пример циклической ссылки:
Такая структура останется в оперативной памяти, пока не будет перезапущен процесс, в котором эта структура была создана.
Циклические ссылки могут быть неявными, т.е. зацикливаться через несколько ссылок. Такая ситуация может быть опаснее, т.к. её очень трудно отследить
Опасные циклические ссылки
Существует ряд циклических ссылок, которые в течение длительной работы могут накапливаться и приводить к таким проблемам как:
- Рабочий процесс занял всю оперативную память (или достиг порога перезапуска);
- Бесконечная рекурсия в результате возникновения циклических ссылок;
- Сеансовые данные заняли все место на диске, на котором расположено хранилище.
Рассмотрим причины возникновения этих ситуаций вследствие образования циклических ссылок и варианты решения этих проблем.
Рабочий процесс занял всю оперативную память (или достиг порога перезапуска)
Если в конфигурации существуют множество мест возникновения циклических ссылок в серверном коде, то память, занимаемая рабочим процессом, постоянно растет. Выглядит такой рост, на графике использования памяти процессом rphost (счетчик "\Process("rphost*")\Virtual Bytes"), как лестница со ступеньками. Информацию по настройке счетчика вы можете найти в статье.
Для расследования причины возникновения таких утечек памяти, необходимо настроить сбор технологического журнала на всех рабочих серверах кластера серверов:
Следует учесть, что данный журнал будет занимать значительный объем. Необходимо размещать его на диске, имеющем достаточно свободного места. Также, рекомендуется периодически архивировать старые файлы и переносить их в другое дисковое пространство. По окончанию расследования имеет смысл отключать журнал, чтобы минизировать влияние на производительность информационной системы. Для сокращения объема журнала возможна установка параметра history до нескольких часов (но, не меньше 2). При этом периодичность архивации должна соответствовать параметру history , т.е. не реже, чем один раз в history -1 часов за предыдущие часы.
Дальше, необходимо расследовать возникновение каждой «ступеньки» на графике. Для этого:
- Определяется точное время, когда был скачкообразный рост по данным Performance Monitor,
- Ищется событие CALL в технологическом журнале процессов rphost за тоже время со свойством Memory, соответствующим размеру роста памяти на графике. Событие CALL может быть зафиксировано немного позже, но вы должны быть уверены, что скачкообразный рост памяти процесса rphost пришел на время выполнения именно этого вызова.
- Memory – объем памяти в байтах, занятой, но не освобожденной за серверный вызов.
- MemoryPeak – пиковое значение занятой за вызов памяти в байтах.
По журналу видно, что за один вызов длительностью 2,7 секунды было выделено, примерно 160 МБ памяти. Согласно графику эта память далее не была освобождена, в чем мы убеждаемся по свойству Memory. Следом за событием CALL в нашем примере следует событие с тем же clientID=405:
Вызов затребовал выделения 160 МБ, а затем попал в подозрение на циклическую ссылку (событие LEAKS технологического журнала).
Само наличие события LEAKS не свидетельствует о циклической ссылке. Событие LEAKS возникает, если в течение одного исполнения кода встроенного языка были созданы, но не были освобождены объекты. Поэтому событие LEAKS следует рассматривать одновременно с событиями CALL и показаниями счетчиков памяти рабочих процессов.
Утечки отслеживаются между начальной и конечной контрольной точкой в коде. В начальной контрольной точке выполняется очистка данных об утечках для текущего пользователя. В конечной контрольной точке выполняется формирование и вывод в технологический журнал события LEAKS, в котором для каждого неосвобожденного экземпляра объекта будет указан стек встроенного языка на момент его создания.
В качестве контрольных точек могут использоваться:
- начало и конец исполнения встроенного языка на клиенте или на сервере;
- вызов процедуры/функции встроенного языка и возврат из процедуры/функции;
- начало выполнения одной строки кода встроенного языка и окончание выполнения другой строки кода встроенного языка.
Начальную и конечную контрольную точку определяет элемент <point>. При этом, вложение контрольных точек друг в друга допускается, но игнорируется – подсчет утечек ведется только по внешним контрольным точкам. Например, если в процессе исполнения кода конфигурации были пройдены контрольные точки Начальная1, Начальная2, Конечная1, Конечная2, то утечки будут отслеживаться между точками Начальная1 и Конечная2.
Элемент <point> может иметь один из следующих форматов:
Более подробно вы можете прочитать в документации.
Таким образом в результате анализа указанного журнала вы можете получить:
- объем занятой и не освобожденной памяти определенным пользователем,
- стек вызова на встроенном языке, в котором возникла проблема,
- стек вызова на встроенном языке, в котором были созданы и не освобождены объекты.
Например, в форме описана переменная (или реквизит). При вызове процедуры, было установлено значение этой переменной. При выходе из процедуры значение этой переменной не сбросилось. Оно сбросится потом (когда будет закрыта форма), но событие LEAKS будем записано в технологически журнал.
Однако, если в качестве значения этой переменной установить саму форму, то переменная не будет уничтожена и останется в памяти все время работы процесса.
Описанная ситуация плоха по следующим причинам:
- рабочий процесс может со временем занять всю свободную память и привести к деградации производительности сервера;
- если настроен перезапуск процессов по порогу превышения памяти, то работа всех фоновых заданий или клиентов, выполняющих длительные вызовы, будет завершена принудительно вместе с завершением работы процесса по срабатыванию условия перезапуска.
Бесконечная рекурсия в результате возникновения циклических ссылок
Из-за циклических ссылок, можно вызвать аварийное завершение рабочего процесса.
Причина такого поведения платформы в том, что при обмене данными между клиентом и сервером все составные типы преобразуются в объекты XDTO. В данном примере, рабочий процесс будет пытаться рекурсивно преобразовать структуру, которая содержит в свойствах саму себя. При выполнении этого кода возникнет бесконечная рекурсия, что приведет к переполнению стека на встроенном языке.
Подобная ситуация также возникает, когда в форме есть реквизит, например, таблица значений. При вызове серверной процедуры в строку этой таблицы записали саму себя или любую другую зацикленную структуру. Тогда при возврате формы на клиента также возникнет бесконечная рекурсия.
Если в форме много реквизитов или коллекций, то не всегда очевидно, какая из них содержит циклическую ссылку. Расследовать причину можно по следующему алгоритму.
1. Собирается технологический журнал с событиями EXCP CALL SCALL с контекстами.
2. В зависимости от версии технологической платформы возникнет либо аварийное завершение процесса в результате переполнения стека, либо исключение, в котором будет указан стек кода на встроенном языке, приводящий к проблеме. В момент воспроизведения проблемы будет сделана запись (например, такая):
3. Ищем последнее событие с контекстом по данному clientID
4. Устанавливаем место в конфигурации, которое привело к ошибке.
В нашем примере, зацикленный реквизит находится в справочнике Контрагенты, форма элемента.
5. Для того, чтобы понять какой из реквизитов формы является причиной падения, необходимо в форму контрагента добавить процедуру:
Затем в конце каждой серверной процедуры или функции, формы элемента, вызвать процедуру ПроверитьЦиклическуюСсылку, передав в нее имя процедуры. Например:
Включить сбор технологического журнала с настройками:
6. Повторить действия пользователя, до момента воспроизведения ошибки. Последней строкой в технологическом журнале, в событии SDBL, будет имя реквизита формы, который «зациклился».
Сеансовые данные заняли все место на диске, на котором расположено хранилище
Сеансовые данные хранятся на рабочем сервере с назначенным на него сервисом сеансовых данных в каталоге кластера …\reg_<ПОРТ>\snccntx…
В них хранится сеансовая информация, например, информация форм управляемого приложения. Также, в них расположено временное хранилище. Все вызовы ПоместитьВоВременноеХранилище, помещают указанные в параметре данные в каталог сеансовых данных.
Неактуальные сеансовые данные не удаляются сразу, а вычищаются специальным сборщиком мусора периодически. Сервис сеансовых данных ведет список помещенных актуальных данных и их размера.
Неактуальными данные становятся в зависимости от параметра «Адрес» функции ПоместитьВоВременноеХранилище:
- В случае, если передается УникальныйИдентификатор формы или адрес в хранилище, то значение будет автоматически удалено после закрытия этой формы.
- Если передан УникальныйИдентификатор, не являющийся уникальным идентификатором формы, то значение будет удалено после завершения сеанса пользователя.
- Если параметр не указан, помещенное значение будет удалено после очередного запроса сервера из общего модуля, при контекстном и неконтекстном серверном вызове из формы, при серверном вызове из модуля команды или при получении формы.
В момент, когда размер актуальных данных составляет 25% от общего размера всех сеансовых данных, платформа запускает «сборку мусора». В этот момент на диске с сеансовыми данными должно быть свободного места, размером 25% от общего объема сеансовых данных. Если свободного места не хватит, то работа кластера становится, и он не сможет продолжить функционировать до того момента, пока не будут удалены старые сеансовые данные.
Если в конфигурации идет активная работа с временным хранилищем, и в качестве адреса используется идентификатор формы, то при попадании формы в циклическую ссылку, все помещенные ей сеансовые данные будут считаться актуальными даже после закрытия формы. Удаляться они только после завершения сеанса. При большом числе пользователей объем таких «актуальных» данных будет постоянно расти. В конечном итоге это может привести к нехватке свободного места в момент очередного «сбора мусора».
Для того, чтобы определить «зависают» ли данные формы, необходимо добавить в форму процедуру:
Затем, в процедуре ПриЗакрытии добавить последней строкой ее вызов.
Настроить технологический журнал на сбор информации:
Затем открыть форму, проделать в ней операции, характерные для работы пользователей и закрыть.
В случае успешного сброса сеансовых данных в технологическом журнале будет пара событий за один короткий промежуток времени, clientID= которых совпадает:
В случае «зависшей» формы будет только событие SDBL.
Однако, необходимо учитывать, что событие VRSREQUEST… ClearTempStorage может быть вызвано не сразу после закрытия формы. Это характерно для медленного соединения. Поэтому, поиск «зависших» форм необходимо проводить на тестовых серверах в монопольном режиме с соединением по TCP/IP между тонким клиентом и сервером без режима медленной работы.
После того, как выявлена форма с циклическими ссылками, расследование места возникновения этой ссылки следует проводить по методу, описанному ранее в разделе «Рабочий процесс занял всю оперативную память (или достиг порога перезапуска)».
Права на папку 'tmp' 1777, т.е. sticky bit стоит.
Средний 4 комментария
Это не Битрикс.Переместите в правильную категорию и Вам, наверняка, помогут
Владислав Жуков, а почему вы пригласили мня сюда, а не в свой вопрос? :)
Ошибка совместного доступа к файлу '/tmp/v8_QwHlJw_b71.tmp'Права не только юзера, от которого запущен клиент, но и юзера, от которого работает сервер 1С.
Ещё возможно запускается множественный вызов функции с одним и тем же именем временного (темпового) файла.
Сразу вижу несоответствие. В вопросе написано про обновление 1С и как "доказательство" приведен скриншот ошибки обмена с сайтом. При обновлении никакие обмены не запускаются (из процедур обновления). Если такое происходит, попробуйте перед обновлениями отключать выполнение фоновых заданий.
Теперь к ошибке. Тут проблема не в правах, а в "совместном доступе к файлу". И это общая ошибка для работы с файловой системой, а ваш обмен с сайтом только частный случай, где вы на нее попали. У меня был проект на сервере Ubuntu и я сталкивался с подобной ошибкой, когда ОС говорила 1С, что с файлом можно работать, но тот же конструктор ЧтениеТекста() выдавал ошибку (на винде такого не происходит).
Если воспользоваться объектом типа Файл, то он покажет существование вашего файла, но его размер будет нулевой (ОС еще не сбросила данные файлового буфера и не закрыла дескриптор). Собственно на этом и строилось мое исправление. Я сделал небольшой цикл ожидания пока размер равен нулю и как только у файла появлялось содержимое (или по таймауту) отпускал алгоритм выполняться далее.
В данной статье мы рассмотрим настройку сервера «1С:Предприятие» для использования Microsoft AD в качестве системы авторизации клиентов 1С. Статья представляет собой описание успешно внедрённого решения, за основу брались различные статьи из открытых источников, в частности официальная документация разработчика 1С.
Преамбула.
У нас имеется работающий на ОС Linux (CentOS7) сервер «1С:Предприятие». Сервер работает на хосте srv-app01, входящем в домен local.domain.name.
1. Настройка кластера сервера 1С:Предприятие
Настройка и управление кластером сервера «1С:Предприятие» происходит с компьютера с ОС Windows, так что для управления сервером нужно использовать традиционную оснастку mmc для Windows «Администрирование серверов 1С:Предприятие», которую следует установить из дистрибутива технологической платформы для Windows (ссылка).
Обязательно нужно настроить «Параметры рабочего сервера», как показано ниже:
Свойства кластера 'Критический объем памяти процессов', 'Режим распределения нагрузки' или свойства рабочего сервера 'Критический объем памяти процессов', 'Временно допустимый объем памяти процессов', 'Интервал превышения допустимого объема памяти процессов', 'Безопасный расход памяти за один вызов', 'Количество ИБ на процесс' содержат значения, отличные от значений по умолчанию.
Использование этих функций возможно только для лицензий на платформу уровня КОРП.
Это связано с тем, что «..начиная с версий платформы «1С:Предприятие» 8.3.12.1852, 8.3.13.1791 и 8.3.14.1592, вводятся ограничения на техническом уровне, не позволяющие использовать функциональность КОРП». Подробнее можно посмотреть здесь.
2. Настройка Kerberos-аутентификации
Для решения поставленной задачи настроим Kerberos-аутентификацию сервера «1С:Предприятие».
а) Настройка контроллера домена
Имя сервера srv-app01 обязательно должно разрешаться DNS-сервером (если его ввели в домен, то соответствующая запись в DNS-сервере есть).
Создать в домене учетную запись пользователя, с которой будут ассоциироваться запросы авторизации к серверу 1С:Предприятие. Имя может быть произвольное. В нашем случае это будет пользователь usr1cv8x с паролем XxXxXx. В свойствах этой уч`тной записи на вкладке «Учётная запись» в секции «Параметры учётной записи:» следует сбросить флажок «Use DES encryption types with this account»:
Для пользователя usr1cv8x следует сгенерировать файл с секретным ключом на компьютере с ОС Windows. Для этого используется утилита ktpass, входящая в состав в пакета Windows Support Tools (его можно найти в подкаталоге SUPPORT установочного диска Windows).
В командной строке запустим утилиту ktpass, которая «свяжет» доменного пользователя с пользователем, от имени которого работает сервер «1С:Предприятие»:
usr1cv8x, указываемое в параметре mapuser, — это имя доменного пользователя, которого мы создали.
В параметре pass передаётся пароль доменной учётной записи usr1cv8x.
В параметре out указывается имя файла с ключом. В нашем случае это usr1cv8.keytab.
б) Настройка центрального сервера кластера «1С:Предприятие»
Убедимся, что все в порядке:
Как видно, мы получили от KDC (Key Distribution Center — центр распределения ключей, эту функцию выполняет контроллер домена) так называемый ticket-granting ticket. После этого следует с помощью команды kdestroy очистить локальный кэш тикетов, чтобы вернуться в исходное состояние.
Далее любым способом следует передать файл с секретным ключом usr1cv8.keytab, полученный во время настройки контроллера домена, на центральный сервер кластера «1С:Предприятия». Этот файл следует скопировать в директорию, где установлен сервер «1С:Предприятие» (по умолчанию это /opt/1C/v8.3/x86_64), и установить права и владельца файла как показано ниже:
При желании файл можно разместить в любом другом месте, нужно только изменить переменную SRV1CV8_KEYTAB в конфигурационном файле (/etc/sysconfig/srv1cv83), чтобы она указывала на новое местоположение файла с секретным ключом.
После этого с помощью команды klist проверяем, всё ли мы сделали правильно. Для этого выполним команду:
Мы видим, что файл с секретным ключом содержит именно то, что нам нужно — в колонке Principal указано то самое имя службы, которое мы задавали при создании файла с секретным ключом, и правильный алгоритм шифрования (arcfour-hmac для RC4-HMAC).
Теперь посмотрим на результаты работы с помощью команды klist. В случае успеха мы увидим примерно следующее:
Если что-то настроено не так, то эта команда выведет следующее:
Если проверка работоспособности прошла успешно, это значит, что с данного момента сервер кластера «1С:Предприятия» способен обрабатывать запросы на аутентификацию. При этом перезапуск сервера не требуется, кроме того случая, когда в конфигурационном файле было изменено место расположения файла с секретным ключом.
в) Настройка пользователей в информационных БД «1С:Предприятие»
Для настройки аутентификации пользователей в информационной БД «1С:Предприятие» с помощью доменной учетной записи нужно запустить БД под Администратором.
Перейти в «Администрирование», слева в списке выбрать «Пользователи».
В появившемся окне «Пользователи» выбрать нужного пользователя.
В свойствах пользователя выбрать «Аутентификация операционной системы» и в поле «Пользователь» нажать на кнопку «. ».
В списке «Пользователи» выбрать нужного пользователя и нажать на кнопку «Выбрать». Должно получиться как на скриншоте:
Эти действия нужно повторить для всех пользователей БД.
В результате мы получаем решение, при котором пользователю не требуется совершать дополнительных действий по вводу логина и пароля для запуска приложения. Система определяет пользователя операционной системы, запускающего приложение, и соотносит с имеющейся ролью в конфигурации «1С». Использование единой системы авторизации в прикладных приложениях удобно как для пользователя, так и для администратора конфигурации «1С» — не нужно обслуживать дополнительную локальную базу пользователей приложения.
Анализ причин роста сеансовых данных
Платформа "1С:Предприятие" в своей работе постоянно использует механизм, называемый "сеансовые данные". В этих данных хранится служебная информация, необходимая для работы сеанса "1С:Предприятия". Например, все, что введено в поля ввода на форме, при серверных вызовах сбрасывается в сеансовые данные.
При вызове методов: ПоместитьВоВременноеХранилище, ПоместитьФайл, НачатьПомещениеФайла, значения указанные в параметрах, записываются в сеансовые данные.
При фоновом исполнении отчетов СКД, результат отчета помещается в сеансовые данные, а затем передается в клиентскую часть.
С точки зрения операционной системы, сеансовые данные представляют собой файлы в каталоге …\srvinfo\reg_<номер порта>\snccntx<GUID>.
С точки зрения внутренней структуры - это noSQL база данных (key-value storage).
Особенности работы платформы с сеансовыми данными
За работу с сеансовыми данными отвечает менеджер кластера – rmngr.exe Если в кластере несколько рабочих серверов, то сеансовые данные будут расположены в соответствии с требованиями назначения функциональности.
Если требования не заданы, то сеансовые данные распределятся равномерно по всем рабочим серверам.
Сеансовые данные растут блоками по 64 Мб. Когда заканчивается блок, то менеджер кластера выделяет следующий блок в 64Мб.Блоки большего объема возможны в результате помещения объемных данных во временные хранилища.
Для обеспечения скорости работы, платформа всегда пишет новые данные в конец, аналогично transaction log в СУБД. Таким образом, размер сеансовых данных постоянно растет. Во всем объеме сеансовых данных, существуют как актуальные, так и устаревшие данные. Актуальность данных определяется способом их помещения:
- Если сеансовые данные помещены из формы и в качестве идентификатора передается идентификатор формы (ЭтаФорма.УникальныйИдентификатор), то данные считаются актуальными, пока открыта форма.
- Если в качестве идентификатора передан УникальныйИдентификатор, не являющийся уникальным идентификатором формы (Новый УникальныйИдентификатор), то значение перестанет быть актуальным после завершения сеанса пользователя.
- Если ничего не передано, то значение перестанет быть актуальным при любом следующем серверном вызове.
Перед выделением следующего блока на диске, проверяется, прошло ли 5 секунд с момента выделения предыдущего блока. Если 5 секунд прошло, то запускается "сборщик мусора" (key value garbage collector). Сборщик оценивает процент актуальных сеансовых данных в общем объеме. Если актуальные данные занимают менее 25% от общего объема, то все актуальные данные копируются в новые файлы, а затем все старые файлы сеансовых данных удаляются.
Так как каждый сеанс (клиенты, фоновые задания, web-сервисы) в своей работе постоянно пишет информацию в сеансовые данные, то при большом количестве пользователей, скорость дисковой подсистемы, на которой расположены файлы сеансовых данных, играет очень важную роль. При большом количестве пользователей, рекомендуется располагать файлы сеансовых данных на максимально быстрых дисках. Желательно RAM-drive. Отказоустойчивость дисков не важна, т.к. при потере сеансовых данных, никакой важной информации утеряно не будет.
Следует отметить порядок размещения сеансовых данных. Если поместить во временное хранилище двоичные данные или файл, то эти данные пройдут в качестве потока байт через rphost, затем в rmngr, который сбросит этот поток на диск. Если же, в качестве помещаемого значения, будет выступать коллекция (таблица значений, результат запроса, массив…), то сначала вся эта коллекция разместиться в памяти rphost, а только затем преобразуется в поток байт и будет передана в rmngr.
Размещение сеансовых данных в памяти
При работе кластера "1С:Предприятия", файлы сеансовых данных отображаются в память (mapping). Подробнее см. статью.
За счет данного механизма, процесс работает с файлом как с оперативной памятью. Файл загружается в память не целиком, а только необходимая часть.
Однако, в операционной системе Windows, отображенные в память файлы, влияют на счетчик Memory\Available Mbytes. При сильном росте сеансовых данных можно увидеть следующую картину:
Свободное место на диске, где расположены сеансовые данные, уменьшается синхронно со свободной памятью сервера. На самом деле, если посмотреть данные RamMap то видно, что большая часть оперативной памяти выделена под Mapped File
Размер памяти, указанный в колонке Standby – это неиспользуемая память (фактически свободная). При запросе памяти любым процессом, ему будет выделена память из этой области.
Следует учитывать данную особенность счетчика Memory\Available Mbytes при построении систем мониторинга или приложений, которые опираются на объем доступной оперативной памяти.
Для косвенной оценки эффективности работы операционной системы с сеансовыми данными, можно использовать счетчик Memory\Page Faults/sec, который показывает на сколько часто процессы обращаются за страницами в память, но не находят их там и подгружают с диска.
Если значение данного счетчика велико, то это может свидетельствовать о нехватке оперативной памяти для кэширования в ней сеансовых данных. В этом случае, необходимо принять решение об увеличении оперативной памяти, либо об оптимизации работы приложения с сеансовыми данными.
Проблемы сеансовых данных
Ошибка совместного доступа к файлу snccntx.dat
При появлении данной ошибки необходимо действовать по алгоритму:
1. Проверить права на папку сеансовых данных для пользователя, от которого запущена служба сервера "1С:Предприятия". Должны быть полные права.
2. Открыть на рабочем сервере диспетчер задач, установить видимость колонки "Командная строка"
3. Необходимо найти процессы rmngr.exe с одинаковым значением параметра –pid.
4. Открыть консоль кластера. Развернуть ветку кластера, порт которого соответствует параметру –regport , найденных rmngr.exe с одинаковым значением параметра –pid
5. Сопоставить PID из диспетчера задач с PID в консоли кластера. Тот процесс rmngr.exe, которого нет в консоли – принудительно завершить.
Закончилось место на диске, где расположены сеансовые данные
Необходимо следить за наличием свободного места на диске, где расположены сеансовые данные.
Не следует размещать файлы технологических журналов на одном диске с сеансовыми данными.
Если на диске, где расположены сеансовые данные, закончится место, то картина будет совершенно "апокалиптическая". Менеджер кластера будет постоянно завершаться с формированием дампа. Начнутся сотни попыток запусков рабочих процессов, которые сразу же будут завершаться с ошибками. После того, как на диске появится свободное место, сервер "1С:Предприятия" запустится в нормальном режиме.
Так же, необходимо следить за размером самих сеансовых данных. Если периодически их размер становится существенным, то необходимо обратить на это особое внимание. Следует помнить, что при срабатывании "сборки мусора" необходимо наличие свободного места на диске, в размере 25% от общего объема сеансовых данных. Если этих 25% не будет, то кластер завершит свою работу аварийно.
Изменить расположение сеансовых данных, можно указав параметр –d в строке запуска службы агента сервера.
В данном каталоге, также расположены: реестр кластера, индекс полнотекстового поиска и журнал регистрации.
Влияние циклических ссылок на рост сеансовых данных
Чаще всего при выполнении процедуры ПоместитьВоВременноеХранилище, указывается идентификатор формы (ЭтаФорма.УникальныйИдентификатор). Как написано в документации, при указании идентификатора формы данные перестают считаться актуальными после того как форма будет закрыта.
Однако, если форма содержит в себе циклические ссылки (см. статью), то после закрытия формы она не уничтожается. Это приводит следующим отрицательным эффектам:
- данные формы остаются в памяти
- сеансовые данные, выделенные для формы, считаются актуальными, пока не будет завершен сеанс
Чтобы избежать данной ситуации, необходимо исключить все циклические ссылки в форме (см. статью).
Необходимо стараться формировать отчеты СКД в фоновом режиме. Так как результат отчета помещается во временное хранилище фоновым заданием, то после завершения задания данный результат будет считаться неактуальным.
Методика анализа роста сеансовых данных
Сбор данных
Необходимо собрать технологический журнал:
Данный технологический журнал может занимать значительный объем. Поэтому необходимо располагать его на дисках имеющих достаточно свободного пространства, периодически переносить старые файлы журнала на другой диск и там архивировать (сохраняя структуру папок).
После того, как технологический журнал будет собран, необходимо провести "парсинг" и выгрузить его данные в файлы csv формата:
На основании данных, которые собраны в папках rmngr_*, необходимо сформировать csv файл вида:
- <файл ТЖ> – имя файла технологического журнала,
- <CallID> – значение свойства CallID,
- <InBytes> - значение свойства InBytes.
В файле …/rmngr_7188/ 15063011. log есть строка:
Данная строка должна быть преобразована в строку:
Необходимо исключить из итогового файла строки с InBytes=0, т.к. они не представляют интереса, но занимают значительный объем.
На основании данных, которые собраны в папках rphost_*, необходимо сформировать csv файл вида:
- <процесс>– имя папки рабочего процесса,
- <файл ТЖ> – имя файла технологического журнала,
- <t:clientID> – значение свойства t:clientID,
- <CallID> – значение свойства CallID.
В файле …/ rphost_1352 / 15063011 .log есть строка:
Данная строка должна быть преобразована в строку:
На основании данных, которые собраны в папках rphost_*, необходимо сформировать csv файл вида:
- <процесс> – имя папки рабочего процесса,
- <t:clientID> – значение свойства t:clientID,
- <Usr> – Имя пользователя из свойства Usr.
В файле …/ rphost_1352 /15063011.log есть строка:
Данная строка должна быть преобразована в строку:
В итоге должно получиться 3 файла: scall.csv, call.csv, conn.csv
Пример создания файлов csv, на основании данных технологического журнала, см. в обработке.
Создание базы данных для анализа
Необходимо создать пустую базу данных (MS SQL Server), в которую добавить таблицы:
Затем, в эти таблицы необходимо загрузить данные из соответствующих csv файлов. Сделать это можно с помощью SQL Server Integration Services
После того, как информация будет загружена в таблицы, можно проводить анализ.
Анализ работы с сеансовыми данными
TOP – 10 пользователей в разрезе процессов и времени
Запрос покажет топ-10 пользователей, которые поместили больше всего сеансовых данных в час. Затем необходимо разобраться с самым верхним (в текущем случае):
Т.е. в процессе rphost_1352 за час с 11-00 по 12-00 пользователь с идентификатором 518 записал в сеансовые данные 2 046 616 858 байт (2Гб).
Далее, необходимо найти все идентификаторы вызовов, которые записывал сеанс 518:
Читайте также: