Маленькие секреты трассировки плат с операционными и инструментальными усилителями. Как же сделать эту трассировку

Е сли вы когда-либо обращались к своему Интернет-провайдеру или на технические форумы с жалобами на нестабильную связь, наверняка, команда «tracert» вам уже знакома. Специалисты поддержки нередко просят пользователей выполнить ее в командной строке и сообщить результат. Это помогает им определить источник неполадки.

Может быть, вас даже удивило, как непонятный набор символов способен помочь в решении сетевых проблем? Что означают эти числа, колонки и строки? Если желаете научиться применять и понимать tracert не хуже профессионалов, эта статья – для вас.

Назначение и применение Tracert на практике

T racert – не просто некая абстрактная команда, которую понимает командная строка, а полноценная программа. Точнее, служебное консольное (не имеющее оконного интерфейса) Windows-приложение, предназначенное для определения пути, по которому направляются сетевые пакеты от одного узла к другому. Имя приложения образовано от «trace route», что означает «трассировка маршрута».

Программа Tracert является собственным компонентом Windows (устанавливается на компьютер вместе с ОС), ее исполняемый файл – TRACERT.exe, постоянно находится в папке %windir%/system32.

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

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

Обратите внимание на сходство этих записей:

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

  • На каком уровне происходит блокировка недоступного веб-ресурса: на уровне домашней сети (пакеты не отсылаются дальше шлюза), в сети провайдера или за ее пределами.
  • Где пакеты сбиваются с правильного маршрута. Например, причиной того, что вместо запрашиваемого , может быть и вредоносная программа на компьютере пользователя, и перенаправление с какого-либо сетевого узла.
  • Является ли веб-ресурс тем, за что себя выдает.

Как работает трассировка

К ак вы знаете, приложение запускается и выполняется в командной строке Windows. Чаще всего оно используется без дополнительных параметров. Команда трассировки маршрута к нужному веб-ресурсу выглядит так:

tracert URL_сайта или IP_сайта. Например, tracert Mts.ru , tracert 91.216.147.50

Ответом на нее будет примерно следующее:

Ниже я поясню, что означают эти числа и записи, а сначала, чтобы было понятно, рассмотрим принцип работы трассировщика.

Как только вы введете вышеуказанную инструкцию в командную сроку и нажмете Enter, приложение отправит заданному веб-ресурсу серию из трех ICMP-пакетов. В одном из служебных полей каждого пакета указано значение TTL – количество допустимых передач между узлами сети или, как говорят,«время жизни» запроса. При переходе отправления от роутера к роутеру значение TTL уменьшается на единицу. Когда оно достигает нуля, пересылка прекращается, пакет отбрасывается, а компьютер-отправитель получает об этом ICMP-уведомление.

Значение TTL первой партии ICMP-запросов равно 1. Первый же узел, на который она поступит, вычтет из этого значения единицу. Так как «время жизни» пакетов станет равным нулю, они будут выброшены «на свалку истории», а отправитель получит ответное «письмо» с указанием имени и IP-адреса этого узла.

Значение TTL второй партии будет равно двум (ответ будет получен от второго узла), третьей – трем и т. д. Отправка с увеличением TTL на 1 будет продолжаться до тех пор, пока данные не получит адресат.

Как читать результат трассировки

В ернемся к анализу вывода Tracert. Мой запрос к сайту Yandex.ru совершил 16 прыжков – прошел через 15 «перевалочных пунктов» и шестнадцатым шагом достиг конечной цели. Порядковые номера прыжков отображены в столбце, обведенном красной рамкой. По умолчанию их максимальное число составляет 30.

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

Последний столбец – это имена и адреса промежуточных и конечного узлов.

Звездочки вместо значений не всегда указывают на недоступность или неисправность сетевого устройства (как пишут в некоторых источниках). Чаще всего это просто настройка, не позволяющая отправлять ответные ICMP-сообщения (меры по защите веб-узла от DDoS-атак). Если ваш запрос благополучно достиг конечной точки за приемлемое время, беспокоиться не о чем.

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

Параметры Tracert

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

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

Tracert – w 1000 yandex. ru , что означает: провести трассировку маршрута к yandex.ru с таймаутом ответов в 1000 ms.

Ниже приведен список параметров с их значениями.

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

Ещё на сайте:

Какие секреты поможет узнать команда Tracert обновлено: Декабрь 5, 2016 автором: Johnny Mnemonic

Время от времени в своей работе технический специалист сталкивается с проблемами различных этапов функционирования операционной системы Windows: проблемами загрузки, завершения, гибернации, сна и прч. В подавляющем большинстве случаев подобные инциденты проявляются в том, что операционная система долго стартует, либо долго завершается, визуально это может выражаться как непривычно долго "висящие" на экране надписи , Завершение работы либо с курсором или без при загрузке/завершении. Иногда подобные этапы могут затянуться очень уж надолго, переходя все грани приличия. К решению подобного рода проблем существует множество подходов, одни состоят в использовании проверенного временем “метода тыка”, когда отключаются стоящие в автозапуске программы, сервисы этапа загрузки, другие же являются более продвинутыми и заключаются в применении специализированного диагностического инструментария от команды Microsoft, который позволяет получить о проблеме достаточно подробную информацию. В данной статье мы будем рассматривать, пожалуй, один из самых результативных способов диагностики проблем загрузки и завершения Windows - использование утилит комплекта Windows Performance Toolkit, таких как xbootmgr , xperf , xperfview .

