Инструкция по настройке контроля сбоев с помощью Агента ЦКК.

В данной инструкции приводится способ настройки Агента ЦКК для контроля аварийного завершения (с образованием дампов) и зависания серверных процессов кластера 1С:Предприятие (только rmngr и rphost). Для выполнения шагов инструкции нам понадобится дистрибутив Агента ЦКК или установленный Агент ЦКК версии 1.0.6.1 или выше, утилита procdump.exe и Java SE Runtime Environment.

Установка Агента ЦКК

На экране приветствия нажмите кнопку «Далее»:

Затем выберите каталог установки Агента ЦКК. Рекомендуется выбирать каталог, предлагаемый по умолчанию:

На следующем экране выберите каталог установки Java SE Runtime Environment:

Далее выберите пользователя от имени которого будет работать служба Агента ЦКК (по умолчанию — LocalSystem).

Если вы хотите использовать Агента ЦКК без взаимодействия с информационной базой Цента контроля качества — установите флаг «Работать автономно»,

в другом случае заполните реквизиты подключения к публикации ЦКК. В данной инструкции будет использоваться настройка «Работать автономно».

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

При использовании опции «Выполнять сбор дампов аварийного завершения» убедитесь в том, что каталог экспорта дампов существует.

Дампы зависших процессов снимаются Агентом ЦКК с помощью утилиты procdump.exe, убедитесь, что ее файл присутствует в указанном каталоге.

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

Настройка технологического журнала, необходимого для диагностики зависания процессов приводится ниже в разделе «Настройка технологического журнала»

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

Update. В версии Агента ЦКК 1.0.7.1 параметр «Каталог тех. журнала» был переименован в «Каталог настройки или сбора тех. журнала». Логика обработки этого параметра была дополнена:

В параметре «Каталог настройки или сбора тех. журнала» рекомендуется указывать именно каталог настроек технологического журнала, т.к. этот способ является более безопасным для работы кластера.
Это объясняется тем, что в случае использования некорректно настроенных технологических журналов Агент ЦКК не будет пытаться снимать дампы с процессов кластера. В случае изменения файла настройки технологического журнала Агент ЦКК автоматически скорректирует директории для анализа.

Нажмите кнопку «Далее», дождитесь окончания установки Агента ЦКК и завершите программу установки:

Настройка технологического журнала

Для того, чтобы Агент ЦКК смог диагностировать зависание какого-либо процесса кластера 1С:Предприятие, необходимо настроить технологический журнал таким образом, чтобы собирались события CALL и SCALL (без ограничения по длительности, а так же без других фильтров).

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

Файл настроек settings.xml Агента ЦКК

Настройки Агента ЦКК можно изменить в файле settings.xml, который находится в каталоге установки Агента. Пример пути к файлу настроек: » C:\Program Files\1C\AgentQMC\1.0.6.1\settings.xml «.

Файл настройки имеет следующий вид:

В секции ConfPath > указывается каталог, содержащий файл conf.cfg (он хранит идентификатор агента).

В секции OffLine> указывается режим работы Агента: true — автономная работа, false — работа с публикацией ЦКК.

В секции находятся настройки сбора аварийных дампов.

А в секции располагаются настройки сбора дампов зависших процессов.

Источник

Центр контроля качества

Обзор основных возможностей и принципов работы

Качество работы системы — это ее соответствие бизнес-требованиям автоматизируемого предприятия, которое складывается из таких показателей, как производительность системы, ее масштабируемость и устойчивость.

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

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

Решаемые задачи

Центр контроля качества позволяет гарантировать эффективную и надежную работу системы на платформе 1С:Предприятие 8 за счет своевременного и правильного технического обслуживания системы. Это особенно важно для внедрений с высокими требованиями по производительности и надежности системы. При создании ЦКК был обобщен опыт технического обслуживания сотен корпоративных внедрений 1С:Предприятия 8.

Основные возможности

Общие принципы работы

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

При использовании центра мониторинга в ЦКК используются права для пользователей, работающих с центром мониторинга:

