Обновлено: 08.01.2025

не надо менять данные ПриПолученииДанных, даже на такие же значения. т.е. сначала сравинвай и меняй только если отличаются.

напиши еще запросов и МВТ в этот обработчик и не убивай временные, я пока организую тотализатор как скоро кроякнеться ваш сервер - дерзай я уже собираю ставки

ты бы хоть в типовых посмотрел как там сделано - зачем же изобретать лисапед

потому это тестовая база. я только начал делать обработку это понятно, но я думал что можно как то по-другому организовать так чтобы событие дохло еще в зародыше=)) ну что то я ничего подобного моей задачке не видел в типовом. вобщем полная(пока еще нет) таблица заказов. можно сразу увидеть какой заказ в какой стадии, и оформить все что нужно с одного окна, не залезая в 10 менюшек и не тыкая в автосоздание документов когда бывало пишется не совсем то что надо а менеджер узнает об этом хз когда. ничего подобного не видел в типовом

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

2 ваш пример описан у габца.. При получении - получаем данные, как бы в кэш, дополняем его как бог черепаху , а при выводе например строки - ищем в кэше по ключу и уже выводим, но не делаем Обновить

Ну нельзя же данные менять! Добавить колонки на форму (просто колонки, не связывая с данным). И выводить в эти колонки текст, используя метод оформления строки УстановитьТекст ОформлениеСтроки.Ячейки.ИмяКолонки.УстановитьТекст(<Текст>)

я так пробовал - не катит так. это больший гемор чем проверять данные перед изменением. +Не все созданные поля должны иметь тип текст(флажок,картинку), но также и ссылки на документы, т.е. ссылку на счет и т.д. При изменении получаемого в процедуре параметра - коллекции ОформленияСтрок хоть ты шрифт поменяй или цвет фона, все равно вызов будет снова=((( КСТАТИ НАСЧЕТ ЭТОГО ПРИМЕРА событие ПриПолученииДанных вызывается при изменении любых данных ТЗ или только при изменении тех данных что видны в ТП? то есть типа Процедура ПриПолученииДанных(ОформленияСтрок) ОформленияСтрок=ПеределанныеОформленияСтрок; КонецПроцедуры ?или я чего то не понял? Жаль что нет ничего типа "ПередПолучениемДанных". так бы по пути перехватить их, изменить, и пусть идут туда куда шли эта вещь как раз на тупых и расчитана будет. убрана излишняя свобода действий менеджеров. тыкнул по порядку в поле "счет" где нет галки - создался новый счет, тыкнул в поле где есть счет - открыл его. и т.д. Часто менеджеры путаются какой заказ на какой стадии. оставляют заказы без ПКО или наоборот выписывают 2-3 двойника и приход оказывается не 20000 а 40-60 =)А так все данные(вплоть до адреса и т.д.) будут получаться из справочников(адреса). у менеджера даже клавиатуры не будет, будет сенсорный экран и все. у админа будет доступ к вводу новой инфы. обычные менеджеры будут работать только с постоянной клиентской базой. вобщем спецификация организации позволяет так замутить=))

2 давай ты словами расскажешь что хочешь сделать со строками и в зависимости от чего.

> оставляют заказы без ПКО или наоборот выписывают 2-3 двойника и приход оказывается не 20000 а 40-60 Это не проблема программиста, это проблема директора, раз два премии лишат - больше не ошибутся. Я бы делал как в или еще одну табличку с нужной информацией, в которой информация меняется при перемещении по основной таблице.

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

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

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

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

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

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

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

• Рабочий процесс занял всю оперативную память (или достиг порога перезапуска);
• Бесконечная рекурсия в результате возникновения циклических ссылок;
• Сеансовые данные заняли все место на диске, на котором расположено хранилище.

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

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

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

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

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

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

1. Определяется точное время, когда был скачкообразный рост по данным Performance Monitor,
2. Ищется событие 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 между тонким клиентом и сервером без режима медленной работы.

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

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

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