Сделаем небольшое отступление и поговорим об общих причинах подобного поведения системы. В общем случае, медленная загрузка/завершение Windows может быть вызвана проблемами в работе драйверов устройств (обычно сторонних), сервисов либо приложений этапа загрузки, стартующих на различных этапах загрузки ОС. Теоретически, любой компонент операционной системы, стартующий на этапах загрузки/завершения ОС, может являться источником существенного увеличения времени, требующегося для выполнения всех фаз процесса загрузки/завершения. Причиной может быть как некорректное проектирование данного программного обеспечения, так и неисправность аппаратной части компьютера. К примеру, программа может выполнять многочисленные (избыточные) обращения к реестру, что, в свою очередь, так же может являться причиной общего падения производительности.
Для того, чтобы локализовать проблему с точностью до участка кода проблемного компонента, Microsoft предлагает широкому кругу специалистов набор специализированных утилит для диагностики различных аспектов быстродействия системы, который носит название Windows Performance Toolkit . Инструментарий Windows Performance Toolkit использует технологию Трассировки Событий (Event Tracing for Windows, ETW). На самом деле, ETW это довольно обширная область знаний, изучение которой представляет особый интерес для специалиста и описание которой может развернуться на добрую серию статей, однако здесь я приведу лишь основные термины.

Event Tracing for Windows - Средство трассировки событий. Технология, предоставляющая возможность генерации (при помощи специального API) сообщений состояния для широкого спектра событий, возникающих в операционной системе Windows.

Сказать иначе, это своеобразный расширяемый механизм логирования, встроенный в систему Windows. Реализован на уровне ядра, позволяет по запросу собирать события от приложений пользовательского режима, драйверов режима ядра и непосредственно кода самого ядра. Дело в том, что во многие компоненты ядра Windows, да и некоторые драйверы устройств включена возможность отслеживания операций с целью дальнейшего использования накопленной статистики при поиске причин системных сбоев. ETW предоставляет обширнейшую информацию по функционированию, как то, переключение контекста, статистика по прерываниям, отложенные вызовы процедур (DPC), процедуры обработки прерываний (ISR), создание и уничтожение процессов и потоков, дисковый ввод-вывод, ошибки страниц, переходы процессора между режимами в рабочем состоянии (p-state), операции с реестром, и многое другое. Предоставляется возможность включать запись событий "на лету", без необходимости перезагрузки системы либо приложения. События трассировки содержат заголовок события и зависящие от поставщика (провайдера) данные, описывающие текущее состояние приложения или операции.

Провайдер (поставщик) - любой компонент системы (приложение, библиотека, ядро, драйвер, сервис), использующий API Event Trace for Windows, предоставляющий события по запросу. Определяет глобальные идентификаторы (GUID) для классов событий, данные по трассировке которых он предоставляет.

Сам по себе инструментарий Windows Performance Toolkit содержит достаточно большое количество средств диагностики, из которых, в свете решения проблем различных этапов работы операционной системы, нас будет интересовать лишь несколько приложений, это утилиты xbootmgr , xperf и xperfview .

  • xperf - контроллер провайдеров и сессий трассировки. Утилита командной строки, имеющая широкий функционал: контроль процесса трассировки, обработка данных трассировки (поддержка анализаторов, называемых действиями, которые генерируют отчет об отдельных составляющих трассировки), старт/останов сессий трассировки, фильтрация собираемых событий, постобработка данных трассировки (конвертация из ETL в XML, объединение данных трассировки, добавление мета-данных в трассировку). В дополнение к основному функционалу, утилита может использоваться как анализатор результатов, однако, поскольку запускается только из командной строки, для визуализации вывода все-равно использует xperfview. Интересная особенность утилиты заключается в том, что она может использоваться как отдельный трассировщик событий уровня ядра прямо в процессе работы операционной системы.
  • xbootmgr - контроллер провайдеров и сессий трассировки. По сути тот же xperf , предназначенный для автоматизации определенных сценариев: по заданным условиям запускает/останавливает сеансы регистрации, автоматизирует процедуры изменения состояний операционной системы, выполняет автоматическую перезагрузку системы заданное количество раз, контролирует трассировку на всем протяжении переключений состояний, позволяет коллекционировать статистику по строго определенным системным событиям (загрузка, завершение, переход в/из режим сна, ожидание).
  • xperfview - потребитель, получатель или визуализатор результатов производительности с графическим интерфейсом. Основное назначение - извлечение данных трассировки из файлов протоколов сессий ETW и представление их в графическом виде в форме графиков и таблиц. По моему мнению, наиболее удобный инструмент для анализа результатов трассировки.

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

ETL - Event Trace Logs, собственный формат данных, хранящихся в виде набора записей, содержащих ETW-заголовок отслеживаемого события, который состоит из отметки времени, идентификатора процесса и потока и класса событий. Классы представляют дополнительные данные, характерные для своих событий.