Также в ЦКК имеются специальные роли, назначаемые пользователям, от имени которых происходят обращения внешних систем к опубликованным в ЦКК веб-сервисам и HTTP-сервисам. Это роли Input statistics, Input incident tickets, PultQMC, АгентПолныеПрава, АгентПолныеПраваЦА и АгентПолныеПраваЦКК. Обычным пользователям, работающим с ЦКК в интерактивном режиме, эти роли не назначаются.

Начальное состояние

При первом запуске ЦКК открывается окно Начальная страница, которая содержит панели Площадки эксплуатации и Инциденты.

Настройка мониторинга информационной системы

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

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

Мониторинг

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

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

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

Для удобства представления ЦКК может собирать и отображать большое количество показателей, характеризующих работу контролируемой информационной системы, в едином окне «Монитор».

Инциденты и оповещения

Инцидент — это объект ЦКК, используемый для отслеживания тех ситуаций в работе контролируемой информационной системы, о которых может потребоваться собирать сведения и извещать ответственных.

На основании инцидентов ЦКК может создавать оповещения, которые отсылаются ответственным. Правила создания оповещений могут гибко настраиваться.

Для просмотра инцидентов в ЦКК используется панель Инциденты.

Инциденты могут быть нескольких уровней в зависимости от их критичности:

Значок	Уровень инцидента
	Критическая ошибка
	Ошибка
	Предупреждение
	Информация

При возникновении Инцидента ЦКК может создавать Оповещение для ответственных за эксплуатацию площадки лиц.

Отчеты и диаграммы

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

Источник

Мониторинг на продукционных серверах

Краткое содержание:

Общие сведения

ЦКК – Центр контроля качества, типовая конфигурация, входящая в Корпоративный инструментальный пакет.

ЦКК умеет собирать, агрегировать информацию и вовремя оповещать обо всех важных событиях в работе вашей системы.

Настройка всех контрольных процедур происходит на рабочем столе конфигурации.

Рис.1 ЦКК Рабочий стол

Общая настройка ЦКК возможна в мастере настроек основных параметров (раздел Настройки).

Рис.2 ЦКК Мастер настроек основных параметров

В разделе Мониторинг вы сможете

Рис.3 ЦКК Мониторинг

В разделе Сервис вы сможете получить подробную аналитику по данным, которые собираются в ЦКК.

Для минимальной настройки ЦКК рекомендуется настроить несколько основных контрольных процедур:

Настройка каждой из указанных процедур не должна занимать более 5-10 минут.

Настройка всех контрольных процедур в ЦКК желательна, т.к. в этом случае вы сможете в полной мере использовать существующую функциональность ЦКК.

Не все контрольные процедуры имеет смысл настраивать на продукционных серверах (например, Контроль нагрузочных тестов).

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

Рис.5 ЦКК Включение технологического журнала

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

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

Контроль подключений

Рекомендуем начать с настройки контроля подключений.

Рис.6 ЦКК Контроль подключений

Задачи контроля подключений:

Минимальная настройка заключается в

Подробная инструкция по использованию web-сервиса находится на закладке Рекомендации на форме настройки Контроля подключений.

Если в случае сбоя вы хотите получать оповещения, например, каждые N секунд (в течение которых информационная база недоступна), вы можете добавить параметры оповещения при сбое.

После настройки контрольной процедуры не забудьте проверить в разделе Настройки \ Зоны ответственности

Рис.7 ЦКК Зоны ответственности

состав группы ответственных лиц, которую вы указали при настройке Контроля подключений.

Для работы контрольной процедуры Контроль производительности требуется, чтобы в контролируемую информационную базу была встроена подсистема оценки производительности из инструмента под названием «1С:Библиотека стандартных подсистем 8.2» (БСП), имеющего версию 2.1.2.23 или более позднюю. На момент написания статьи выпущена версия БСП 2.2.

Рис.8 ЦКК Контроль производительности

Для настройки контрольной процедуры необходимо указать

Экспорт файлов в указанный каталог настраивается в обработке ОценкаПроизводительности, входящей в комплект подсистемы БСП ОценкаПроизводительности.

Рис.9 БСП ОценкаПроизводительности Экспорт замеров производительности

Контроль потребления памяти

Рис.10 ЦКК Контроль потребления памяти

Для настройки контрольной процедуры необходимо указать

Контроль устойчивости системы

Контрольная процедура Контроль устойчивости системы предназначена для

Рис.11 ЦКК Контроль устойчивости системы

