Поиск циклических ссылок

Циклическая ссылка возникает, когда объекты начинают ссылаться друг на друга. Это приводит к ситуации, при которой ни один из объектов, участвующих в циклической ссылке, не будет уничтожен. В свою очередь, это является причиной возникновения утечек памяти (memory leaks).

Классический пример циклической ссылки:

Такая структура останется в оперативной памяти, пока не будет перезапущен процесс, в котором эта структура была создана.

Циклические ссылки могут быть неявными, т. е. зацикливаться через несколько ссылок. Такая ситуация может быть опаснее, т. к. её очень трудно отследить

Опасные циклические ссылки

Существует ряд циклических ссылок, которые в течение длительной работы могут накапливаться и приводить к таким проблемам как:

Рассмотрим причины возникновения этих ситуаций вследствие образования циклических ссылок и варианты решения этих проблем.

Рабочий процесс занял всю оперативную память (или достиг порога перезапуска)

Если в конфигурации существуют множество мест возникновения циклических ссылок в серверном коде, то память, занимаемая рабочим процессом, постоянно растет. Выглядит такой рост, на графике использования памяти процессом rphost (счетчик «\Process(«rphost*»)\Virtual Bytes»), как лестница со ступеньками. Информацию по настройке счетчика вы можете найти в статье.

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

Дальше, необходимо расследовать возникновение каждой «ступеньки» на графике. Для этого:

По журналу видно, что за один вызов длительностью 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 между тонким клиентом и сервером без режима медленной работы.

После того, как выявлена форма с циклическими ссылками, расследование места возникновения этой ссылки следует проводить по методу, описанному ранее в разделе «Рабочий процесс занял всю оперативную память (или достиг порога перезапуска)».

Цифровая связь — код контроля ошибок

Шум или ошибка — основная проблема в сигнале, которая нарушает надежность системы связи. Кодирование с контролем ошибок — это процедура кодирования, выполняемая для контроля появления ошибок. Эти методы помогают в обнаружении ошибок и исправлении ошибок.

Линейные Блочные Коды

В линейных блочных кодах биты четности и биты сообщения имеют линейную комбинацию, что означает, что результирующее кодовое слово является линейной комбинацией любых двух кодовых слов.

Систематический код

Ниже приведено представление структуры кодовых слов в соответствии с их распределением.

Если сообщение не изменено, оно называется систематическим кодом. Это означает, что шифрование данных не должно изменять данные.

Сверточные коды

До сих пор в линейных кодах мы обсуждали, что систематический неизмененный код является предпочтительным. Здесь данные из общего числа n битов, если переданы, k битов являются битами сообщения и (nk) битами являются биты четности.

В процессе кодирования биты четности вычитаются из целых данных, а биты сообщения кодируются. Теперь биты четности снова добавляются, и все данные снова кодируются.

На следующем рисунке приведены примеры блоков данных и потоков данных, используемых для передачи информации.

Весь процесс, изложенный выше, утомителен и имеет недостатки. Выделение буфера является основной проблемой, когда система занята.

Этот недостаток устраняется в сверточных кодах. Где весь поток данных назначается символам, а затем передается. Поскольку данные представляют собой поток битов, для хранения не требуется буфер.

Коды Хэмминга

Тем не менее, код Хэмминга — лучшая процедура, чем обсуждаемые ранее при обнаружении и исправлении ошибок.

Коды BCH

Коды БЧХ названы в честь изобретателей B ose, C haudari и H ocquenghem. Во время разработки кода BCH существует контроль количества символов, которые должны быть исправлены, и, следовательно, возможна множественная битовая коррекция. Коды БЧХ — это мощный метод исправления ошибок.

Для любых натуральных чисел m ≥ 3 и t <2 m-1 существует двоичный код BCH. Ниже приведены параметры такого кода.

Количество проверочных цифр n — k ≤ mt

Минимальное расстояние d _min ≥ 2t + 1

Циклические коды

Циклическое свойство кодовых слов заключается в том, что любой циклический сдвиг кодового слова также является кодовым словом. Циклические коды следуют этому циклическому свойству.

Циклические коды используются для исправления ошибок. Они в основном используются для исправления двойных ошибок и пакетных ошибок.

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