В платформе 1С:Предприятие 8 используется стратегия управления временем жизни объектов, основанная на подсчете ссылок на объекты - reference counting. Данная стратегия заключается в следующем. Каждый объект платформы содержит счетчик ссылок. При появлении ссылки на объект (когда объект присваивается какой-либо переменной) происходит увеличение счетчика на единицу, при уничтожении подобной ссылки - значение счетчика на единицу уменьшается. Когда счетчик ссылок объекта становится равен нулю, объект автоматически уничтожается, и память, занимаемая им, освобождается.

Особенностью подсчета ссылок на объекты является возможность организации циклической ссылки. Циклическая ссылка возникает, когда объекты начинают ссылаться друг на друга. Например, если есть объекты, внутри которых вложены другие объекты, и где-то в глубине они ссылаются на самый верхний объект. В результате образуется циклическая ссылка. В самом упрощённом виде циклическая ссылка может быть получена следующим образом:

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

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

Мы разработали два инструмента, которые помогут вам обнаруживать циклические ссылки. Мы рекомендуем использовать их только в период отладки и тестирования, потому что они требуют значительных ресурсов, что может негативно сказаться на выполнении операций 1С:Предприятия.

Автоматический поиск циклических ссылок

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

В этом диалоге будут перечислены все переменные, для которых обнаружено зацикливание. И для каждой переменной будут перечислены (в терминах встроенного языка) все циклы, в которых она участвует.

В данном случае к зацикливанию привёл такой фрагмент кода:

Этот режим вы можете включить разными способами, например:

• в параметрах командной строки;
• в параметрах запуска в конфигураторе;
• в конфигурационном файле conf.cfg.

Также режим автоматического поиска циклических ссылок можно включить и в настройках технологического журнала. Но в этом случае исполнение программного кода останавливаться не будет, а вся обнаруженная информация будет собираться в технологический журнал, в новое событие SCRIPTCIRCREFS.

Поиск циклических ссылок из встроенного языка

Для более тонкой и точной диагностики наличия циклических ссылок мы реализовали новый метод глобального контекста ПроверитьЦиклическиеСсылкиВстроенногоЯзыка(). С его помощью вы можете найти циклические ссылки, например, в нужный вам момент, или в той процедуре, которая вас интересует, или проанализировать ту переменную, которая вызывает у вас подозрение.

Если вы не указываете параметры этого метода, то будут проанализированы все локальные переменные на стеке. Если вы передаёте в метод локальную переменную, то будет проанализирована только она.

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

Отслеживание получения и освобождения лицензий

Ещё одна группа вопросов, которые до сих пор диагностировались сложно, связана с получением и освобождением лицензий. Например, в ситуации, когда неожиданно для администратора или разработчика заканчивались лицензии, требовались значительные усилия для расследования.

Теперь в технологическом журнале мы реализовали подробное логирование событий, связанных с лицензированием. Для этого мы используем событие LIC.

Попытки получения лицензий

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

При этом, если используются HASP ключи, логируется и процесс их инициализации. Фиксируется вид запрашиваемой лицензии и список доступных HASP ключей.

Освобождение лицензий

При каждом освобождении лицензии записывается информация об идентификаторе, времени, в которое был создан объект освобождаемой лицензии, получателе лицензии, виде лицензии или о ключе, а также данные о количестве занятых программных лицензий.

Проверка неизменности параметров, критичных для лицензирования

Мы реализовали периодическую (через 20 минут) проверку неизменности параметров компьютера, критичных для привязки программных лицензий. Если обнаруживается критическое изменение этих параметров, то в технологический журнал записывается событие LIC. Оно содержит информацию об имени файла лицензии, регистрационный номер, пин-код, вид лицензии, максимальное количество пользователей и список критичных изменений в оборудовании.

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

Я продолжаю изучать ознакомительную версию платформы 1С 8.3.10. И эта моя статья будет посвящена циклическим ссылкам.
Для тех кто не в курсе, проведу небольшой ликбез по теме циклических ссылок. Циклическая ссылка возникает тогда, когда какой-то объект ссылается на самого себя. Это может приводить к различным проблемам в плане производительности, в частности утечки памяти.

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