Для настройки контрольной процедуры необходимо указать

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

Гибкие оповещения

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

Рис.12 ЦКК Оповещения

Гибкость заключается в том, что вы самостоятельно можете указывать условия срабатывания оповещений по sms и/или e-mail.

Например, мы знаем, что информационная база в некоторой организации эксплуатируется 24/7. Это означает, что в системе всегда должны быть пользователи. Допустим, информационная база доступна, но по каким-то причинам пользователи не могут в ней работать, их сеансы завершаются. Хочется, как можно раньше узнать о том, что сеансов пользователей в системе крайне мало (что может свидетельствовать о сбое).

Другой пример: у вас есть 1000 клиентских лицензий. Сервис лицензирования кластера серверов 1С раздает лицензии. Хочется узнать, когда число сеансов приблизится к критичному, например, 950, таким образом иметь запас времени на принятие решения о необходимости активации дополнительных лицензий.

Обе указанные задачи (и многие другие) решаются достаточно простой настройкой. Требуется выбрать нужный показатель (например, Число сеансов), указать условие сравнения, пороговое значение, назначить период проверки и получателей.

Рис.13 ЦКК Показатель оповещения

Условия можно накладывать на показатель, рассчитанный за выбранный период в прошлом (т.е. отслеживать отклонения), так и указывать его абсолютное значение.

Внимание!
Все оповещения работают по уже собранным данным в ЦКК. Это обозначает, что для корректной работы оповещений необходимы работающие контрольные процедуры. Если контрольная процедура Контроль потребления памяти НЕ настроена, оповещения по числу сеансов работать НЕ будет.

Использование ЦКК для агрегации своих данных

ЦКК имеет встроенный web-сервис InputStatistics, который предназначен для того чтобы принимать данные от внешних источников, уникальных для вашей системы (для которых может и не существовать пока специализированной контрольной процедуры).

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

На вход принимается строка в формате

Например, могут быть следующие входные данные:

Уровни вложенности иерархии разделяются точкой ‘.’. Значение (число) всегда идёт после последней точки в строке. ЦКК автоматически сгруппирует значения в соответствие с заданной на входе иерархией. Значения могут храниться в разрезе узлов деревьев и листов.

Посмотреть полученную статистику можно в разделе Мониторинг, выбрав показатель «Счетчики»

Рис.14 Настройка счетчика в мониторинге

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

По выбранным счетчикам вы также можете настроить гибкие оповещения и получать e-mail и/либо sms, в случае отклонения выбранного счетчика (либо группы счетчиков) от заданной величины.

Пример настройки сбора данных по загруженности оборудования с помощью PowerShell (3.0 или 4.0) для Windows серверов с агрегацией данных в ЦКК.

Все указанные счетчики должны нормально собираться с помощью Performance Monitor. Если какие-то счетчики называются по-другому, замените их.

Обратите внимание! В файле настройки указаны счетчики для логических дисков C, D и E. Если таких дисков у вас нет, замените эти строки, либо удалите выбранные счетчики.

указываем путь до опубликованного веб-сервиса в ЦКК. Пусть требуется аутентификация для подключения к веб-сервису. Для этого, пусть пользователь будет “QMC”, а его пароль “QMC123”

Указываем один раз логин и пароль (например, “”, “123”)

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

## need one time to create password file wsInputStatistics.xml. If changed user profile or file deleted we need uncomment line below & run script interactly

Ставим комментарий на вторую строку. Должно получиться так:

На контролирующем сервере пользователь «QMC_WS» должен обладать соответствующими правами (на запуск скриптов PowerShell).

то всегда будет создаваться журнал, путь к которому указан в файле srv_perf.xm

то при безошибочной работе журнал создаваться не должен.

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

Настройка сбора технологического журнала производится в файле logcfg.xml

О расположении файла можно подробно прочитать в статье.

Структура файла logcfg.xml также подробно описана в статье.

При любой настройке технологического журнала следует всегда контролировать рост объема вашего журнала в течение некоторого времени.

Серверный технологический журнал

Настройка минимального технологического журнала может выглядеть следующим образом:

Такой технологический журнал будет

Зачем нужен такой журнал:

Ошибки блокировок на уровне технологической платформы всегда будут записаны в технологический журнал и будут иметь вид (текст в поле Descr будет включать в себя):

Такого (минимального) технологического журнала не достаточно для того чтобы расследовать возникшие ошибки. Для расследования ошибок необходимо использовать ЦУП или более подробный технологический журнал.

В предложенной настройке технологический журнал будет собираться в директорию C:\LOGS\All

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

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

Такая настройка позволяет собирать минимальный объем информации, на основании которого можно расследовать до 80% проблем, возникающих при работе технологической платформы. В случае крайне нестабильной работы системы будет занимать много места директория с дампами процессов ( C:\DUMPS ), т.к. в данном случае будут записываться полные снимки процессов в момент их аварийного завершения. В случае нестабильной работы рекомендуется настроить автоматический разбор дампов из такой директории, например, с помощью контрольной процедуру «Контроль устойчивости» в ЦКК. Директория с технологическим журналом (C:\LOGS\All) при нормальной работе не должна превышать пары сотен Mb за сутки (Конечно же, всё зависит от вашей нагрузки и конфигурации системы. Нужно учитывать, что оценка может оказаться очень грубой и некорректной). Т.к. по истечении заданного времени (history=»28″) «старый» технологический журнал будет автоматически удаляться технологической платформой (для того чтобы избежать забивания журналами дискового пространства) рекомендуется настроить автоматическое копирование (например, раз в сутки) всех журналов со сжатием (например, в zip) на другой ресурс с помощью планировщика операционной системы. Таким образом, вы будете иметь журналы за любой момент работы системы.

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

Файл настройки приведен для версии технологической платформы 8.3, в фильтре по полю Durationus указано время 20 секунд (в микросекундах). Все события, которые попадают в такой журнал (при нормальной работе системы такой журнал должен быть скромных размеров) должны быть предметом рассмотрения, в первую очередь события SDBL со свойством Func=CommitTransaction. Такие события будут иметь длительность внешней (вложенные транзакции технологической платформой не поддерживаются) транзакции. Если транзакция длится более 20 секунд (скорее всего, в рамках транзакции будут установлены транзакционные блокировки на какие-либо ресурсы), она может стать «виновником» ошибок блокировок. Также внимание стоит уделить длительным запросам.

Для расследования ошибок на управляемых блокировках необходим технологический журнал вида

Следует обратить внимание, что журнал может быть большого объема, а длительность его ротации в примере указана равной 4 часам.

Ниже приведен пример того, как можно провести расследование ошибок управляемых блокировок (на примере управляемых взаимоблокировок).

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

1. Создаем конфигурацию с регистром сведений РегистрСведений1. Регистр независимый, непериодический.

2. Делаем обработку, в которой есть две команды

3. Настраиваем технологический журнал

Получаем ошибку взаимоблокировки на управляемых блокировках. Смотрим в собранный технологический журнал.