Своим появлением ETW существенно расширила функционал встроенной системы журналирования Windows, благодаря чему она научилась получать данные от системных и пользовательских провайдеров ETW. В повседневной работе Вы можете наблюдать данные события через службу Журнала Событий, в оснастке "Просмотр Событий" (в разделе "Журналы приложений и служб"), потому как Служба событий может подписываться на любые события, которые предоставляет ETW посредством провайдеров событий.
Одна из основных особенностей ETW, поддерживаемой в WPT, заключается в поддержке символов для декодирования и профилирования стеков вызовов потоков, что дает возможность увидеть виновника сбоя вплоть до функции в коде, эта возможность крайне полезна и открывает такие перспективы, как отладка без отладчика.

Установка и настройка

На более-менее живой системе установить набор Windows Performance Toolkit может посредством полного инсталлятора Windows SDK. Я уже подробно описывал процесс , по ней можно с легкостью установить и Windows Performance Toolkit. Просто во время установки не забудьте отметить пункт "Windows Performance Toolkit". Помните, что лучше было бы установить дистрибутив, соответствующий разрядности Вашей платформы. По окончании установки рабочий каталог инструментария при установке из пакета: C:\Program Files\Microsoft Windows Performance Toolkit , при установке посредством онлайн-инсталлятора: C:\Program Files (x86)\Windows Kits\XX\Windows Performance Toolkit , хотя пути могут в будущих дистрибутивах и измениться.
Несколько сложнее дела обстоят с системой, в которой имеются проблемы загрузки в нормальном режиме. Дело в том, что..

WPT невозможно установить в безопасном режиме, по той причине что Служба установщика Windows недоступна в безопасном режиме, и это при том что WPT поставляются в виде.msi-файла. Теперь представьте распространенную ситуацию: система не грузится в нормальном режиме, и в то же время Вы не можете поставить средство диагностики в безопасном:)

Для выхода из подобных обстоятельств имеется три решения:

  1. компоненты WPT могут работать в качестве переносных приложений, достаточно скопировать с рабочей системы каталог Microsoft Windows Performance Toolkit и использовать его в качестве портабельной версии. Единственное, учитывайте разрядность систем!!
  2. можно использовать хитрый твик реестра для установки.msi в безопасном режиме.
  3. можно использовать альтернативное решение - утилиту в режиме протоколирования этапа загрузки.

Запуск трассировки

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

  1. Все нижеописанные действия рекомендуется производить не просто из командной строки, запущенной из-под учетной записи, входящей в группу "Пользователи журналов производительности" либо "Администраторы", а непосредственно из сеанса любой административной учетной записи во избежание проблем с доступом к провайдерам ядра в ходе многочисленных перезагрузок.
  2. Во всех случаях трассировки проблем этапов загрузки операционной системы Windows рекомендуется настроить автоматический вход пользователя в систему, дабы время, затраченное на ввод пароля пользователем, не повлияло существенно на измерения. Хотя я этого не делал.

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

xbootmgr -trace boot -traceflags BASE+CSWITCH+DRIVERS+POWER -numruns 1 –stackwalk Profile+CSwitch -resultpath C:\TEMP

Для трассировки этапа завершения выполняем команду:

xbootmgr -trace shutdown -traceflags BASE+CSWITCH+DRIVERS+POWER -numruns 1 –stackwalk Profile+CSwitch -resultpath C:\TEMP -noprepreboot

После выполнения данной команды, контроллер xbootmgr передает ETW-коду в ядре информацию о классах событий, к отслеживанию которых необходимо приступить.
Небольшая ремарка: для хранения результатов я использую директорию для временных файлов системы, описанную в переменной %TEMP% , у меня обычно это традиционно C:\TEMP . Соглашусь, что порой достаточно проблематично найти требуемый файл результатов в нагромождении временных файлов, однако это мой личный выбор, Ваше же право использовать произвольную целевую директорию.
Думаю, опции командной строки утилиты xbootmgr требуют дополнительного пояснения:

Опция Описание
-trace Режим трассировки.
  • boot - трассировка этапа загрузки ОС;
  • hibernate - трассировка режима гибернации и выхода из него;
  • standby - трассировка спящего режима и выхода из него;
  • shutdown - трассировка этапа завершения работы ОС;
  • rebootCycle - трассировка полного цикла перезагрузки: этапов загрузки и завершения работы ОС;
-traceFlags Флаги трассировки. Так называемые "флаги" представляют собой провайдеры событий, с помощью которых можно получить доступ к тем или иным событиям.
Более подробную информацию о провайдерах можно получить командой xperf -help providers . По-умолчанию используются опции BASE+CSWITCH. Описаны ниже.
-numRuns Количество повторений заданной стадии.
-resultPath Целевой каталог для формирования файла отчета. Опция задает режим мониторинга контроллера - запись результатов в файл. По-умолчанию логи сохраняются в директории %WINDIR%\System32 .
-stackWalk Фильтр прохода по стеку. Используются для углубленного анализа событий с помощью логирования участков кода момента событий и их последующего анализа. В данной статье мы не будем рассматривать этот функционал. Вероятно, по-умолчанию используется комбинация ProcessCreate+CSwitch, однако данный факт не подтвержден.
-noPrepReboot Отключить предварительную подготовительную перезагрузку. Применяю эту опцию в случае трассировки этапа перезагрузки, поскольку она позволяет отлавливать некоторые баги.
-prepSystem Проводит подготовку системы перед началом очередного этапа трассировки. Подготовка, в зависимости от ситуации, может быть разной, но основная польза данного ключа состоит в запуске процесса дефрагментации диска.

