연습 3 - 중요 경로 및 대기 분석 이해
시나리오 및 활동이 예기치 않게 지연될 수 있습니다. 예를 들어 경우에 따라 Microsoft Edge 내에서 탭을 여는 데 예상보다 오래 걸릴 수 있습니다.
활동은 시작 이벤트에서 종료 이벤트로 흐르는 일련의 작업(일부는 순차적이고 일부는 병렬)로 정의됩니다. 추적의 모든 시작/끝 이벤트 쌍을 활동으로 볼 수 있습니다. 이 일련의 작업을 통해 가장 긴 경로를 중요 경로라고 합니다. 중요 경로에 대한 작업 기간을 직접 줄이면 전체 활동의 기간이 줄어듭니다.
활동을 완료한 프로세스와 스레드를 식별하고 활동이 완료된 시점부터 뒤로 작업하는 것이 좋습니다. 활동을 완료한 스레드를 분석하여 해당 스레드가 대부분의 시간을 소요한 방법과 실행 중, 준비 또는 대기 중 중에서 어떤 상태인지를 확인하면서 시작합니다.
상당한 실행 시간은 직접적인 CPU 사용량이 중요 경로의 기간에 영향을 미쳤을 수 있음을 나타냅니다. 준비 상태에서 소요된 시간은 다른 스레드가 중요 경로의 스레드가 실행되지 않도록 하여 중요 경로의 기간에 기여함을 나타냅니다. 대기 중 소요 시간은 현재 스레드가 대기하고 있는 중요 경로의 I/O, 타이머 또는 기타 스레드와 프로세스를 가리킵니다.
현재 스레드를 준비한 각 스레드는 중요 경로의 또 다른 연결일 수 있으며 중요 경로의 기간이 설명될 때까지 분석될 수도 있습니다.
필요한 모든 정보가 WPA의 CPU 사용량(정밀) 그래프와 표에 기록됩니다. 디스패처가 기록하는 CPU 사용량 이벤트는 컨텍스트 스위치와 연결됩니다. 이 표에서는 내부 전환된 스레드인 NewThread에 중점을 두며 각 행은 컨텍스트 전환을 나타냅니다. 데이터는 다음 이벤트 시퀀스에 대해 수집됩니다.
NewThread가 차단 함수 호출로 인해 외부 전환됩니다.
NewThread가 준비 스레드에서 실행할 준비가 됩니다.
NewThread가 내부 전환되어 이전 스레드가 외부 전환됩니다.
NewThread가 가 다시 외부 전환됩니다.
CPU 사용량(정밀) 표에서 흥미로운 열은 다음과 같습니다.
열 | 세부 정보 |
---|---|
% CPU 사용량 | 스레드가 전환된 후 새 스레드의 CPU 사용량. 이 값은 현재 표시되는 기간 동안 총 CPU 시간의 백분율로 표시됩니다. |
개수 | 행으로 표현되는 컨텍스트 전환 횟수. 개별 행의 경우 항상 1입니다. |
CPU 사용량(밀리초) | 컨텍스트 전환 후 새 스레드의 CPU 사용량. |
NewProcess | 새 스레드의 프로세스. |
NewThreadId | 새 스레드의 스레드 ID. |
NewThreadStack | 새 스레드가 내부 전환될 때 새 스레드의 스택. 일반적으로 스레드가 차단되었거나 대기 중인 내용을 나타냅니다. |
준비(초) | 스레드가 준비 큐에서 소요한 시간(선점 또는 CPU 부족으로 인해). |
ReadyingThreadId | 준비 스레드의 스레드 ID. |
ReadyingProcess | 준비 스레드를 소유하는 프로세스. |
ReadyThreadStack | 준비 스레드의 스택. |
ReadyTime(초) | 새 스레드가 준비된 시간. |
SwitchInTime(s) | 새 스레드가 내부 전환된 시간. |
대기(초) | 스레드가 논리적 또는 물리적 리소스에서 대기한 시간. NewThreadId가 ReadyingThreadId의 신호를 받으면 대기가 종료됩니다. |
1단계: UI 지연 문제에 대한 추적 캡처 및 열기
이 연습에서는 응답하지 않는 UI를 사용하는 더미 프로세스에 초점을 둡니다. 이 프로세스는 단추와 텍스트 상자가 있는 간단한 Windows Form 애플리케이션입니다. 단추를 클릭하면 텍스트 상자가 업데이트될 때까지 20초 동안 UI가 응답하지 않게 됩니다. 이 작업의 중요 경로를 분석할 것입니다.
여기에서 UIDelay.exe를 다운로드합니다.
UIDelay.exe를 시작합니다.
시작 메뉴에서 WPR을 엽니다.
추적 구성을 수정합니다.
첫 번째 수준 심사 및 CPU 사용량을 선택합니다.
성능 시나리오로 일반을 선택합니다.
세부 정보 수준으로 자세한 정보 표시를 선택합니다.
시작을 클릭합니다.
UIDelay.exe에서 클릭 단추를 클릭합니다.
- 텍스트 상자에 "완료!"가 표시될 때까지 기다립니다.
WPR에서 추적을 저장하고 WPA를 사용하여 엽니다.
추적 메뉴를 열고 기호 경로 구성을 선택합니다.
- 기호 캐시의 경로를 지정합니다. 기호에 대한 자세한 내용은 MSDN의 기호 지원 페이지를 참조하세요.
추적 메뉴를 열고 기호 로드를 선택합니다.
2단계: 지연된 UI 스레드 식별
중요 경로 분석을 수행하기 전에 먼저 활동 시작 및 중지 이벤트를 식별해야 합니다.
Graph 탐색기의 시스템 활동 노드에서 UI 지연 그래프를 찾습니다.
분석 탭에서 UI 지연 그래프를 끌어다 놓습니다.
UIDelay.exe 프로세스를 찾습니다.
그 시간은 약 20초여야 합니다. 이는 UIDelay.exe의 UI 스레드에서 20초의 지연이 있었음을 나타냅니다.
UI 스레드 식별자는 스레드 ID 열에 표시됩니다. 이 예제에서는 24174입니다. 컴퓨터에서 캡처한 추적에서는 이 값이 다릅니다. 스레드 ID를 기록해야 합니다.
전체 UIDelay.exe 시간 간격을 선택하고 마우스 오른쪽 단추를 클릭하고 확대합니다.
항상 분석하려는 영역을 확대해야 합니다. 관련 없는 활동에서 발생하는 노이즈 양을 줄입니다.
3단계: UI 지연 중요 경로 분석
스레드 ID 및 타임스탬프가 있는 분석 시작점을 갖게 되었으므로 활동 중요 경로를 자세히 조사하여 UI 스레드에서 20초 지연으로 이어지는 이벤트 시퀀스를 이해할 수 있습니다.
이 단계의 NewThreadId는 2단계(UIDelay.exe 프로세스의 스레드 24174)에서 식별한 스레드입니다.
CPU 사용량(정밀) 그래프를 추가하고 분석 탭에 추가하고 프로세스/스레드별 사용률 미리 설정을 적용합니다.
열 머리글을 마우스 오른쪽 단추로 클릭하고 NewThreadStack, ReadyThreadStack 및 CPU 사용량(ms) 열을 표시합니다.
Ready (us) [Max] 및 Waits (us) [Max] 열을 제거합니다. 이제 뷰포트가 다음과 같이 표시되어야 합니다.
NewProcess 열에서 UIDelay.exe 프로세스를 찾아서 확장하고 열 머리글을 클릭하여 Waits(us) [Sum]을 기준으로 정렬합니다.
UIDelay.exe 프로세스에서 NewThreadId를 검색하고 실행 중, 준비 또는 대기 중 상태에서 소요된 시간을 분석합니다.
다음 예제에서는 다음을 찾을 수 있습니다.
스레드가 CPU 시간을 10.025초 사용하고 있습니다.
스레드가 5.159초 동안 대기하고 있습니다.
스레드가 무시할 수 있는 시간(10ms) 동안 준비 상태에 있습니다.
참고 연습 2의 4단계에서 설명한 것과 동일한 방법론을 사용하여 CPU 사용량(샘플링됨) 그래프를 사용하고 UIDelay.exe 프로세스를 확인하여 10초 동안 CPU 활동을 분석할 수 있습니다.
NewThreadId가 기다리는 것이 무엇인지 알아보려면 NewThreadId 그룹을 확장하여 NewThreadStack을 표시합니다.
[루트]를 확장하고 대기로 이어지는 함수 호출을 식별합니다.
이 예제에서 UIDelay.exe 스레드 ID 24174는 단추 클릭 함수가 트리거될 때 기본 차단 함수 호출을 5.073초 동안 기다리고 있습니다.
5.021초는 ExecuteWMICall 함수 아래의 작업으로 인해 발생합니다.
35ms는 PingServer 함수 아래의 작업으로 인해 발생합니다.
3.1단계: ExecuteWMICall 코드 경로 확인
호출 스택을 ExecuteWMICall 아래로 더 확장하면 Thread.Sleep을 명시적으로 호출하여 실제로 UI 스레드가 5초 동안 절전 상태가 됩니다.
이러한 종류의 동작은 응답에 직접적인 영향을 주기 때문에 어떤 희생을 치르든 피해야 합니다. 코드에서 정보를 기다려야 하는 경우 별도의 스레드에서 비동기적으로 수행하고 이벤트 기반 메서드를 사용해야 합니다.
3.2단계: PingServer 코드 확인
호출 스택을 PingServer 아래로 더 확장하면 UI 스레드가 네트워크를 통해 Ping 명령을 보내므로 I/O 종속성이 있음을 알 수 있습니다.
지연은 매우 작지만(35ms) UI 스레드에서는 피해야 합니다. 보통 사용자는 100ms보다 큰 UI 지연을 보게 됩니다. 이 작업을 수행하면 총 활동 경과 시간이 100ms를 초과하여 응답에 대한 인식이 나빠질 수 있습니다.
이러한 작업은 별도의 스레드에서 비동기적으로 발생해야 하며 UI를 차단하지 않아야 합니다.