10:58.515038-3,TLOCK,4,process=rphost,p:processName=test_lock3,t:clientID=41,t:applicationName=1CV8C,t:computerName=MOROZOV-AN,t:connectID=16,SessionID=8,AppID=1CV8C,Regions=InfoRg10.DIMS,Locks=’InfoRg10.DIMS Shared Fld11=»Test1″ Fld12=»Test2″‘,WaitConnections=,Context=’Форма.Вызов : ОбщаяФорма.РабочийСтол.Модуль.ПервыйУчастникНаСервере ОбщаяФорма.РабочийСтол.Форма : 19 : НаборЗаписейРегистрСведений1.Прочитать();’ 11:00.496028-3,TLOCK,4,process=rphost,p:processName=test_lock3,t:clientID=45,t:applicationName=1CV8,t:computerName=MOROZOV-AN,t:connectID=17,SessionID=10,Usr=DefUser,Regions=InfoRg10.DIMS,Locks=’InfoRg10.DIMS Shared Fld11=»Test1″ Fld12=»Test2″‘,WaitConnections=,Context=’Форма.Вызов : ОбщаяФорма.РабочийСтол.Модуль.ВторойУчастникНаСервере ОбщаяФорма.РабочийСтол.Форма : 50 : НаборЗаписейРегистрСведений1.Прочитать();’ 11:05.519001-0,TDEADLOCK,5,process=rphost,p:processName=test_lock3,t:clientID=45,t:applicationName=1CV8,t:computerName=MOROZOV-AN,t:connectID=17,SessionID=10,Usr=DefUser,DeadlockConnectionIntersections=’17 16InfoRg10.DIMS Exclusive Fld11=»Test1″ Fld12=»Test2″,16 17 InfoRg10.DIMS Exclusive Fld11=»Test1″ Fld12=»Test2″‘,Context=’Форма.Вызов : ОбщаяФорма.РабочийСтол.Модуль.ВторойУчастникНаСервере ОбщаяФорма.РабочийСтол.Форма : 58 : НаборЗаписейРегистрСведений1.Записать();’ 11:05.519003-16002,TLOCK,4,process=rphost,p:processName=test_lock3,t:clientID=45,t:applicationName=1CV8,t:computerName=MOROZOV-AN,t:connectID=17,SessionID=10,Usr=DefUser,Regions=InfoRg10.DIMS,Locks=’InfoRg10.DIMS Exclusive Fld11=»Test1″ Fld12=»Test2″‘,WaitConnections=16,Context=’Форма.Вызов : ОбщаяФорма.РабочийСтол.Модуль.ВторойУчастникНаСервере ОбщаяФорма.РабочийСтол.Форма : 58 : НаборЗаписейРегистрСведений1.Записать();’ 11:05.519024-1997023,TLOCK,4,process=rphost,p:processName=test_lock3,t:clientID=41,t:applicationName=1CV8C,t:computerName=MOROZOV-AN,t:connectID=16,SessionID=8,AppID=1CV8C,Regions=InfoRg10.DIMS,Locks=’InfoRg10.DIMS Exclusive Fld11=»Test1″ Fld12=»Test2″‘,WaitConnections=17,Context=’Форма.Вызов : ОбщаяФорма.РабочийСтол.Модуль.ПервыйУчастникНаСервере ОбщаяФорма.РабочийСтол.Форма : 26 : НаборЗаписейРегистрСведений1.Записать();’

5. Находим событие TDEADLOCK и выписываем свойства поля

DeadlockConnectionIntersections=’ 17 16 InfoRg10.DIMS Exclusive Fld11=»Test1″ Fld12=»Test2″, 16 17 InfoRg10.DIMS Exclusive Fld11=»Test1″ Fld12=»Test2″‘

10:58.515038-3,TLOCK,4,process=rphost,p:processName=test_lock3,t:clientID=41,t:applicationName=1CV8C,t:computerName=MOROZOV-AN,t:connectID=16,SessionID=8,AppID=1CV8C,Regions=InfoRg10.DIMS,Locks=’InfoRg10.DIMS Shared Fld11=»Test1″ Fld12=»Test2″‘,WaitConnections=,Context=’Форма.Вызов : ОбщаяФорма.РабочийСтол.Модуль.ПервыйУчастникНаСервере ОбщаяФорма.РабочийСтол.Форма : 19 : НаборЗаписейРегистрСведений1.Прочитать();’

установил разделяемую управляемую блокировку на поля регистра сведений

Locks=’InfoRg10.DIMS Shared Fld11=»Test1″ Fld12=»Test2″‘

Эту операцию первый участник выполнил из

Форма.Вызов : ОбщаяФорма.РабочийСтол.Модуль.ПервыйУчастникНаСервере ОбщаяФорма.РабочийСтол.Форма : 19 : НаборЗаписейРегистрСведений1.Прочитать();

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

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

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

Собственно, блокировка при записи

11:05.519024-1997023,TLOCK,4,process=rphost,p:processName=test_lock3,t:clientID=41,t:applicationName=1CV8C,t:computerName=MOROZOV-AN,t:connectID=16,SessionID=8,AppID=1CV8C,Regions=InfoRg10.DIMS,Locks=’InfoRg10.DIMS Exclusive Fld11=»Test1″ Fld12=»Test2″‘,WaitConnections=17,Context=’Форма.Вызов : ОбщаяФорма.РабочийСтол.Модуль.ПервыйУчастникНаСервере ОбщаяФорма.РабочийСтол.Форма : 26 : НаборЗаписейРегистрСведений1.Записать();’