Понятное дело, что у утилиты xbootmgr значительно больше опций командной строки, нежели представлено в моей таблице, самостоятельно Вы можете познакомиться с ними, выполнив команду xbootmgr -help .
По информации по опциям утилиты xbootmgr меня больше всего заинтересовала информация о флагах трассировки (провайдерах) и фильтре прохода по стеку. Как выяснилось позже, провайдеров представлено в системе достаточно большое количество, к тому же, провайдеры могут добавляться пользовательскими приложениям. Многие из этих провайдеров требуют дополнительного пояснения.

Флаг Описание
BASE Базовая информация. Какая именно?
PROC_THREAD Создание/удаление процесса или потока.
LOADER Загрузчик образов исполняемых файлов. События загрузки/выгрузки образа (библиотек, драйверов, программ) пользовательского режима или режима ядра.
PROFILE Профилирование процессора. Дискретное событие, происходящее каждую 1 миллисекунду. Во время работы xbootmgr профилировщик прерывает процессор с интервалом в 1 миллисекунду и записывает стек вызова выполняющихся потоков. Помогает исследовать расход процессорного времени и выявить медленный код.
CSWITCH Переключение контекста. Процедура сохранения контекста одной задачи и восстановления контекста другой. Количество переключений контекста в заданный промежуток времени?
COMPACT_CSWITCH Компактное переключение контекста. Чем отличается от обычного?
DISPATCHER Планировщик. Диспетчер, процесс, выполняющий принятие решений по переключению управления между задачами.
DPC События вызовов отложенных процедур.
INTERRUPT Прерывания. События возникновения программных и аппаратных прерываний.
SYSCALL Системные вызовы. Обращения кода пользовательского режима к функциям ядра для выполнения каких-либо задач. Фиксируется количество вызовов?
PRIORITY События по смене приоритета процесса/потока?
ALPC Усовершенствованных вызов локальной процедуры, Advanced Local Procedure Call. Средство межпроцессового взаимодействия для быстрого обмена сообщениями. Механизм доступен только для внутренних системных процессов и не доступен для пользовательского кода.
PERF_COUNTER Счетчики производительности процессов. Что имеется в виду?
DISK_IO Дисковый ввод-вывод.
DISK_IO_INIT Дисковый ввод-вывод. Инициализация.
FILE_IO Файловый ввод-вывод. Время и результат выполнения операций файловой системы.
FILE_IO_INIT Начало файлового ввода-вывода. Создание/Открытие.
HARD_FAULTS Ошибки обращения к странице (Hard Pagefaults, ошибки страниц), требующие ее считывания с диска, соответственно, требующие иногда существенного времени для завершения. Прерывание, генерируемое в случае попытки доступа программы к странице памяти, которая отображена на виртуальное адресное пространство процесса, но фактически не загружена в оперативную память. Отличаются от Pagefaults тем, что это не просто событие ошибки обращения к странице, но требует её фактической загрузки в память.
FILENAME Операции с файлами (создание / удаление / сводка).
SPLIT_IO Раздробленный (разделенный) ввод-вывод. Частота разделений операций ввода-вывода физического диска на несколько составных более низкоуровневых операций. Указывает на то, что запросы ввода-вывода были расщеплены на множественные запросы ввода-вывода физического диска из-за более низкоуровневых аппаратных средств работы с диском. Позволяет диагностировать время отклика диска. Помогает определить концепцию дефрагментации диска.
REGISTRY Активность системного реестра. Трассировка операций реестра.
DRIVERS Событий драйверов. Задержки.
POWER События электропитания.
NETWORKTRACE События сетевого уровня (такие как прием и передача TCP/UDP пакетов).
VIRT_ALLOC Операции с виртуальной памятью. Резервирование, передача, изменение, освобождение региона страниц в виртуальном адресном пространстве.
MEMINFO Информация об использовании памяти.
ALL_FAULTS Все ошибки страниц. Вероятно, отличаются от HARD_FAULTS тем, что включают еще и события Page_faults, то есть обычные ошибки обращения к странице, не требующие подгрузки с носителя.

Особенное внимание еще уделяется так называемым флагам прохода по стеку (Stack Walking Flags). Вероятно, это атомарные события, при которых код трассировки лезет в стек вызовов текущего потока для записи данных при наступлении конкретного события. Перечислю в виде списка, поскольку пока что нет глубокого понимания ситуации:

ProcessCreate, ProcessDelete, ImageLoad, ImageUnload, ThreadCreate, ThreadDelete, CSwitch, ReadyThread, ThreadSetPriority, ThreadSetBasePriority, Mark, SyscallEnter, SyscallExit, Profile, ProfileSetInterval, DiskReadInit, DiskWriteInit, DiskFlushInit, FileCreate, FileCleanup, FileClose, FileRead, FileWrite, FileSetInformation, FileDelete, FileRename, FileDirEnum, FileFlush, FileQueryInformation, FileFSCTL, FileDirNotify, FileOpEnd, SplitIO, RegQueryKey, RegEnumerateKey, RegEnumerateValueKey, RegDeleteKey, RegCreateKey, RegOpenKey, RegSetValue, RegDeleteValue, RegQueryValue, RegQueryMultipleValue, RegSetInformation, RegFlush, RegKcbCreate, RegKcbDelete, RegVirtualize, RegCloseKey, HardFault, PagefaultTransition, PagefaultTransition, PagefaultDemandZero, PagefaultCopyOnWrite, PagefaultGuard, PagefaultHard, PagefaultAV, VirtualAlloc, VirtualFree, PagefileBackedImageMapping, HeapRangeCreate, HeapRangeReserve, HeapRangeRelease, HeapRangeDestroy, HeapCreate, HeapAlloc, HeapRealloc, HeapFree, HeapDestroy, AlpcSendMessage, AlpcReceiveMessage, AlpcWaitForReply, AlpcWaitForNewMessage, AlpcUnwait, ThreadPoolCallbackEnqueue, ThreadPoolCallbackDequeue, ThreadPoolCallbackStart, ThreadPoolCallbackStop, ThreadPoolCallbackCancel, ThreadPoolCreate, ThreadPoolClose, ThreadPoolSetMinThreads, ThreadPoolSetMaxThreads, PowerSetPowerAction, PowerSetPowerActionReturn, PowerSetDevicesState, PowerSetDevicesStateReturn, PowerDeviceNotify, PowerDeviceNotifyComplete, PowerSessionCallout, PowerSessionCalloutReturn, PowerPreSleep, PowerPostSleep, PowerPerfStateChange, PowerIdleStateChange, PowerThermalConstraint, ExecutiveResource, PoolAlloc, PoolAllocSession, PoolFree, PoolFreeSession.

Вернемся к процедуре трассировки. После запуска вышеописанной команды, xbootmgr создает сессии (буфера в памяти) и начинает собирать информацию, поступающую через программные интерфейсы ETW от провайдеров, указанных пользователем (в нашем случае это BASE, CSWITCH, DRIVERS, POWER). Параллельно, в зависимости от режима работы xbootmgr, выполняются те или иные ключевые этапы (загрузка, завершение, сон, гибернация). Запомните, что в зависимости от опций утилиты, Вы должны быть готовы к мгновенной перезагрузке операционной системы, поэтому не забудьте предварительно сохранить рабочие данные!

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

На каждом из ключевых этапов сессии, по мере заполнения буферов, данные сбрасываются на диск в отдельные файлы трассировки. Затем все эти файлы, на последнем этапе, объединяются контроллером в один единственный формата.etl. Поэтому особенно нетерпеливые могут наблюдать несколько.etl файлов в целевой директории отчета, это говорит о том, что процесс сборки еще не завершен! В ходе сборки разрозненных данных трассировки, на каждом из этапов будет создаваться отдельный etl -файл отчета и выводиться такое вот предупреждение:

После того, как оно исчезнет с экрана, можно быть уверенным, что целевой файл отчетов консолидирован и процесс (или один из этапов) трассировки завершен, а в целевом каталоге у нас появится файл shutdown_BASE+CSWITCH+DRIVERS+POWER_1.etl (имя которого зависит от указанных в командной строке провайдеров).

Анализ результатов трассировки

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

Если в целевом каталоге имеется несколько файлов с расширением.etl , содержащих в названии суффикс premerge (например boot_BASE+CSWITCH+DRIVERS+POWER_1_km_premerge.etl ), то это означает, что процесс трассировки не завершен и идет сборка отчета.

В этом случае необходимо дождаться окончания процесса и склеивания файлов отчетов в один. Интервал сбора данных утилитой xbootmgr после загрузки системы на финальном этапе задается при помощью опции командной строки –PostBootDelay и по-умолчанию равен 120 секундам.

Просмотр отчета

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

  1. Открыть файл результатов через просмотрщик xperfview . Сделать это можно либо непосредственно запустив утилиту и выбрав пункты File -> Open , либо запустив xperfview с параметром командной строки, эквивалентным имени файла результатов трассировки.
  2. Сконвертировать.etl файл в.xml файл командой: xperf -i shutdown_BASE+CSWITCH+DRIVERS+POWER_1.etl -o shutdown_analysis.xml -a shutdown Затем открыть получившийся файл shutdown_analysis.xml в веб-браузере. Обратите внимание на опцию -a, которая задает фильтр вывода, она должна соответствовать конкретному режиму, в котором создавалась трасса, либо можно эту опцию просто убрать совсем.
  3. Открыть файл.etl утилитой xperf. Для этого выполняем команду: xperf shutdown_BASE+CSWITCH+DRIVERS+POWER_1.etl –a shutdown

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

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