Если мы запустим написанный выше код с включенным параметром «Проверка циклических ссылок встроенного языка», то 1С: Предприятие выдаст ошибку.

Этот способ очень удобен, когда Вы ведете отладку приложения. Но этот способ не всегда удобен, если необходимо контролировать циклический ссылки при разработке нескольких конфигураций, т.к. в каждой базе нужно будет устанавливать этот параметр.
В этом случае гораздо удобнее изменить файл conf.cfg (у меня он находится в каталоге C:\Program Files (x86)\1cv8\conf)
В этот файл необходимо добавить следующую строку

тогда у любой базы, запускаемой под платформой 1С 8.3.10, при работе будет осуществляться проверка циклических ссылок.
Что бы проверить цикличность ссылок на стороне сервера, когда используется клиент-серверный вариант работы, то необходимо запустить сервер с ключом /EnableCheckScriptCircularRefs
И как Вы заметили по предыдущей картинке в случае включенной проверки на цикличность ссылок, работа приложения будет завершена. Иногда это может вызывать проблемы со стороны пользователей. Для того что бы работа продолжалась можно или использовать технологический журнал со специальными настройками, или разработчику использовать метод глобального контекста

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

А если Мы его применим в любом другом месте кода:

&НаСервере
Процедура ПроверитьНаСервере ()
ЦиклическиеСсылки = ПроверитьЦиклическиеСсылкиВстроенногоЯзыка ();
КонецПроцедуры
&НаКлиенте
Процедура Проверить ( Команда )
ПроверитьНаСервере ();
КонецПроцедуры

То таблица ЦиклическиеСсылки будет пустая.

Таким образом можно сделать вывод, что метод носит узконаправленный характер и может пригодиться только для отладки небольшого куска кода. Нельзя его использовать для проверки конфигурации в целом. Разработчики платформы рекомендуют его использовать только для отладки, т.к. этот метод очень сильно загружает 1С: Предприятие
Теперь вернемся к таблице значений ЦиклическиеСсылки и посмотрим что она возвращает.
Для этого я поставлю точку останова на конце процедуры ТестНаСервере, а потом раскрою таблицу значений в таблоКак видно у таблицы значений две колонки – «ОписаниеЗначения» (тип строка) и «ЭлементыЦиклическихСсылок» (тип Массив).
В первой колонке содержится название переменной, где найдена циклическая ссылка. А вот вторая колонка, где массив, интереснее. Посмотрим на рисунках что в составе этого массива.

В этом массиве содержатся строки цикла ссылок, разделенные запятым. Разберем на примере строки с массивом (первый рисунок). Первое значение строки – сама переменная с которой все начинается, второе значение Массив[2] – элемент переменной, который ведет к зацикливанию, в нашем случае это Массив.Добавить(Структура), а последняя строка – переменная на которую вышел цикл, т.е. опять Массив.
Поэтому с этим методом очень удобно отлаживать код программы, что бы узнать, где и когда у нас пошло зацикливание.
На этом я закончу изучать работу с циклическими ссылками, если Вам что не понятно, то пишите в комментариях к этой статье, и мы вместе постараемся разобрать возникшие вопросы.

Отличное пособие по разработке в управляемом приложении 1С, как для начинающих разработчиков, так и для опытных программистов.

1. Очень доступный и понятный язык изложения
2. Книга посылается на электронную почту в формате PDF. Можно открыть на любом устройстве!
3. Поймете идеологию управляемого приложения 1С
4. Узнаете, как разрабатывать управляемое приложение;
5. Научитесь разрабатывать управляемые формы 1С;
6. Сможете работать с основными и нужными элементами управляемых форм
7. Программирование под управляемым приложением станет понятным

Если Вам помог этот урок решить какую-нибудь проблему, понравился или оказался полезен, то Вы можете поддержать мой проект, перечислив любую сумму:

можно оплатить вручную:

Читайте также:

  
• 1с зкбу что это
  
• Сделайте сравнительный анализ статистики использования различных браузеров
  
• При помощи powerpoint невозможно создание
  
• Программа picsart для компьютера
  
• 1с обновить классификатор адресов