Мы видим, что установить он её не смог и ждал в течение 1997023 микросекунд участника WaitConnections=17 т.е. с номером

Это же симметрично сделал второй участник взаимоблокировки.

Таким образом, мы по технологическому журналу полностью выяснили, что именно и как именно произошло.

6. В статье указан этот сценарий в разделе «Повышение уровня блокировки ресурса в рамках одной транзакции».

Для расследования причин неоптимальной работы запросов может оказаться полезным следующий технологический журнал (пример сделан для сервера СУБД MS SQL Server).

В примере настроены планы запросов (

). Не смотря на то, что сбор планов включается на СУБД для всех баз, планы будут записываться только для тех событий, которые удовлетворяют указанным фильтрам. Рекомендуем всегда настраивать как можно более тонко фильтрацию. В этом случае ваш журнал не будет значительного объема, а его разбор будет удобным. В примере приведена настройка фильтрации по информационной базе (MyInfoBase) и по пользователю (Василий).

Типичные причины неоптимальной работы запросов и методы оптимизации указаны в статье.

Клиентский технологический журнал

Наиболее распространенной задачей, в которой требуется настройка клиентского технологического журнала, является расследование длительного входа в систему. Для того чтобы расследовать, что именно пытается делать клиентского приложение (например, какую форму открывает?) нужен клиентский технологический журнал. Пример настройки полного клиентского технологического журнала ниже.

Рекомендуется в общем случае настраивать полный технологический журнал для анализа работы клиентских приложений. Такой журнал не будет большого объема (в виду того, что клиентское приложение одно, выполняет действий значительно меньше, чем сервер).

Внимание! Не настраивайте такой журнал на рабочем сервере.

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

Разбор технологического журнала

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

В случае если разбираем технологический журнал на Windows сервере, возможно использовать специально ПО, например, cygwin.

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

рис.15 Директория с технологическими журналами процессов кластера

Например, мы хотим получить группировку по полю Descr всех событий EXCP только по процессам rphost.

Вывод в виде таблицы с колонками

Например, мы хотим получить суммарную длительность событий DBMSSQL и SDBL с группировкой по последней строке стека на встроенном языке.

Вывод в виде таблицы с колонками:

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

Предположим, что мы хотим получить суммарную длительность ожиданий на управляемых блокировках. В этом случае query.pl изменится на tlock.pl

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

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

«\Memory(_Total)\Available Mbytes»
«\Process(«1cv8*»)\% Processor Time»
«\Process(«1cv8*»)\Private Bytes»
«\Process(«1cv8*»)\Virtual Bytes»
«\Process(«ragent*»)\% Processor Time»
«\Process(«ragent*»)\Private Bytes»
«\Process(«ragent*»)\Virtual Bytes»
«\Process(«rphost*»)\% Processor Time»
«\Process(«rphost*»)\Private Bytes»
«\Process(«rphost*»)\Virtual Bytes»
«\Process(«rmngr*»)\% Processor Time»
«\Process(«rmngr*»)\Private Bytes»
«\Process(«rmngr*»)\Virtual Bytes»
«\LogicalDisk(_Total)\Free Megabytes»
«\Processor(_Total)\% Processor Time»
«\Memory(_Total)\Pages/sec» «\System(_Total)\Processor Queue Length»
«\PhysicalDisk(_Total)\Avg. Disk Queue Length»
«\PhysicalDisk(*)\Avg. Disk Queue Length»
«\PhysicalDisk(*)\Avg. Disk Bytes/Read»
«\PhysicalDisk(*)\Avg. Disk Bytes/Write»
«\Network Interface(*)\Bytes Total/sec»

Добавить (настроить) такой набор счетчиков Performance Monitor можно командой

Внимание!
Имена счетчиков могут незначительно отличаться в зависимости от версии вашей операционной системы.Данные будут собираться каждые 5 секунд.
Рекомендуется также не забыть настроить планировщик задач на автозапуск выбранного счетчика, например, каждый час, если сбор данных ещё не запущен. Это нужно на те случаи, в которых возникает необходимость перезапускать продукционные серверы. Обычно в такие моменты о включении сбора данных Performance Monitor вспоминают в последнюю очередь.

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

Исходные файлы находятся в каталоге \1CITS\EXE\Scalability\i8105809

Источник