Общий алгоритм

  1. При анализе проблем загрузки, определить на каком из этапов происходит основная задержка:
  • Pre Session Init (PreSMSS);
  • Session Init (SMSSInit);
  • Winlogon Init
  • Explorer Init
  • Post Boot
  • При анализе проблем завершения, определить, какой именно компонент завершается дольше обычного;
  • На графике, на котором виден проблемный компонент, выделить интересующий интервал, на нем по правой кнопке мыши вызвать меню и выбрать пункт Summary Table ;
  • В открывшемся окне по столбцам времени выполнения (содержащем слова Time), определить, какой из модулей (или процедур/функций) тратит изрядное время на свой функционал;
  • Пример

    Тут мы разберем показательный пример из личного опыта. На одной из корпоративных рабочих станций появились проблемы с выключением/перезагрузкой, этап завершения операционной системы Windows 7 тянулся неоправданно долго, порой доходя до десятков минут. Поэтому, сразу имейте в виду, что дальнейшие отчеты и анализ у нас будут показаны для этапа завершения операционной системы.
    Непосредственно после запуска утилиты xperfview и открытия файла трассировки, на экране появляется графическое представление результатов отчета. Картинка щелкабельна, поэтому Вы можете более внимательно ознакомиться с результатами нашей с вами трассировки:

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

    • CPU Sampling - Замеры используемого процессорного времени (в процентах).
    • CPU Frequency - Отслеживание изменения частоты процессора.
    • CPU Idle States - Состояния процессора.
    • Disk I/O - Дисковый ввод-вывод. Количество операций ввода-вывода.
    • Disk Utilization - Использование диска (в процентах).
    • Driver Delays >=100ms - Драйвера с задержкой, превышающей порог в 100 миллисекунд.
    • Process Lifetimes - Карта времени завершения процессов.
    • Hard Faults - Количество "тяжелых" ошибок страниц, требующих считывания информации с диска.
    • Services - Карта сервисов. Обращайте внимание на ключевое слово (у нас "stop") после имени сервиса. В нашем случае говорит о том, что мы трассировали этап завершения.
    • Winlogon - Основные контрольные точки этапа Winlogon.
    • Generic Events - Карта всех событий.

    Из всех, представленных на сриншотах, результатов интерес вызывают, пожалуй всего два раздела, а именно Services и Driver Delays >=100ms . Тут мы можем воочию наблюдать существенные отклонения от типовых диапазонов быстродействия. Три драйвера csc.sys , mup.sys , fltmgr.sys по какой-то необъяснимой причине очень долго выгружались. Так же и сервисы gpsvc и wuauserv завершались довольно продолжительное время.

    • %SystemRoot%\System32\Drivers\csc.sys - это драйвер удаленной файловой системы, мини-редиректор, поддерживающий функционал системного механизма автономных файлов и отвечающий за то, куда именно перенаправляются запросы ввода-вывода, к удаленной файловой системе или к локальному кешу (%SystemRoot%\CSC ). Драйвер поддерживает локальный кеш и обновляет кешированные данные при запросах ввода-вывода.
    • %SystemRoot%\System32\Drivers\mup.sys - Многосетевой UNC-поставщик, драйвер удаленной файловой системы, непосредственно показывающий (отображающий) системным драйверам файловых систем удаленную файловую систему. Является эдаким центральным хабом самого низкого уровня, обрабатывающим запросы ввода-вывода для доступа к удаленным файловым системам через UNC-пути (\\Server\User\Path) и маршрутизирующим ввод-вывод определенному редиректору.
    • %SystemRoot%\System32\Drivers\fltmgr.sys - диспетчер фильтров файловых систем или высокоуровневый обработчик запросов к файловой системе, отвечает за функционирование всех драйверов фильтров в системе, которые могут представлять из себя модули различного назначения: антивирусные файловые сканеры, репликаторы файлов, шифровщики файлов, резервное копирование файлов и прч.

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

    11 декабря 2016 в 17:48

    Маленькие секреты трассировки плат с операционными и инструментальными усилителями

    • Tutorial
    При проектировании плат
    Ничто не обходится так дёшево,
    И не ценится так высоко,
    Как правильная трассировка.


    В век интернета вещей и доступности изготовления печатных плат, причём не только по ЛУТ технологии, их проектированием часто занимаются люди, вся деятельность которых связана с цифровой техникой.

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

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

    Пример номер два. Трассировка простой схемы операционного усилителя



    Рис. 1. Схема усилителя на ОУ


    Рис. 2. Два варианта трассировки платы усилителя на ОУ

    Небольшой оффтопик, прямо не относящейся к теме сегодняшней статьи

    Настоятельно советую применять этот же приём при подаче питания и на другие типы микросхем, особенно АЦП, ЦАП и многочисленные выводы питания микроконтроллеров. Если вы используете встроенные аналоговые модули микроконтроллера - ADC, DAC, компараторы, источники опорного напряжен не поленитесь заглянуть в даташит и посмотреть какие блокировочные конденсаторы в каком количестве и куда необходимо ставить. Не помешает цепь развязки в виде фильтра или хотя бы сопротивления между основным цифровым питанием микроконтроллера и аналоговым. Аналоговую землю лучше размещать отдельным полигоном или экранным слоем, и соединять с основной землёй в одной точке, в некоторых случаях полезно через фильтр


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

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

    Пример номер один. Трассировка монитора тока потребления на инструментальном усилителе


    Рис. 3. Схема монитора тока с использованием инструментального ОУ

    На рисунке представлена схема измерителя потребляемого тока. Измерительным элементом служит сопротивление шунта включенное в цепь питания. Нагрузка на которой измеряется ток - R load. Измеряемое напряжение снимается с сопротивления R shunt и фильтруется с помощью симметричной цепи на элементах R1,R2,C1-C3. Микросхема U2 служит для подачи опорного напряжения. R4, C5 - выходной фильтр.

    При трассировке разумеется необходимо соблюдать все рекомендации которые были даны выше.


    Рис. 4. Два варианта трассировки платы усилителя на инструментальном ОУ

    Разберём недочёты, которые имеет левая схема:

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

    Не держите на стене заряженное ружьё. Однажды оно обязательно выстрелит и выберет для этого самый неудобный момент.

    Сегодня я расскажу, как сделать трассировку к сайту , т.е. выполнить команду в командной строке Windows. Для чего это вам может понадобиться?
    Обычно трассировка используется техническими специалистами для выявления проблем в сети. Например, у вас вдруг ни с того ни с сего в браузере перестал открываться какой-то конкретный сайт или открывается очень медленно. Вы с этой проблемой обращаетесь на форум своего интернет-провайдера. Там вас почти наверняка сразу попросят сделать трассировку до этого сайта и выложить результат.

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

    Как же сделать эту трассировку?

    Заходим на своем компьютере в “Пуск” – “Выполнить” (или можно нажать на клавиатуре одновременно клавиши Win+R ). Набираем команду cmd и жмем “ОК”:В открывшемся черном окне пишем команду и через пробел название интересующего нас сайта (вместо имени сайта можно использовать его IP-адрес):
    После этого нажимаем клавишу Enter на клавиатуре.

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

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

    Как видите, в моем случае трассировка далеко не прошла – остановка произошла где-то на оборудовании провайдера:

    Полученные данные нам, вероятно, потребуется предоставить на форум провайдера. Можно просто сделать скриншот этого окна, но лучше скопировать эти данные в виде текста. Для этого щелкаем правой клавишей мыши прямо в этом окне – далее выбираем пункт “Выделить все”:
    Затем жмем клавишу Enter на клавиатуре. Теперь весь текст находится в буфере обмена – можем вставить его в любой текстовый редактор или сразу в ответ на форуме (нажав правую кнопку мыши – “Вставить”, либо сочетанием клавиш Ctrl+V).

    В данной теме я хочу поговорить об очень полезном инструменте — SQL Server Profiler.

    Как описано на MSDN, приложение SQL Server Profiler - это графический пользовательский интерфейс для трассировки SQL, с помощью которого можно наблюдать за экземпляром компонента Database Engine. Приложение позволяет собирать и сохранять данные о каждом событии в файле или в таблице для последующего анализа. Данное приложение представляет исключительную важность в задачах анализа производительности исполняемых запросов, а также при анализе проблем параллельности работы в базе данных.

    На текущий момент Microsoft продвигает другой аналогичный инструмент — Extended Events и рекомендует пользоваться им, тем не менее я считаю полезным уметь работать и с инструментом Profiler.

    Настройка приложения

    В профайлере, начиная с версии 2005, в настройках приложения присутствует флажок «Показывать значения в столбце «Продолжительность» в микросекундах» (Show values in Duration column in microseconds). Данный флажок управляет как отображением значения в соответствующей колонке, так и значением, устанавливаемым для отбора по данной колонке. На мой взгляд, при работе с Profiler удобнее использовать микросекунды, поэтому советую данный флажок установить. Настройка находится в меню Сервис (Tools) → Параметры (Options).

    Общие параметры

    Запуск трассировки в Profiler

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

    1. Открыть приложение SQL Server Profiler
    2. Выбрать пункт основного меню «Файл» (File), в нем «Создать трассировку» (New Trace)
    3. В открывшемся диалоге подключиться к нужному экземпляру SQL Server
    4. В открывшемся окне настроить трассировку
    5. Запустить трассировку

    Настройка трассировки

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

    Вкладка общие

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

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

    Вывод данных трассировки может происходить:

    1. На экран в новом окне — вывод происходит на экран, при этом в дальнейшем трассировку можно будет сохранить как в файл, так и в таблицу в СУБД (даже если опции записи в файл и/или таблицу не были включены)
    2. Записывать в файл на диске (опционально) — дополнительно к выбранным опциям, данные будут записываться в файл на диске. Далее этот файл можно открыть через профайлер. Эта опция удобна для сохранения и/или для передачи трассировки.
    3. Записывать в таблицу базы данных (опционально) — дополнительно к выбранным опциям, данные будут записываться в таблицу базы данных. Далее, посредством возможностей предоставляемых СУБД, можно произвести анализ данных, например, найти самые длительные события или просуммировать общую длительность.

    Последним пунктом настройки предлагается установить время остановки трассировки, если это требуется.

    Перед продолжением настройки установим шаблон «Пустой» (Blank), имя трассировки может быть произвольным, все остальные флажки могут быть сняты.


    Основные свойства трассировки

    Вкладка выбора событий

    Событие - это действие экземпляра SQL Server Database Engine. Для анализа проблем, возникающих при работе с 1С, существуют определенные наборы событий, с которыми необходимо уметь работать.

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

    Помимо матрицы событий и их свойств, на форме присутствуют флажки: «Показать все события» (Show all events) и «Показать все столбцы» (Show all columns). При установленном флажке в матрице раскрываются все события/столбцы, при снятом остаются только выбранные. Помимо этого, флажок «Показать все столбцы» влияет на отображение данных в «Фильтры столбцов» — отображаемый список соответствует отображаемым столбцам в матрице. При этом, даже если столбец скрыт (не выбран в матрице и снят флаг «Показать все столбцы»), но отбор на него был установлен — отбор сработает.

    «Фильтры столбцов» (Column Filters) — открывает список столбцов по которым можно установить отборы. Если значение события при трассировке не подходит под значение отбора в столбце, данное событие не будет отражено в трассировке. Таким образом, можно установить отбор на информационную базу, по которой необходимо произвести трассировку.

    «Упорядочить столбцы» (Organize Columns) — используется для изменения (организации) порядка следования выводимых колонок.


    Выбор событий трассировки

    События для получения плана выполнения запроса

    Для того чтобы получить план запроса в Profiler следует добавить следующие события:

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

    Среди столбцов, выводимых в трассировке, рекомендуется включить: TextData, BinaryData, Reads, Writes, CPU, Duration, SPID.


    События для получения плана выполнения запроса

    Также полезно установить фильтры по длительности и базе данных. Как это сделать описано ниже в статье.

    Другие способы получения плана запроса (без использования Profiler) описаны в статье «Методы получения плана запроса в СУБД MS SQL Server»

    События для получения графа взаимоблокировки

    Для получения графа взаимоблокировки достаточно добавить одноименное событие Locks: Deadlock graph.

    Событие Deadlock graph возникает одновременно с классом событий Lock: Deadlock. Класс событий Deadlock graph предоставляет XML-описание взаимоблокировки.

    Среди столбцов, выводимых в трассировке, рекомендуется включить: EventSequence, SPID, StartTime, TextData.


    События для получения графа взаимоблокировки

    События для получения информации об эскалации

    Для получения информации об эскалации достаточно добавить событие Locks: Escalation.

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

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


    События для получения информации об эскалации

    Установка фильтров столбцов

    Установить фильтры можно нажав на кнопку «Фильтры столбцов».


    Установка отборов по столбцам

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

    Очень полезным фильтром является отбор по имени базы или ее идентификатору (если в экземпляре находится несколько баз, а трассировать необходимо какую-то определенную). Для установки фильтра по имени базы необходимо для колонки DatabaseName установить значение «Похоже на» или «Не похоже на». Стоит отметить: если установленному значению будут отвечать несколько баз, тогда события будут собираться по каждой из них. Второй вариант фильтрации событий по определенной базе — установка отбора по колонке DatabaseID. Узнать идентификатор базы данных можно выполнив запрос в SQL Server Management Studio:

    SELECT DB_ID("MyBase")

    SELECT DB_ID ("MyBase" )

    где MyBase — имя базы, для которой необходимо получить идентификатор.

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

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

    Работа с трассировкой

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

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

    Если трассировка приостановлена или остановлена, тогда ее можно возобновить.

    Помимо этого, в любой момент существует возможность очистить окно трассировки.

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

    Панель инструментов

    Для изменения настройки уже созданной трассировки необходимо ее приостановить (или остановить) и перейти в пункт меню Файл (File) → Свойства (Properties). Выполнив изменения в трассировке, ее можно запустить вновь.

    Работа с шаблонами трассировки

    Наличие готовых шаблонов трассировки экономит время на настройке новой трассировки, поэтому я рекомендую сохранять необходимые для работы шаблоны. Шаблоны можно создавать, изменять, экспортировать и импортировать; для данных действий предназначен раздел меню «Файл» (File) → «Шаблоны» (Templates).

    Создание шаблона

    Для создания шаблона трассировки можно воспользоваться пунктом меню «Файл» (File) → «Шаблоны» (Templates) → «Новый шаблон» (New template).

    Вторым (и на мой взгляд наиболее удобным) вариантом создания шаблона является сохранение настройки текущей трассировки в виде шаблона. Для этого требуется воспользоваться пунктом меню «Файл» (File) → «Сохранить как» (Save as) → «Шаблон трассировки» (Trace template)

    Сохранение трассировки

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

    Для того чтобы сохранить трассировку в файл, в меню присутствует пункт «Файл» (File) → «Сохранить как» (Save as) → «Файл трассировки» (Trace File). Для сохранения трассировки в таблицу существует аналогичный пункт меню: «Файл» (File) → «Сохранить как» (Save as) → «Таблица трассировки» (Trace Table)



    
    Top