CPU 분석
이 가이드에서는 평가 메트릭에 영향을 미치는 CPU(중앙 처리 장치) 관련 문제를 조사하는 데 사용할 수 있는 기술에 대해 자세하게 설명합니다.
평가별 분석 가이드의 개별 메트릭 또는 문제 섹션은 조사를 위한 일반적인 문제를 식별합니다. 이 가이드에서는 이러한 문제를 조사하는 데 사용할 수 있는 기술과 도구를 제공합니다.
이 가이드의 기술은 WPT(Windows Performance Toolkit)의 WPA(Windows Performance Analyzer)를 사용합니다. WPT는 Windows ADK(Windows Assessment and Deployment Kit)의 일부이며 Windows 참가자 프로그램에서 다운로드할 수 있습니다. 자세한 내용은 Windows Performance Toolkit 기술 참조를 참조하세요.
이 가이드는 다음 세 섹션으로 구성됩니다.
이 섹션에서는 Windows 10에서 CPU 리소스를 관리하는 방법을 설명합니다. |
|
이 섹션에서는 Windows ADK 도구 키트에서 CPU 정보를 보고 해석하는 방법을 설명합니다. |
|
이 섹션에는 CPU 성능과 관련된 일반적인 문제를 조사하고 해결하는 데 사용할 수 있는 기술 컬렉션이 포함되어 있습니다. |
배경
이 섹션에는 간단한 설명과 CPU 성능에 대한 기본 설명이 포함되어 있습니다. 이 항목에 대한 더 포괄적인 학습을 위해 Windows Internals, Fifth Edition을 권장합니다.
최신 컴퓨터에는 별도의 소켓에 설치된 여러 CPU가 있을 수 있습니다. 각 CPU는 각각 하나 또는 두 개의 개별 명령 스트림을 동시에 처리할 수 있는 여러 물리적 프로세서 코어를 호스트할 수 있습니다. 이러한 개별 명령 스트림 프로세서는 Windows 운영 체제에서 논리 프로세서로 관리됩니다.
이 가이드에서 프로세서와 CPU는 모두 논리 프로세서, 즉 운영 체제에서 프로그램 명령을 실행하는 데 사용할 수 있는 하드웨어 디바이스를 참조합니다.
Windows 10은 전원 관리, 전원 사용량 및 성능 균형, 사용량의 균형을 조정하여 프로그램 및 드라이버의 처리 요구 사항의 균형을 맞추는 두 가지 주요 방법으로 프로세서 하드웨어를 적극적으로 관리합니다.
프로세서 전원 관리
프로세서가 항상 작동 상태에 있는 것은 아닙니다. 실행할 준비가 될 명령이 없으면 Windows는 Windows Power Manager에서 결정한 대로 프로세서를 대상 유휴 상태(또는 C 상태)로 전환합니다. CPU 사용 패턴에 따라 프로세서의 대상 C 상태는 시간 경과에 따라 조정됩니다.
유휴 상태는 C0(활성, 유휴 아님)에서 점진적으로 저전력 상태까지 번호가 매겨진 상태입니다. 이러한 상태에는 C1(중지되었지만 시계는 여전히 사용하도록 설정됨), C2(중지되었고 시계 사용 안 함) 등이 포함됩니다. 유휴 상태의 구현은 프로세서에 따라 다릅니다. 그러나 모든 프로세서에서 더 높은 상태 번호는 더 낮은 전력 소비를 반영하지만 프로세서가 명령 처리로 돌아갈 수 있도록 대기 시간이 길어집니다. 유휴 상태에서 소요되는 시간은 에너지 사용 및 배터리 수명에 크게 영향을 미칩니다.
일부 프로세서는 명령을 능동적으로 처리하는 경우에도 성능(P-) 및 제한(T-) 상태에서 작동할 수 있습니다. P 상태는 프로세서가 지원하는 클록 주파수 및 전압 수준을 정의합니다. T 상태는 클록 주파수를 직접 변경하지는 않지만 일부 클록 틱에서 처리 작업을 건너뛰어 유효 클록 속도를 낮출 수 있습니다. 현재 P 상태 및 T 상태는 함께 프로세서의 유효 작동 빈도를 결정합니다. 낮은 주파수는 낮은 성능과 낮은 전력 소비에 해당합니다.
Windows Power Manager는 CPU 사용 패턴 및 시스템 전원 정책에 따라 각 프로세서에 대한 적절한 P 상태 및 T 상태를 결정합니다. 고성능 상태와 낮은 성능 상태에서 소요되는 시간은 에너지 사용 및 배터리 수명에 크게 영향을 미칩니다.
프로세서 사용률 관리
Windows는 세 가지 주요 추상화로 프로세서 사용률을 관리합니다.
프로세스
스레드
DPC(지연 프로시저 호출) 및 ISR(인터럽트 서비스 루틴)
프로세스 및 스레드
Windows의 모든 사용자 모드 프로그램은 프로세스의 컨텍스트에서 실행됩니다. 프로세스에는 다음 특성 및 구성 요소가 포함됩니다.
가상 주소 공간
우선 순위 클래스
로드된 프로그램 모듈
환경 및 구성 정보
하나 이상의 스레드
프로세스에는 프로그램 모듈, 컨텍스트, 환경이 포함되어 있지만 프로세서에서 실행되도록 직접 예약되지는 않습니다. 대신 프로세스에서 소유하는 스레드는 프로세서에서 실행되도록 예약됩니다.
스레드는 실행 컨텍스트 정보를 유지 관리합니다. 거의 모든 계산은 스레드의 일부로 관리됩니다. 스레드 작업은 측정 및 시스템 성능에 근본적으로 영향을 미칩니다.
시스템의 프로세서 수가 제한되어 있으므로 모든 스레드를 동시에 실행할 수 없습니다. Windows는 프로세서 시간 공유를 구현하여 프로세서가 다른 스레드로 전환되기 전에 스레드가 일정 기간 동안 실행될 수 있도록 합니다. 스레드 간 전환 작업을 컨텍스트 스위치라고 하며 디스패처라는 Windows 구성 요소에 의해 수행됩니다. 디스패처는 우선 순위, 이상적인 프로세서 및 선호도, 양자 및 상태에 따라 스레드 예약 결정을 내립니다.
우선 순위
우선 순위는 디스패처가 실행할 스레드를 선택하는 방법의 핵심 요소입니다. 스레드 우선 순위는 0에서 31까지의 정수입니다. 스레드가 실행 가능하고 현재 실행 중인 스레드보다 우선 순위가 높은 경우 우선 순위가 낮은 스레드가 즉시 선점되고 우선 순위가 높은 스레드의 컨텍스트가 전환됩니다.
스레드가 실행 중이거나 실행할 준비가 되면 두 스레드를 동시에 실행할 수 있는 프로세서가 충분하지 않거나 우선 순위가 높은 스레드가 사용 가능한 프로세서의 하위 집합에서만 실행되도록 제한되지 않는 한 우선 순위가 낮은 스레드는 실행할 수 없습니다. 스레드에는 특정 시간에 일시적으로 더 높은 우선 순위로 올라갈 수 있는 기본 우선 순위(예: 프로세스가 전경 창을 소유하는 경우 또는 I/O가 완료되는 경우)가 있습니다.
이상적인 프로세서 및 선호도
스레드의 이상적인 프로세서 및 선호도 는 지정된 스레드가 실행되도록 예약된 프로세서를 결정합니다. 각 스레드에는 프로그램 또는 Windows에서 자동으로 설정되는 이상적인 프로세서가 있습니다. Windows는 각 프로세스에서 거의 동일한 수의 스레드가 각 프로세서에 할당되도록 라운드 로빈 방법론을 사용합니다. 가능하면 Windows는 스레드가 이상적인 프로세서에서 실행되도록 예약합니다. 그러나 스레드는 때때로 다른 프로세서에서 실행되는 경우가 있습니다.
스레드의 프로세서 선호도는 스레드가 실행되는 프로세서를 제한합니다. 이는 스레드의 이상적인 프로세서 특성보다 더 강력한 제한 사항입니다. 이 프로그램은 SetThreadAffinityMask를 사용하여 선호도를 설정합니다. 선호도는 스레드가 특정 프로세서에서 실행되지 않도록 방지할 수 있습니다.
Quantum
컨텍스트 전환은 비용이 많이 드는 작업입니다. Windows는 일반적으로 각 스레드가 다른 스레드로 전환되기 전에 양자라고 하는 일정 기간 동안 실행할 수 있도록 허용합니다. 퀀텀 기간은 명백한 시스템 응답성을 유지하도록 설계되었습니다. 컨텍스트 전환의 오버헤드를 최소화하여 처리량을 최대화합니다. 퀀텀 기간은 클라이언트와 서버마다 다를 수 있습니다. 퀀텀 기간은 일반적으로 서버에서 더 길어서 명백한 응답성이 저하되더라도 처리량을 극대화합니다. 클라이언트 컴퓨터에서 Windows는 전체적으로 더 짧은 퀀텀을 할당하지만 현재 전경 창과 연결된 스레드에 더 긴 퀀텀을 제공합니다.
State(상태)
각 스레드는 지정된 시간에 특정 실행 상태에 있습니다. Windows는 성능과 관련된 세 가지 상태를 사용합니다. 실행, 준비 및 대기 중입니다.
현재 실행 중인 스레드는 실행 중 상태입니다. 실행할 수 있지만 현재 실행되고 있지 않은 스레드는 준비 상태입니다. 특정 이벤트를 대기 중이므로 실행할 수 없는 스레드는 대기 상태에 있습니다.
상태에서 상태로의 전환은 그림 1 스레드 상태 전환에 표시됩니다.
그림 1 스레드 상태 전환
그림 1 스레드 상태 전환은 다음과 같이 설명됩니다.
실행 중인 상태의 스레드는 WaitForSingleObject 또는 Sleep(> 0)과 같은 대기 함수를 호출하여 대기 상태로의 전환을 시작합니다.
실행 중인 스레드 또는 커널 작업은 대기 상태(예: SetEvent 또는 타이머 만료)에서 스레드를 준비합니다. 프로세서가 유휴 상태이거나 준비 스레드가 현재 실행 중인 스레드보다 우선 순위가 높은 경우 준비 스레드를 실행 중인 상태로 직접 전환할 수 있습니다. 그렇지 않으면 준비 상태로 전환됩니다.
준비 상태의 스레드는 실행 중인 스레드가 대기하거나, (Sleep(0))을 생성하거나, 퀀텀의 끝에 도달할 때 디스패처에서 처리하도록 예약됩니다.
실행 중인 상태의 스레드는 우선 순위가 높은 스레드가 선점되거나, (Sleep(0))을 생성하거나, 퀀텀이 종료될 때 디스패처에 의해 전환되어 준비 상태로 배치됩니다.
대기 상태에 있는 스레드가 반드시 성능 문제를 나타내는 것은 아닙니다. 대부분의 스레드는 대기 상태에서 상당한 시간을 보내며, 이를 통해 프로세서는 유휴 상태에 들어가고 에너지를 절약할 수 있습니다. 스레드 상태는 사용자가 스레드가 작업을 완료하기를 기다리는 경우에만 성능에서 중요한 요소가 됩니다.
DPC 및 ISR
프로세서는 스레드 처리 외에도 네트워크 카드 또는 타이머와 같은 하드웨어 디바이스의 알림에 응답합니다. 하드웨어 디바이스에 프로세서 주의가 필요한 경우 인터럽트를 생성합니다. Windows는 현재 실행 중인 스레드를 일시 중단하고 인터럽트와 연결된 ISR을 실행하여 하드웨어 인터럽트에 응답합니다.
ISR을 실행하는 동안 프로세서는 다른 인터럽트를 포함한 다른 작업을 처리하지 못하도록 방지할 수 있습니다. 이러한 이유로 ISR은 신속하게 완료해야 하며 그러지 않으면 시스템 성능이 저하될 수 있습니다. 실행 시간을 줄이기 위해 ISR은 일반적으로 인터럽트에 대한 대응으로 수행해야 하는 작업을 수행하도록 DPC를 예약합니다. 각 논리 프로세서에 대해 Windows는 예약된 DPC의 큐를 유지 관리합니다. DPC는 모든 우선 순위 수준에서 스레드보다 우선합니다. 프로세서가 처리 스레드로 돌아가기 전에 해당 큐의 모든 DPC를 실행합니다.
프로세서가 DDP 및 ISR을 실행하는 동안 해당 프로세서에서 스레드를 실행할 수 없습니다. 이 속성으로 인해 특정 처리량 또는 정확한 타이밍(예: 오디오 또는 비디오를 재생하는 스레드)에서 작업을 수행해야 하는 스레드에 문제가 발생할 수 있습니다. DDP 및 ISR을 실행하는 데 사용되는 프로세서 시간으로 인해 이러한 스레드가 충분한 처리 시간을 받지 못하는 경우 스레드는 필요한 처리량을 달성하지 못하거나 작업 항목을 제시간에 완료하지 못할 수 있습니다.
Windows ADK 도구
Windows ADK는 하드웨어 정보 및 평가를 평가 결과 파일에 기록합니다. WPA는 다양한 그래프에서 CPU 사용량에 대해 자세하게 설명합니다. 이 섹션에서는 Windows ADK 및 WPA를 사용하여 CPU 성능 데이터를 수집하고 보고 분석하는 방법을 설명합니다.
Windows ADK 평가 결과 파일
Windows는 대칭 다중 처리 시스템만 지원하므로 이 섹션의 모든 정보는 설치된 모든 CPU 및 코어에 적용됩니다.
자세한 CPU 하드웨어 정보는 <Processor><Instance id=”0”> 노드 아래 평가 결과 파일의 EcoSysInfo 섹션에서 사용할 수 있습니다.
예시:
<Processor>
<Instance id="0">
<ProcessorName>The name of the first CPU</ProcessorName>
<TSCFrequency>The maximum frequency of the first CPU</TSCFrequency>
<NumProcs>The total number of processors</NumProcs>
<NumCores>The total number of cores</NumCores>
<NumCPUs>The total number of logical processors</NumCPUs>
...and so on...
WPA 그래프
WPA에 추적을 로드한 후 WPA UI의 추적/시스템 구성/일반 및 추적/시스템 구성/PnP 섹션에서 프로세서 하드웨어 정보를 찾을 수 있습니다.
참고 이 가이드의 모든 프로시저는 WPA에서 발생합니다.
CPU 유휴 상태 그래프
유휴 상태 정보가 추적에서 수집되면 전원/CPU 유휴 상태 그래프가 WPA UI에 표시됩니다. 이 그래프는 항상 각 프로세서의 대상 유휴 상태에 대한 데이터를 포함합니다. 이 상태가 프로세서에서 지원되는 경우 그래프에는 각 프로세서의 실제 유휴 상태에 대한 정보도 포함됩니다.
다음 테이블의 각 행은 프로세서의 대상 또는 실제 상태에 대한 유휴 상태 변경에 대해 설명합니다. 그래프의 각 행에 사용할 수 있는 열은 다음과 같습니다.
| Column | 세부 정보 |
|---|---|
CPU |
상태 변경의 영향을 받는 프로세서. |
진입 시간 |
프로세서가 유휴 상태로 전환된 시간. |
종료 시간 |
프로세서가 유휴 상태를 종료한 시간. |
Max:Duration(ms) |
유휴 상태(기본 집계:최댓값)에서 소요되는 시간. |
Min:Duration(ms) |
유휴 상태(기본 집계:최소)에 소요되는 시간. |
다음 상태 |
프로세서가 현재 상태 이후 전환된 상태. |
이전 상태 |
프로세서가 현재 상태로 전환되기 전의 상태. |
State(상태) |
현재 유휴 상태. |
상태(숫자) |
현재 유휴 상태(예: C0의 경우 0). |
Sum:Duration(ms) |
유휴 상태(기본 집계:합계)에 소요되는 시간. |
테이블 |
사용 안 함 |
Type |
대상(Power Manager가 프로세서에 대해 선택한 대상의 상태) 또는 실제(프로세서의 실제 유휴 상태) |
기본 WPA 프로필은 이 그래프에 대해 형식별 상태, CPU 및 형식별 상태 다이어그램, CPU의 두 가지 미리 설정을 제공합니다.
형식별 상태, CPU
각 CPU의 대상 및 실제 상태는 형식별 상태, CPU 그래프에서 Y축의 상태 번호와 함께 그래프로 표시됩니다. 그림 2의 형식별 CPU 유휴 상태, CPU는 활성 상태와 대상 유휴 상태 간에 변동되는 CPU의 실제 상태를 보여 줍니다.
그림 2 CPU 유휴 상태, 형식별 상태, CPU
형식별 상태 다이어그램, CPU
이 그래프에는 각 CPU의 대상 및 실제 상태가 타임라인 형식으로 표시됩니다. 각 상태에는 타임라인에 별도의 행이 있습니다. 그림 3 형식별 CPU 유휴 상태 다이어그램, CPU는 타임라인 보기에서 그림 2 형식별 CPU 유휴 상태와 동일한 데이터를 표시합니다.
그림 3 형식별 CPU 유휴 상태 다이어그램, CPU
CPU 빈도 그래프
여러 P 상태 또는 T 상태를 지원하는 시스템에서 CPU 빈도 데이터가 수집된 경우 WPA UI에서 CPU 빈도 그래프를 사용할 수 있습니다. 다음 테이블의 각 행은 프로세서의 특정 빈도 수준에서 시간을 나타냅니다. 빈도(MHz) 열에는 프로세서에서 지원하는 P 상태 및 T 상태에 해당하는 제한된 수의 빈도가 포함되어 있습니다. 그래프의 각 행에 사용할 수 있는 열은 다음과 같습니다.
| Column | 세부 정보 |
|---|---|
% 기간 |
기간은 현재 표시되는 기간 동안 총 CPU 시간의 백분율로 표시됩니다. |
Count |
빈도 변경 횟수(개별 행의 경우 항상 1). |
CPU |
빈도 변경의 영향을 받는 CPU. |
진입 시간 |
CPU가 P 상태를 입력한 시간. |
종료 시간 |
CPU가 P 상태를 종료한 시간. |
주파수(MHz) |
P 상태에 있는 동안의 CPU 빈도. |
Max:Duration(ms) |
P 상태에 소요되는 시간(기본 집계:최댓값). |
Min:Duration(ms) |
P 상태에 소요되는 시간(기본 집계:최솟값). |
Sum:Duration(ms) |
P 상태에 소요되는 시간(기본 집계:합계). |
테이블 |
사용 안 함 |
Type |
P 상태에 대한 추가 정보. |
기본 프로필은 이 그래프에 대해 미리 설정된 CPU별 빈도를 정의합니다. 그림 4 CPU별 CPU 빈도는 세 P 상태 간에 전환되는 CPU를 보여 줍니다.
그림 4 CPU별 CPU 빈도
CPU 사용량(샘플링) 그래프
CPU 사용량(샘플링) 그래프에 표시되는 데이터는 정기적인 샘플링 간격으로 수집한 CPU 활동의 샘플을 나타냅니다. 대부분의 추적에서 1밀리초(1ms)입니다. 테이블의 각 행은 단일 샘플을 나타냅니다.
샘플의 가중치는 다른 샘플과 비교하여 해당 샘플의 중요성을 나타냅니다. 가중치는 현재 샘플의 타임스탬프에서 이전 샘플의 타임스탬프를 뺀 것과 같습니다. 가중치가 시스템 상태 및 활동의 변동으로 인해 항상 샘플링 간격과 정확히 같지는 않습니다.
그림 5 CPU 샘플링은 데이터를 수집하는 방법을 나타냅니다.
그림 5 CPU 샘플링
샘플 간에 발생하는 모든 CPU 활동은 이 샘플링 방법으로 기록되지 않습니다. 따라서 DPC 및 ISR과 같은 매우 짧은 기간의 활동은 CPU 샘플링 그래프에 잘 표시되지 않습니다.
그래프의 각 행에 사용할 수 있는 열은 다음과 같습니다.
| Column | 세부 정보 |
|---|---|
% 가중치 |
가중치는 현재 표시되는 시간 범위에서 소요된 총 CPU 시간의 백분율로 표시됩니다. |
주소 |
스택 맨 위에 있는 함수의 메모리 주소. |
모든 수 |
행으로 표시되는 샘플 수. 이 숫자에는 프로세서가 유휴 상태일 때 수집되는 샘플이 포함됩니다. 개별 행의 경우 이 열은 항상 1입니다. |
Count |
프로세서가 유휴 상태일 때 수집되는 샘플을 제외하고 행으로 표시되는 샘플 수. 개별 행의 경우 이 열은 항상 1(또는 CPU가 전원이 낮은 상태인 경우 0)입니다. |
CPU |
이 샘플을 가져온 CPU의 0 기반 인덱스. |
표시 이름 |
활성 프로세스의 표시 이름. |
DPC/ISR |
샘플에서 일반 CPU 사용량, DPC/ISR 또는 저전력 상태를 측정했는지 여부. |
함수 |
스택 맨 위에 있는 함수. |
모듈 |
스택 맨 위에 있는 함수를 포함하는 모듈. |
우선 순위 |
실행 중인 스레드의 우선 순위. |
Process |
실행 중인 코드를 소유하는 프로세스의 이미지 이름. |
프로세스 이름 |
실행 중인 코드를 소유하는 프로세스의 전체 이름(프로세스 ID 포함). |
Stack |
실행 중인 스레드의 스택. |
스레드 ID |
실행 중인 스레드의 ID. |
스레드 시작 함수 |
실행 중인 스레드가 시작된 함수. |
스레드 시작 모듈 |
스레드 시작 함수를 포함하는 모듈. |
TimeStamp |
샘플이 수행된 시간. |
Weight |
샘플(즉, 마지막 샘플 이후의 시간)으로 표현되는 시간(밀리초). |
기본 프로필은 이 그래프에 대해 다음과 같은 미리 설정을 제공합니다.
CPU별 사용률
우선 순위별 사용률
프로세스별 사용률
프로세스 및 스레드별 사용률
CPU별 사용률
CPU별 CPU 사용량 사용률 그래프는 프로세서 간에 작업이 분산되는 방식을 보여 줍니다. 그림 6 CPU별 CPU 사용량 사용률은 다음 두 CPU에 대한 분산을 보여 줍니다.
그림 6 CPU별 CPU 사용량 사용률
우선 순위별 사용률
스레드 우선 순위별로 그룹화된 CPU 사용량은 우선 순위가 높은 스레드가 우선 순위가 낮은 스레드에 미치는 영향을 보여 줍니다. 그림 7 우선 순위별 CPU 사용량(샘플링) 사용률은 다음 그래프를 표시합니다.
그림 7 우선 순위별 CPU 사용량(샘플링) 사용률
프로세스별 사용률
프로세스별로 그룹화된 CPU 사용량은 프로세스의 상대적 사용량을 보여 줍니다. 그림 8 프로세스별 CPU 사용량(샘플링) 사용률은 다음 미리 설정을 보여 줍니다. 이 샘플 그래프에서는 한 프로세스가 다른 프로세스보다 더 많은 CPU 시간을 소비하는 것으로 나타납니다.
그림 8 프로세스별 CPU 사용량(샘플링) 사용률
프로세스 및 스레드별 사용률
프로세스별로 그룹화된 다음 스레드별로 그룹화된 CPU 사용량은 각 프로세스의 프로세스 및 스레드의 상대적 사용량을 보여 줍니다. 그림 9 프로세스 및 스레드별 CPU 사용량(샘플링) 사용률은 다음 미리 설정을 보여 줍니다. 이 그래프에서는 단일 프로세스의 스레드가 선택됩니다.
그림 9 프로세스 및 스레드별 CPU 사용량(샘플링) 사용률
CPU 사용량(정밀) 테이블
CPU 사용량(정밀) 그래프는 컨텍스트 전환 이벤트와 관련된 정보를 기록합니다. 각 행은 단일 컨텍스트 전환과 연결된 데이터 세트를 나타냅니다. 즉, 스레드가 실행되기 시작했을 때입니다. 데이터는 다음 이벤트 시퀀스에 대해 수집됩니다.
새 스레드가 전환됩니다.
새 스레드는 준비 스레드에서 실행할 준비가 되었습니다.
새 스레드가 전환되어 이전 스레드를 전환합니다.
새 스레드가 다시 전환됩니다.
그림 10 CPU 사용량 정밀 다이어그램에서 시간은 왼쪽에서 오른쪽으로 흐릅니다. 다이어그램 레이블은 CPU 사용량(정밀) 그래프의 열 이름에 해당합니다. 타임스탬프 열의 레이블은 다이어그램 맨 위에 표시되고 간격 기간 열의 레이블은 다이어그램의 맨 아래에 표시됩니다.
그림 10 CPU 사용량 정밀 다이어그램
그림 10 CPU 사용량 정밀 다이어그램의 타임라인 나누기는 타임라인을 다른 CPU에서 동시에 발생할 수 있는 영역으로 나눕니다. 번호가 매겨진 이벤트의 순서가 수정되지 않는 한 이러한 타임라인은 겹칠 수 있습니다. 예를 들어 준비 스레드는 프로세서 2에서 새 스레드가 전환된 후 프로세서 1에서 다시 전환되는 것과 동시에 실행될 수 있습니다.
타임라인에서 다음 네 가지 대상에 대한 정보가 기록됩니다.
전환된 스레드인 새 스레드입니다. 그래프에서 이 행의 주요 관심사입니다.
NewPrev 스레드는 새 스레드가 전환된 이전 시간을 나타냅니다.
처리할 새 스레드를 준비한 스레드인 준비 스레드입니다.
새 스레드를 전환할 때 전환된 스레드인 이전 스레드입니다.
다음 테이블의 데이터는 각 대상 스레드와 관련이 있습니다.
| Column | 세부 정보 |
|---|---|
% CPU 사용량 |
스레드가 전환된 후 새 스레드의 CPU 사용량. 이 값은 현재 표시되는 기간 동안 총 CPU 시간의 백분율로 표시됩니다. |
Count |
행으로 표현되는 컨텍스트 전환 횟수. 개별 행의 경우 항상 1입니다. |
Count:Waits |
행으로 표시되는 대기 수. 스레드가 유휴 상태로 전환되는 경우를 제외하고 개별 행의 경우는 항상 1입니다. 스레드가 유휴 상태로 전환되는 경우는 0으로 설정됩니다. |
CPU |
컨텍스트 전환이 발생한 CPU. |
CPU 사용량(밀리초) |
컨텍스트 전환 후 새 스레드의 CPU 사용량. NewInSwitchTime과 같지만 밀리초 단위로 표시됩니다. |
IdealCpu |
새 스레드에 대한 스케줄러에서 선택한 이상적인 CPU. |
LastSwitchOutTime(초) |
새 스레드로 전환되기 전의 시간. |
NewInPri |
전환되는 새 스레드의 우선 순위. |
NewInSwitchTime(초) |
NextSwitchOutTime에서 SwitchInTime을 뺀 값 |
NewOutPri |
전환할 때 새 스레드의 우선 순위. |
NewPrevOutPri |
이전에 전환된 새 스레드의 우선 순위. |
NewPrevState |
이전에 전환된 후 새 스레드의 상태. |
NewPrevWaitMode |
이전에 전환된 새 스레드의 대기 모드. |
NewPrevWaitReason |
새 스레드가 전환된 이유. |
NewPriDecr |
스레드에 영향을 미치는 우선 순위 높임. |
NewProcess |
새 스레드의 프로세스. |
NewProcess 이름 |
PID를 포함하는 새 스레드 프로세스의 이름. |
NewQnt |
사용되지 않습니다. |
NewState |
새 스레드가 전환된 후의 상태. |
NewThreadId |
새 스레드의 스레드 ID. |
NewThreadStack |
새 스레드가 전환될 때 새 스레드의 스택. |
NewThreadStartFunction |
새 스레드의 시작 함수. |
NewThreadStartModule |
새 스레드의 시작 모듈. |
NewWaitMode |
새 스레드의 대기 모드. |
NewWaitReason |
새 스레드가 전환된 이유. |
NextSwitchOutTime(초) |
새 스레드가 다음으로 전환된 시간. |
OldInSwitchTime(초) |
이전 스레드가 전환되기 전에 전환된 시간. |
OldOutPri |
이전 스레드가 전환될 때의 우선 순위. |
OldProcess |
이전 스레드를 소유하는 프로세스. |
OldProcess 이름 |
PID를 포함하여 이전 스레드를 소유하는 프로세스의 이름. |
OldQnt |
사용되지 않습니다. |
OldState |
이전 스레드가 전환된 후의 상태. |
OldThreadId |
이전 스레드의 스레드 ID. |
OldThreadStartFunction |
이전 스레드의 시작 함수. |
OldThreadStartModule |
이전 스레드의 시작 모듈. |
OldWaitMode |
이전 스레드의 대기 모드. |
OldWaitReason |
이전 스레드가 전환된 이유. |
PrevCState |
프로세서의 이전 CState. 이 값이 0(활성)이 아니면 새 스레드의 컨텍스트가 전환되기 전에 프로세서가 유휴 상태였습니다. |
준비(초) |
SwitchInTime(초)에서 ReadyTime(초)을 뺀 값 |
ThreadId 준비 |
준비 스레드의 스레드 ID. |
ThreadStartFunction 준비 |
준비 스레드의 시작 함수. |
ThreadStartModule 준비 |
준비 스레드의 시작 모듈. |
ReadyingProcess |
준비 스레드를 소유하는 프로세스. |
ReadyingProcess 이름 |
PID를 포함하여 준비 스레드를 소유하는 프로세스의 이름. |
ReadyThreadStack |
준비 스레드의 스택. |
ReadyTime(초) |
새 스레드가 준비된 시간. |
SwitchInTime(s) |
새 스레드가 전환된 시간. |
TimeSinceLast(초) |
SwitchInTime(초)에서 LastSwitchOutTime(초)을 뺀 값 |
대기(초) |
ReadyTime(초)에서 LastSwitchOutTime(초)을 뺀 값 |
기본 프로필은 이 그래프에 대해 다음 미리 설정을 사용합니다.
CPU별 타임라인
프로세스/스레드별 타임라인
컨텍스트 전환 시작 시 우선 순위별 사용량
CPU별 사용률
프로세스/스레드별 사용률
CPU별 타임라인
CPU별 타임라인의 CPU 사용량은 프로세서 간에 작업이 분산되는 방식을 보여 줍니다. 그림 11 CPU별 CPU 사용량(정밀) 타임라인은 8개 프로세서 시스템에 타임라인을 표시합니다.
그림 11 CPU별 CPU 사용량(정밀) 타임라인
프로세스/스레드별 타임라인
프로세스당, 스레드당 타임라인의 CPU 사용량은 특정 시간에 스레드가 실행된 프로세스를 보여 줍니다. 그림 12 프로세스/스레드별 사용량(정밀) 타임라인은 여러 프로세스에서 이 타임라인을 보여 줍니다.
그림 12 프로세스/스레드별 사용량(정밀) 타임라인
컨텍스트 전환 시작 시 우선 순위별 사용량
이 그래프는 각 우선 순위 수준에서 우선 순위가 높은 스레드 활동의 버스트를 식별합니다. 그림 13 컨텍스트 전환 시작 시 우선 순위별 CPU 사용량(정밀) 사용량은 우선 순위 분산을 보여 줍니다.
그림 13 컨텍스트 전환 시작 시 우선 순위별 CPU 사용량(정밀) 사용량
CPU별 사용률
이 그래프에서 CPU 사용량은 CPU별로 그룹화되고 그래프로 표시되어 프로세서 간에 작업이 분산되는 방식을 보여 줍니다. 그림 14 CPU별 CPU 사용량(정밀) 사용률은 8개의 프로세서가 있는 시스템의 그래프를 보여 줍니다.
그림 14 CPU별 CPU 사용량(정밀) 사용률
프로세스/스레드별 사용률
이 그래프에서 CPU 사용량은 먼저 프로세스별로 그룹화된 다음 스레드별로 그룹화됩니다. 프로세스의 상대적 사용량과 각 프로세스의 스레드를 보여 줍니다. 그림 15 프로세스/스레드별 CPU 사용량(정밀) 사용률은 여러 프로세스에서 이 분산을 보여 줍니다.
그림 15 프로세스/스레드별 CPU 사용량(정밀) 사용률
DPC/ISR Graph
DPC/ISR 그래프는 WPA에서 DPC/ISR 정보의 기본 소스입니다. 그래프의 각 행은 DPC 또는 ISR이 중단 없이 실행되는 기간인 조각을 나타냅니다. 데이터는 조각의 시작과 끝에 수집됩니다. DPC/ISR이 완료되면 추가 데이터가 수집됩니다. 그림 16 DPC/ISR 다이어그램은 작동 방식을 보여 줍니다.
그림 16 DPC/ISR 다이어그램
그림 16 DPC/ISR 다이어그램은 다음 활동 중에 수집된 데이터를 설명합니다.
DPC/ISR-A가 실행되기 시작합니다.
DPC/ISR-A보다 인터럽트 수준이 높은 장치 인터럽트는 ISR-B가 DPC/ISR A를 인터럽트하게 하여 DPC/ISR-A의 첫 번째 조각을 종료합니다.
ISR-B가 완료되어 ISR-B의 조각이 종료됩니다. DPC/ISR-A는 두 번째 프래그먼트에서 실행을 다시 시작합니다.
DPC/ISR-A가 완료되어 DPC/ISR-A의 두 번째 조각이 종료됩니다.
각 조각에 대한 행이 데이터 테이블에 표시됩니다. DPC/ISR-A에 대한 조각은 조각이 아닌 열과 동일한 정보를 공유합니다.
DPC/ISR 그래프의 열은 조각 수준 정보 또는 DPC/ISR 수준 열에 대해 설명합니다. 각 조각의 다른 데이터는 조각 수준 열에 있고 동일한 데이터는 DPC/ISR 열에 있습니다.
| Column | 세부 정보 |
|---|---|
% 기간(조각남) |
현재 표시되는 기간 동안 총 CPU 시간의 백분율로 표현되는 기간(조각남). |
% 전용 기간 |
현재 표시되는 기간 동안 총 CPU 시간의 백분율로 표현되는 전용 기간. |
% 포괄 기간 |
현재 표시되는 기간 동안 총 CPU 시간의 백분율로 표현되는 포괄 기간. |
주소 |
DPC 또는 ISR 함수의 메모리 주소. |
개수(DPC/ISR) |
이 행으로 표시되는 DDPC/ISR의 수. DPC/ISR의 마지막 조각을 나타내는 행의 경우 항상 1입니다. 그렇지 않으면 이 개수는 0입니다. |
개수(조각) |
행으로 표현되는 조각의 수. 개별 행의 경우 항상 1입니다. |
CPU |
DPC 또는 ISR이 실행된 논리 프로세서의 인덱스. |
DPC 형식 |
DPC의 경우 DPC의 형식으로 일반 또는 타이머 중 하나입니다. ISR의 경우 값이 비어 있습니다. |
DPC/ISR 시작 시간(초) |
DPC/ISR이 시작된 추적 시간. |
DPC/ISR 종료 시간(초) |
추적 시작부터 DPC/ISR이 완료된 시점까지의 시간. |
기간(조각남)(ms) |
조각 종료 시간(초)에서 조각 시작 시간(초)을 뺀 값. |
전용 기간(ms) |
해당 DPC/ISR의 모든 조각에 대한 조각난 기간의 합계. |
조각 |
이 행의 DPC/ISR에 여러 조각이 있는 경우 값은 True, 그렇지 않으면 False입니다. |
조각 |
DPC/ISR의 유일한 조각이 아닌 경우 값은 True, 그렇지 않으면 False입니다. |
조각 시작 시간(초) |
조각이 실행되기 시작한 시간. |
조각 종료 시간(초) |
조각 실행이 중지된 시간. |
함수 |
실행된 DPC 또는 ISR 함수. |
포괄 기간(ms) |
DPC/ISR 종료 시간(초)에서 DPC/ISR 시작 시간(초)을 뺀 값. |
MessageIndex |
메시지 신호 인터럽트용 인터럽트 인덱스. |
모듈 |
DPC 또는 ISR 함수를 포함하는 모듈. |
Return Value |
DPC/ISR의 반환 값. |
Type |
이벤트의 형식. DPC 또는 인터럽트(ISR)입니다. |
벡터 |
디바이스의 인터럽트 벡터 값. |
기본 프로필은 이 그래프에 대해 다음 미리 설정을 사용합니다.
[DPC,ISR,DPC/ISR] CPU별 기간
[DPC,ISR,DPC/ISR] 모듈별 기간, 함수
[DPC,ISR,DPC/ISR] 모듈/함수별 타임라인
[DPC,ISR,DPC/ISR] CPU별 기간
DPC/ISR 이벤트는 실행된 CPU에 의해 집계되며 기간별로 정렬됩니다. 이 그래프는 CPU 간에 DPC 활동의 할당을 보여 줍니다. 그림 17 CPU별 DPC/ISR 기간은 8개의 프로세서가 있는 시스템에 대한 이 그래프를 보여 줍니다.
그림 17 CPU별 DPC/ISR 기간
[DPC,ISR,DPC/ISR] 모듈별 기간, 함수
DPC/ISR 이벤트는 DPC/ISR 루틴의 모듈 및 함수에 의해 이 그래프에서 집계되며 기간별로 정렬됩니다. 이는 그림 18 모듈별 DPC/ISR 기간에서 가장 많이 사용한 DPC/ISR 루틴을 보여 줍니다. 함수는 두 모듈에서 DPC/ISR 활동이 발생하는 기간을 보여 줍니다.
그림 18 모듈/함수별 DPC/ISR 기간
[DPC,ISR,DPC/ISR] 모듈/함수별 타임라인
DPC/ISR 이벤트는 DPC/ISR 루틴의 모듈 및 함수에 의해 이 그래프에서 집계됩니다. 타임라인의 그래프로 표시됩니다. 이 그래프는 DPC/ISR이 실행된 기간에 대해 자세히 보여 줍니다. 이 그래프는 단일 DPC/ISR을 조각낼 수 있는 방법을 보여 줄 수도 있습니다. 그림 19 모듈/함수별 DPC/ISR 타임라인은 세 가지 모듈의 활동 타임라인을 보여 줍니다.
그림 19 모듈/함수별 DPC/ISR 타임라인
스택 트리
스택 트리는 WPA의 CPU 사용량(샘플링), CPU 사용량(정밀), DPC/ISR 테이블과 평가 보고서에서 보고되는 문제에 표시됩니다. 스택 트리는 일정 기간 동안 여러 이벤트와 연결된 호출 스택을 나타냅니다. 트리의 각 노드는 이벤트의 하위 집합에서 공유하는 스택 세그먼트를 나타냅니다. 트리는 개별 스택에서 생성되며 그림 20 세 이벤트의 스택에 표시됩니다.
그림 20 세 이벤트의 스택
그림 21 식별된 일반적인 세그먼트는 그래프에 대해 일반적인 시퀀스를 식별하는 방법을 보여 줍니다.
그림 21 식별된 일반적인 세그먼트
그림 22 스택에서 빌드된 트리는 일반적인 세그먼트를 결합하여 트리의 노드를 형성하는 방법을 보여 줍니다.
그림 22 스택에서 빌드된 트리
WPA UI의 스택 열에는 리프가 아닌 각 노드에 대한 확장기가 포함되어 있습니다. 평가 보고 문제에서 트리는 집계 가중치와 함께 표시됩니다. 가중치가 지정된 임계값을 충족하지 않는 경우 그래프에서 일부 분기를 제거할 수 있습니다. 아래 샘플 스택은 위에 표시된 이벤트가 어떻게 평가 보고 문제의 일부로 표시되는지 보여 줍니다.
5ms ModuleA!Function1
5ms ModuleA!Function2
5ms ModuleA!Function3
|
4ms |-ModuleA!Function4
4ms | ModuleB!Function1
| |
1ms | |-ModuleB-Function2
1ms | | ModuleB-Function3
| |
3ms | |-ModuleB!Function3
3ms | ModuleB!Function4
|
1ms |-ModuleA!Function5
1ms ModuleC!Function1
1ms ModuleC!Function2
스택의 <itself> 노드는 함수 자체가 스택의 맨 위에 있는 시간을 나타냅니다. <itself> 노드에는 부모 함수에 의해 호출되는 함수에 소요되는 시간이 포함되지 않습니다. 이 기간을 함수에 소요된 전용 시간이라고 합니다.
예를 들어 Function1은 Function2를 호출합니다. Function2는 CPU 집약적 루프에서 2밀리초를 사용하고 4밀리초 동안 실행되는 다른 함수를 호출했습니다. 이것은 다음 스택으로 나타낼 수 있습니다.
6ms ModuleA!Function1
|
2ms |-<itself>
4ms |-ModuleA!Function2
4ms ModuleB!Function3
4ms ModuleB-Function4
기술
이 섹션에서는 성능 분석에 대한 표준 접근 방식을 설명합니다. 일반적인 CPU 관련 성능 문제를 조사하는 데 사용할 수 있는 기술을 설명합니다.
성능 분석은 4단계 프로세스입니다.
시나리오 및 문제를 정의합니다.
관련된 구성 요소 및 관련 시간 범위를 식별합니다.
발생했어야 하는 작업의 모델을 만듭니다.
모델을 사용하여 문제를 식별하고 근본 원인을 조사합니다.
시나리오 및 문제 정의
성능 분석의 첫 번째 단계는 시나리오와 문제를 명확하게 정의하는 것입니다. 많은 성능 문제가 평가 메트릭으로 측정되는 시나리오에 영향을 미칩니다. 예시:
시나리오 1: 물리적 리소스가 완전히 활용되지 않습니다. 예를 들어 서버는 패킷을 충분히 빠르게 암호화할 수 없으므로 네트워크 연결을 완전히 활용할 수 없습니다.
시나리오 2: 실제 리소스가 예상보다 많이 활용되고 있습니다. 예를 들어 시스템은 배터리 전원을 사용하는 유휴 기간 동안 상당한 CPU 리소스를 사용합니다.
시나리오 3: 활동이 필요한 속도로 완료되지 않습니다. 예를 들어 프레임이 충분히 빠르게 디코딩되지 않으므로 비디오 재생 중에 프레임이 삭제됩니다.
시나리오 4: 활동이 지연되었습니다. 예를 들어 사용자가 Internet Explorer를 시작했지만 탭을 여는 데 예상보다 오래 걸렸습니다.
CPU 리소스와 관련된 시나리오 3 및 4는 이 가이드에서 다룹니다. 시나리오 1과 2는 범위를 벗어났으므로 다루지 않습니다. 이러한 문제를 분석하기 위해서는 “너무 느림”과 같은 모호한 관찰에서 시작하여 시나리오와 정확한 문제를 식별하기 위해 추가 질문을 할 수 있습니다.
구성 요소 및 기간 식별
시나리오와 문제가 식별되면 관련된 구성 요소와 관심 기간을 식별할 수 있습니다. 구성 요소에는 하드웨어 리소스, 프로세스, 스레드가 포함됩니다.
분석 가이드에서 관련 활동을 식별하여 관심 있는 시간 범위를 찾을 수 있는 경우가 많습니다. 활동은 WPA에서 선택하고 확대할 수 있는 시작 이벤트와 중지 이벤트 사이의 간격입니다. 활동이 정의되지 않은 경우 시나리오와 연결된 특정 일반 이벤트를 찾거나 시나리오의 시작과 끝을 표시할 수 있는 리소스 사용률의 변경 내용을 검색하여 시간 범위를 찾을 수 있습니다. 예를 들어 CPU가 2초 동안 유휴 상태였고 4초 동안 완전히 활용된 다음 2초 동안 다시 유휴 상태인 경우 비디오 재생을 캡처하는 추적에서 4초 동안의 전체 사용률이 관심 영역일 수 있습니다.
모델 만들기
문제의 근본 원인을 이해하려면 발생한 문제의 모델이 있어야 합니다. 모델은 문제 또는 메트릭에 대한 관련 목표로 시작합니다. 예: “이 작업은 5초 이내에 완료되어야 합니다.”
더 완전한 모델에는 구성 요소가 수행해야 하는 방법에 대한 정보가 포함되어 있습니다. 예를 들어 구성 요소 간에 어떤 통신이 필요한가요? 일반적인 리소스 사용률은 얼마인가요? 일반적으로 작업은 얼마나 걸리나요?
모델에 대한 정보는 종종 평가 분석 가이드에서 찾을 수 있습니다. 해당 리소스를 사용할 수 없는 경우 성능 문제를 나타내지 않는 유사한 하드웨어 및 소프트웨어에서 추적을 생성하여 모델을 만들 수 있습니다.
모델을 사용하여 문제를 식별한 다음 근본 원인 조사
모델이 있으면 추적을 모델과 비교하여 문제를 식별할 수 있습니다. 예를 들어 일시 중단 디바이스라는 특정 활동에 대한 모델은 전체 활동이 3초 안에 완료되어야 한다고 제안하는 반면 일시 중단 <디바이스 이름>이라는 하위 활동의 각 인스턴스는 100밀리초를 넘지 않아야 합니다. 하위 활동 일시 중단 <디바이스 이름>의 두 인스턴스에 각각 800밀리초가 걸리는 경우 해당 인스턴스를 조사해야 합니다.
모델의 각 편차를 분석하여 근본 원인을 찾을 수 있습니다. 관련된 스레드의 상태를 검사하고 일반적인 근본 원인을 찾아야 합니다. 필요한 속도로 완료되지 않거나 지연된 활동에 대한 몇 가지 주요 CPU 관련 근본 원인은 다음과 같습니다.
직접 CPU 사용량: 적절한 스레드가 전체 CPU 리소스를 수신했지만 필요한 프로그램이 충분히 빠르게 실행되지 않았습니다. 이는 프로그램 오작동 또는 느린 하드웨어로 인해 발생할 수 있습니다.
스레드 간섭: 다른 스레드가 대신 실행 중이므로 스레드가 충분한 실행 시간을 얻지 못했습니다. 이 경우 스레드가 고갈되거나 선점된 것으로 간주됩니다.
DPC/ISR 간섭: CPU가 DPC 또는 ISR을 처리하는 데 사용 중이어서 스레드가 충분한 실행 시간을 얻지 못했습니다.
대부분의 경우 이러한 근본 원인 중 하나가 스레드에 눈에 띄게 영향을 미치지 않으며 스레드는 대부분의 시간을 대기 상태로 보냅니다. 이 경우 스레드가 대기 중인 이벤트를 식별하고 조사해야 합니다. 이 재귀적인 유형의 조사를 대기 분석이라고 하며 중요한 경로를 식별하여 시작합니다.
고급 기술: 대기 분석 및 중요 경로
활동은 시작 이벤트에서 종료 이벤트로 흐르는 작업 네트워크(일부는 순차적이고 일부는 병렬)입니다. 추적의 모든 시작/끝 이벤트 쌍을 활동으로 볼 수 있습니다. 이 작업 네트워크를 통해 가장 긴 경로를 중요 경로라고 합니다. 중요 경로에 대한 작업 기간을 줄이면 전체 작업 기간이 바로 줄어들지만 이로 인해 중요 경로도 변경될 수 있습니다.
그림 23 활동 작업은 세 스레드의 활동을 보여 줍니다. 스레드 1은 작업(activity) 시작 이벤트를 보낸 다음 스레드 2 및 스레드 3이 작업(task)을 완료할 때까지 기다립니다. 스레드 2가 먼저 작업을 완료한 다음 스레드 3이 완료합니다. 두 스레드가 작업을 완료하면 스레드 1이 준비되고 작업 이벤트가 완료됩니다.
그림 23 활동 작업
이 시나리오에서 중요 경로에는 스레드 3 및 스레드 1의 일부가 포함됩니다. 이러한 경로는 그림 24 중요 경로에서 추적됩니다. 스레드 2가 중요 경로에 없으므로 작업을 완료하는 데 걸리는 시간은 전체 활동 시간에 영향을 미치지 않습니다.
그림 24 중요 경로
중요 경로는 활동에 시간이 많이 걸리는 이유에 대한 낮은 수준의 문자 그대로의 답변입니다. 중요 경로의 주요 세그먼트를 알게 되면 이를 분석하여 전체 지연에 기여하는 문제를 찾을 수 있습니다.
중요 경로를 찾기 위한 일반적인 접근 방식
중요 경로를 찾는 첫 번째 단계는 시나리오 모델을 검토하여 활동의 목적과 구현을 이해하는 것입니다.
활동을 이해하면 중요 경로에 있을 수 있는 특정 작업, 프로세스, 스레드를 식별하는 데 도움이 될 수 있습니다. 예를 들어 빠른 시작 재개 Explorer 초기화 활동의 지연은 상당한 양의 I/O가 필요한 RunOnce 애플리케이션과 Explorer 초기화 프로세스로 인해 발생할 수 있습니다.
시나리오 모델을 검토한 후 평가에 영향을 받는 활동에 대한 문제를 보고했는지 확인합니다. 대부분의 경우 평가 보고된 지연 문제에 중요 경로의 근사값이 포함됩니다. 중요 경로는 대기 및 준비 작업의 시퀀스로 표시됩니다. 목록 중간에 중요 경로의 기본 지연 세그먼트가 있는 이벤트 시퀀스로 처음부터 끝까지 읽을 수 있습니다. 목록의 마지막 항목은 활동을 완료한 스레드를 준비한 작업입니다.
중요 경로를 수동으로 찾아야 하는 경우 활동을 완료한 프로세스와 스레드를 식별하고 활동이 완료된 순간부터 거꾸로 작업하는 것이 좋습니다. WPA의 활동 그래프를 통해 활동을 시작한 프로세스와 스레드, 활동을 완료한 프로세스와 스레드를 식별할 수 있습니다.
활동 그래프는 평가 결과 XML 파일을 통해 추적이 로드될 때 표시됩니다. 특정 활동과 연결된 프로세스 및 스레드를 식별하려면 그래프를 관심 있는 활동으로 확장한 다음 보기를 그래프+테이블로 전환합니다. 그래프 모드를 테이블로 설정합니다. 시작 프로세스, 시작 스레드 ID, 종료 프로세스, 종료 스레드 ID 열이 테이블의 각 활동에 대해 표시됩니다.
시작 및 종료 프로세스, 스레드 및 활동의 구현을 알고 나면 중요한 경로를 뒤로 추적할 수 있습니다. 활동을 완료한 스레드를 분석하여 해당 스레드가 실행, 준비 또는 대기 중 대부분의 시간을 소요한 방법을 확인하면서 시작합니다.
상당한 실행 시간은 직접적인 CPU 사용량이 중요 경로의 기간에 영향을 미쳤을 수 있음을 나타냅니다. 준비 모드에서 소요된 시간은 다른 스레드가 중요 경로의 스레드가 실행되지 않도록 하여 중요 경로의 기간에 기여함을 나타냅니다. 대기 중 소요 시간은 현재 스레드가 대기하고 있는 중요 경로의 I/O, 타이머 또는 기타 스레드와 프로세스를 가리킵니다.
현재 스레드를 준비한 각 스레드는 중요 경로의 또 다른 연결일 수 있으며 중요 경로의 기간이 설명될 때까지 분석될 수도 있습니다.
절차: WPA에서 중요 경로 찾기
다음 절차에서는 중요 경로를 찾으려는 활동 그래프에서 활동을 식별했다고 가정합니다.
활동 그래프에서 활동 위로 마우스를 가져가면 활동을 완료한 프로세스를 식별할 수 있습니다.
CPU 사용량(정밀) 그래프를 추가합니다. 영향을 받는 활동을 확대하고 프로세스/스레드별 사용률 미리 설정을 적용합니다.
열 머리글을 마우스 오른쪽 단추로 클릭하고 ReadyThreadStack 및 CPU 사용량(ms) 열을 표시합니다. Ready (us) [Max] 및 Waits (us) [Max] 열을 제거합니다.
대상 프로세스를 확장하고 CPU 사용량(ms), Ready (us) [Sum], Waits (us) [Sum]별로 각각 정렬합니다.
실행, 준비 또는 대기 상태에서 소요된 시간이 가장 많은 프로세스에서 NewThreadIds를 검색합니다.
실행 중 또는 준비 상태에서 상당한 시간을 보내는 스레드는 중요한 경로에서 직접 CPU 사용량을 나타낼 수 있습니다. 대기 상태에서 상당한 시간을 보내는 스레드 ID.Threads는 I/O, 타이머 또는 중요한 경로의 다른 스레드에서 대기 중일 수 있습니다.
스레드가 무엇을 기다리고 있는지 알아보려면 NewThreadId 그룹을 확장하여 ReadyThreadStack을 표시합니다.
[Root]를 확장합니다.
KiDispatchInterrupt로 시작하는 스택은 다른 스레드와 관련이 없습니다. 스레드가 이러한 스택에서 무엇을 기다리고 있는지 확인하려면 KiDispatchInterrupt를 확장하고 자식 스택의 함수를 확인합니다. IopfCompleteRequest는 준비된 스레드가 I/O를 기다리고 있음을 나타냅니다. KiTimerExpiration는 준비된 스레드가 타이머를 기다리고 있음을 나타냅니다.
ReadyingProcess 및 ReadyingThread가 표시될 때까지 KiDispatchInterrupt로 시작하지 않는 스택을 확장합니다. 프로세스가 이미 확장된 경우 ReadyingThread에 해당하는 NewThreadId를 확장합니다. 실행 중이거나, 준비되거나, 다른 이유를 기다리거나, 다른 프로세스를 기다리는 스레드를 찾을 때까지 이 단계를 반복합니다. 스레드가 다른 프로세스를 기다리는 경우 해당 프로세스를 사용하여 이 절차를 반복합니다.
예제
이 예제에서는 빠른 시작 재개 Explorer 초기화 활동의 지연을 보여 줍니다. 문제 창에서 검색하면 이 활동에 대해 7개의 지연 형식 문제가 보고됨을 보여 줍니다. 이러한 각 문제는 중요 경로의 세그먼트로 검토할 수 있습니다. 다음 주요 세그먼트가 식별됩니다.
TestBootStrapper.exe(3024) 프로세스의 스레드 3872는 2.1초 동안 선점됩니다.
TestBootStrapper.exe(3024) 프로세스의 스레드 3872는 1초의 CPU 시간을 사용합니다.
TestBootStrapper.exe(3024) 프로세스의 스레드 3872는 544밀리초 동안 레지스트리 하이브를 플러시합니다.
TestBootStrapper.exe(3024) 프로세스의 스레드 3872는 513밀리초 동안 절전 모드입니다.
Explorer.exe의 스레드 4052 및 4036이 디스크에서 읽기 때문에 461밀리초 지연이 발생합니다.
TestBootStrapper.exe(3024) 프로세스의 스레드 3872는 187밀리초 동안 고갈됩니다.
TestBootStrapper.exe 프로세스의 스레드 3872가 디스크에 3.5MB를 기록하여 178밀리초 지연이 발생합니다.
문제는 이 활동이 5.2초 지연되었음을 보여 줍니다. 이러한 지연은 전체 활동 기간인 6.3초에서 큰 비중을 차지합니다. TestBootStrapper.exe 애플리케이션은 주로 다른 처리 작업을 선점했으므로 지연을 주로 담당합니다.
중요 경로의 문제 조사
영향을 받는 영역을 확대/축소하고 ReadyThreadStack 및 CPU 사용량(ms) 열을 추가합니다.
이 경우 Explorer.exe는 활동을 완료하는 프로세스입니다. Explorer.exe 프로세스를 확장하고 다음 그림과 같이 CPU 사용량(ms), Ready (us) [Sum], Waits (us) [Sum]별로 각각 정렬합니다.
그림 25 CPU 사용량(ms)별 활동
그림 26 Ready (us)별 활동
그림 27 Waits (us)별 활동
CPU 사용량(ms) 열을 기준으로 정렬하면 299밀리초의 상위 자식 행이 표시됩니다. Ready (us) [Sum] 열을 기준으로 정렬하면 46밀리초의 상위 자식 행이 표시됩니다. Waits (us) [Sum] 열을 기준으로 정렬하면 5749밀리초의 상위 자식 행과 4902밀리초의 두 번째 행이 표시됩니다. 이러한 행은 지연에 크게 기여하므로 추가로 조사해야 합니다.
다음 그림과 같이 스택을 확장하여 준비 스레드를 표시합니다.
그림 28 스레드에 대한 준비 프로세스 및 스레드 준비
그림 29 다른 스레드에 대한 준비 프로세스 및 준비 스레드
이 예제에서 첫 번째 스레드는 RunOnce.exe 프로세스가 종료될 때까지 기다리는 데 대부분의 시간을 소요합니다. RunOnce.exe 프로세스를 완료하는 데 너무 많은 시간이 걸리는 이유를 조사해야 합니다. 두 번째 스레드는 첫 번째 스레드에서 대기 중이며 동일한 대기 체인의 중요하지 않은 링크일 수 있습니다.
RunOnce.exe에 대해 이 절차의 단계를 반복합니다. 기본 기여 열은 Waits (us)이며 4명의 가능한 기여자가 있습니다.
각 기여자를 확장하여 처음 세 명의 기여자가 각각 네 번째 기여자를 기다리고 있는지 확인합니다. 이 상황에서는 처음 세 명의 기여자가 대기 체인에 중요하지 않게 됩니다. 네 번째 기여자는 다른 프로세스인 TestBootStrapper.exe를 기다리고 있습니다.
이 시나리오는 그림 30 RunOnce.exe의 스레드에 대한 준비 프로세스 및 준비 스레드에 나와 있습니다.
그림 30 RunOnce.exe의 스레드에 대한 준비 프로세스 및 준비 스레드
TestBootStrapper.exe에 대해 이 절차의 단계를 반복합니다. 결과는 다음 세 가지 그림에 나와 있습니다.
그림 31 CPU 사용량(ms)별 스레드
그림 32 Ready (us)별 스레드
그림 33 Waits (us)별 스레드
스레드 3872는 실행에 약 1초, 준비에 2초, 대기에 1.3초를 소요했습니다. 이 스레드는 스레드 3872에 대한 준비 스레드이기도 하므로 실행 및 준비 시간이 지연에 기여할 수 있습니다. 평가는 시간이 지연과 일치하는 다음 문제를 보고합니다.
TestBootStrapper.exe(3024) 프로세스의 스레드 3872는 2.1초 동안 선점됩니다.
TestBootStrapper.exe(3024) 프로세스의 스레드 3872는 187밀리초 동안 고갈됩니다.
TestBootStrapper.exe(3024) 프로세스의 스레드 3872는 1초의 CPU 시간을 사용합니다.
다른 기여 문제를 찾으려면 스레드 3872가 대기 중인 이벤트를 확인합니다. 그림 34 대기 시간에 대한 기여자에서와 같이 ReadyThreadStack을 확장하여 1.3초의 대기 시간에 대한 기여자를 확인합니다.
그림 34 대기 시간에 대한 기여자
KiRetireDpcList는 일반적으로 I/O와 관련되어 있고 KiTimerExpiration은 타이머입니다. ReadyThreadStack을 제거한 다음 NewThreadStack을 보면 I/O와 타이머가 어떻게 시작되었는지 확인할 수 있습니다. 이 보기는 그림 35 NewThreadStack의 I/O 및 타이머와 같이 세 가지 관련 기능을 보여 줍니다.
그림 35 NewThreadStack의 I/O 및 타이머
이 보기는 다음 세부 정보를 공개합니다.
TestBootStrapper.exe(3024) 프로세스의 스레드 3872는 544밀리초 동안 레지스트리 하이브를 플러시합니다.
TestBootStrapper.exe(3024) 프로세스의 스레드 3872는 513밀리초 동안 절전 모드입니다.
TestBootStrapper.exe 프로세스의 스레드 3872는 디스크에 3.5MB를 기록하므로 178밀리초 지연이 발생합니다.
중요 경로 조사를 시작할 때 Explorer.exe에서 가장 중요한 대기 원인을 분석하고 대기 원인 이후에 발생한 중요 경로 부분을 무시했습니다. 중요 경로에서 이전에 무시된 이 섹션을 캡처하려면 타임라인을 확인해야 합니다. CPU 사용량(정밀)을 추가하고 프로세스/스레드별 타임라인 미리 설정을 적용합니다.
중요 경로의 일부로 식별된 프로세스만 포함하도록 필터링합니다. 결과 그래프는 그림 36 중요 경로 타임라인에 나와 있습니다.
그림 36 중요 경로 타임라인
그림 36 중요 경로 타임라인은 Explorer.exe가 RunOnce.exe에 대한 대기를 중지한 후 더 많은 작업을 수행했음을 보여 줍니다. 이전에 분석한 대기 체인 이후의 기간을 확대/축소하고 다른 분석을 수행합니다. 이 경우 분석은 Explorer.exe 내부에 있으며 중요 경로를 통한 명확한 추적이 없는 많은 수의 스레드를 보여 줍니다. 이 경우 추가 분석을 통해 실행 가능한 인사이트를 얻을 수 없습니다.
직접 CPU 사용량
중요 경로의 스레드는 상당한 CPU 시간을 사용하므로 활동이 지연되는 경우가 많습니다. 스레드 상태 모델을 사용하면 이 문제가 실행 중인 상태에서 예외적인 시간을 보내는 중요 경로의 스레드가 특징임을 알 수 있습니다. 일부 하드웨어에서는 이러한 과도한 CPU 사용량이 지연에 기여할 수 있습니다.
문제 식별
많은 평가에서 추론을 사용하여 직접적인 CPU 사용량 관련 문제를 식별합니다. 중요 경로의 상당한 CPU 사용량은 다음 형식의 문제로 보고됩니다.
P 프로세스의 CPU 사용은 영향을 받는 활동 A를 x초 동안 지연되게 합니다.
여기서 P는 실행 중인 프로세스, A는 활동, x는 시간(초)입니다.
지연이 발생하는 활동에 대해 이러한 문제가 보고되면 직접 CPU 사용량이 원인일 수 있습니다.
직접 CPU 사용량 조사
CPU 사용량(샘플링) 그래프에서 100% CPU 사용량이 발생하는 개별 CPU를 찾아 문제를 수동으로 식별할 수 있습니다.
그래프에서 관심 영역을 확대/축소하고 프로세스 및 스레드별 사용률 미리 설정을 선택합니다.
기본적으로 테이블에는 집계 CPU 사용량이 가장 높은 행이 맨 위에 표시됩니다. 이러한 스레드는 CPU 사용량(샘플링) 그래프의 맨 위에도 표시됩니다.
참고 다중 프로세서가 있는 시스템에서 단일 프로세서를 100% 사용하는 스레드는 100/(논리 프로세서 수)를 사용하는 것으로 나타납니다. 이러한 종류의 시스템에서는 가상 유휴 스레드(PID 0, TID 0)만 100/(논리 프로세서 수)보다 더 큰 프로세서 사용률을 나타낼 수 있습니다. CPU를 가장 많이 사용하는 프로세스와 스레드가 중요 경로의 스레드에 해당하는 경우 직접적인 CPU 사용량이 요인일 수 있습니다.
평가에서 보고된 직접 CPU 사용량 문제의 예제
TestUM.exe 프로세스(4024)가 CPU를 사용하면 영향을 받는 활동인 빠른 시작 종료 프로세스인 TestIM.exe가 2.1초 동안 지연됩니다. 이 예제는 그림 37 스레드 3208에 나와 있습니다.
그림 37 스레드 3208
조사
직접적인 CPU 사용이 중요 경로의 지연에 기여한다는 것을 알게 된 후에는 지연에 기여하는 특정 모듈 및 함수를 식별해야 합니다.
기술: 평가에서 보고된 직접 CPU 사용량 문제 검토
평가에서 보고된 직접 CPU 사용량 문제를 확장하여 직접 CPU 사용량의 영향을 받는 중요 경로를 표시할 수 있습니다. CPU 사용량과 연결된 노드를 확장하면 CPU 사용량 및 관련 모듈과 연결된 스택이 표시됩니다. 이 보기는 그림 38 확장된 CPU 사용량 세그먼트에 나와 있습니다.
그림 38 확장된 CPU 사용량 세그먼트
기술: 직접 CPU 사용량 문제의 스택을 수동으로 검색
평가에서 문제를 보고하지 않았거나 추가 확인이 필요한 경우 CPU 사용량(샘플링) 그래프를 사용하여 CPU 사용량 문제와 관련된 모듈 및 함수에 대한 정보를 수동으로 수집할 수 있습니다. 이렇게 하려면 관심 영역을 확대/축소하고 CPU 사용량별로 정렬된 스택을 확인해야 합니다.
직접 CPU 사용량 문제의 스택을 수동으로 검색
추적 메뉴에서 기호 로드를 클릭합니다.
CPU 문제의 영향을 받는 중요 경로의 일부분만 표시하도록 타임라인을 확대/축소합니다.
프로세스 및 스레드별 사용률 미리 설정을 적용합니다.
디스플레이에 스택 열을 추가한 다음 이 열을 스레드 ID의 오른쪽(바의 왼쪽)으로 끕니다.
프로세스 및 스레드를 확장하여 스택 트리를 표시합니다.
스택의 행은 % CPU 사용량 가중치를 기준으로 내림차순으로 정렬됩니다. 이렇게 하면 가장 흥미로운 스택이 맨 위에 배치됩니다. 스택을 확장할 때 % 가중치 열을 관찰하여 사용량이 가장 많은 행에 계속 초점을 맞추는지 확인하세요.
스택의 복사본을 추출하려면 모든 행을 선택하고 마우스 오른쪽 단추를 클릭한 다음 선택 영역 복사를 클릭합니다.
해결
구성 및 구성 요소 수준 모두에서 해결 방법을 적용하여 높은 CPU 사용량을 해결할 수 있습니다.
직접 CPU 사용량은 하위 엔드 프로세서가 있는 컴퓨터에 더 큰 영향을 미칩니다. 이러한 경우 컴퓨터에 더 많은 처리 능력을 추가할 수 있습니다. 또는 중요 경로 또는 시스템에서 문제 모듈을 제거할 수 있습니다. 구성 요소를 변경할 수 있는 경우 다음 결과 중 하나를 달성하기 위해 다시 설계하는 것이 좋습니다.
중요 경로에서 CPU 집약적 코드 제거
더 많은 CPU 효율적인 알고리즘 사용
작업 연기 또는 캐시
스레드 간섭
중요 경로에 있지 않고 활동과 관련이 없을 수 있는 스레드별 CPU 사용량으로 인해 중요 경로에 있는 스레드가 지연될 수 있습니다. 스레드 상태 모델은 이 문제의 특징이 준비 상태에서 비정상적인 시간을 보내는 중요 경로의 스레드임을 보여 줍니다.
문제 식별
많은 평가에서 추론을 사용하여 간섭 관련 문제를 식별합니다. 이러한 항목은 다음 두 가지 형식 중 하나로 보고됩니다.
P 프로세스가 고갈됩니다. 고갈 상태로 인해 영향을 받는 활동 A가 x밀리초 지연됩니다.
프로세스가 선점됩니다. 선점 상태로 인해 영향을 받는 활동 A가 x밀리초 지연됩니다.
여기서 P는 프로세스, A는 활동, x는 시간(ms)입니다.
첫 번째 형식은 중요 경로의 스레드와 동일한 우선 순위 수준에서 스레드의 간섭을 반영합니다. 두 번째 형식은 중요 경로의 스레드보다 우선 순위가 높은 스레드의 간섭을 반영합니다.
지연된 활동에 대해 이러한 유형의 문제가 보고되는 경우 스레드 간섭이 원인일 수 있습니다. CPU 사용량(정밀) 그래프를 사용하여 문제를 수동으로 식별할 수 있습니다.
스레드 간섭 문제 식별
간격으로 확대/축소하고 CPU별 사용률 미리 설정을 적용합니다. 모든 CPU에서 100%의 사용률은 간섭 문제를 나타냅니다.
프로세스/스레드별 사용률 미리 설정을 적용하고 첫 번째 Ready (us) 열을 기준으로 정렬합니다. (합계 집계가 포함된 열입니다.)
영향을 받는 활동의 프로세스를 확장하고 중요 경로의 스레드에 대한 준비 시간을 확인합니다. 이 값은 스레드 간섭 문제를 해결하여 지연을 줄일 수 있는 최대 시간입니다. 조사 중인 지연에 비해 크기가 큰 값은 스레드 간섭 문제가 있음을 나타냅니다.
그림 39 CPU 사용률이 거의 100% 및 그림 40 스레드 간섭 문제는 다음 시나리오를 보여 줍니다.
그림 39 CPU 사용률이 거의 100%
그림 40 스레드 간섭 문제
조사
문제가 식별되면 영향을 받는 스레드가 준비 상태에서 너무 많은 시간을 소요한 이유를 확인해야 합니다.
기술: 스레드가 준비 상태에서 시간을 소요한 이유 확인
CPU 사용량(정밀) 그래프를 사용하여 스레드가 준비 상태에서 시간을 소요한 이유를 확인할 수 있습니다. 먼저 스레드가 특정 프로세서로 제한되는지 여부를 결정해야 합니다. 이 정보를 직접 얻을 수는 없지만 CPU 사용률이 높은 기간 동안 스레드의 CPU 사용 기록을 검사할 수 있습니다. 스레드가 프로세서 간에 자주 전환되는 경향이 있는 기간입니다.
스레드의 프로세서 제한 사항 확인
영향을 받는 영역으로 확대/축소합니다.
CPU 사용량(정밀) 그래프를 추가하고 프로세스/스레드별 사용률 미리 설정을 적용합니다.
고급 대화 상자를 사용하여 NewThreadId의 오른쪽에 고유 개수 집계 모드가 있는 CPU 열을 추가합니다.
그래프를 필터링하여 관심 있는 스레드만 표시합니다.
CPU 열의 값은 현재 시간 간격 동안 스레드가 실행된 프로세서 수를 반영합니다. CPU 사용률이 100%인 기간 동안 이 숫자는 이 스레드가 실행될 수 있는 프로세서의 수와 유사합니다. 값이 사용 가능한 프로세서 수보다 작으면 스레드가 특정 CPU로 제한될 수 있습니다.
그림 41 제한된 스레드는 이 그래프의 예제를 보여 줍니다.
그림 41 제한된 스레드
스레드의 프로세서 제한 사항을 알고 나면 스레드가 선점되거나 고갈된 항목을 확인할 수 있습니다. 이렇게 하려면 스레드가 준비 상태에서 소요한 간격을 식별한 다음 해당 간격 동안 실행 중인 다른 스레드 또는 프로세스를 검사해야 합니다.
스레드가 선점되거나 고갈된 항목 확인
스레드가 준비 상태일 때를 보여 주는 그래프를 구성하고 프로세스/스레드별 사용률 미리 설정을 적용합니다.
보기 편집기를 열고 고급을 클릭한 다음 그래프 구성 탭을 선택합니다.
그림 42 준비 시간 열과 같이 시작 시간을 ReadyTime(초)으로 설정하고 기간을 Ready (us)로 설정합니다. 확인을 클릭합니다.
그림 42 준비 시간 열
보기 편집기에서 CPU 사용률(%) 열을 Ready (us) [Sum] 열로 바꿉니다.
관심 있는 스레드를 선택하여 그림 43 준비 시간 그래프와 유사한 그래프를 생성합니다.
그림 43 준비 시간 그래프
이 경우 스레드는 준비 상태에서 상당한 시간을 보냈습니다. 일반적인 우선 순위를 확인하려면 NewInPri 열에 평균 집계를 추가합니다.
이 경우 스레드의 평균 우선 순위는 정확히 8입니다. 이 숫자는 우선 순위 상승을 수신하지 않는 백그라운드 스레드일 수 있음을 나타냅니다.
평균 우선 순위를 확인한 후 스레드 실행이 허용된 CPU에 대한 CPU 활동을 확인합니다.
이 경우 스레드는 CPU 1에 대해서만 선호도가 있는 것으로 확인되었습니다.
다른 CPU 사용량(정밀) 그래프를 추가하고 CPU별 사용률 미리 설정을 적용합니다. 관련 CPU를 선택합니다.
고급 보기를 열고 이전에 찾은 우선 순위에 대한 필터를 추가하여 해당 스레드를 필터링합니다. 이 시나리오는 그림 44 스레드 필터에 나와 있습니다.
그림 44 스레드 필터
그림 45 CPU 사용량, 준비 시간, 기타 스레드 활동에서 위쪽 그래프는 스레드 3548의 CPU 사용량을 보여 줍니다. 중간 그래프는 스레드가 준비된 시간을 보여 줍니다. 아래쪽 그래프는 스레드가 실행되도록 허용된 CPU(이 경우 Cpu1)에 대한 활동을 보여 줍니다.
그림 45 CPU 사용량, 준비 시간, 기타 스레드 활동
해당 간격 동안 대부분의 시간 동안 스레드가 준비되었지만 실행되지 않은 영역을 확대/축소합니다.
CPU 사용량 그래프에서 막대의 왼쪽에 NewInPri를 추가하고 결과를 확인합니다.
대상 스레드 우선 순위와 동일한 우선 순위가 있는 스레드 또는 프로세스는 스레드가 고갈된 시간을 표시합니다. 대상 스레드 우선 순위보다 우선 순위가 높은 스레드 또는 프로세스는 스레드가 선점된 시간을 표시합니다. 모든 선점 스레드 및 작업의 시간을 추가하여 스레드가 선점된 총 시간을 계산할 수 있습니다.
그림 46 대상 스레드가 준비되었을 때의 우선 순위별 사용량은 스레드 시간 730밀리초가 선점되고 스레드 시간 300밀리초가 고갈되었음을 보여 줍니다. (이 그림은 1192밀리초 간격으로 확대/축소됩니다.)
그림 46 대상 스레드가 준비되었을 때의 우선 순위별 사용량
이 스레드의 선점 및 고갈을 담당하는 스레드를 확인하려면 NewInPri 열 오른쪽에 NewProcess 열을 추가하고 프로세스가 실행 중인 우선 순위 수준을 검토하세요. 이 경우 선점과 고갈은 주로 동일한 프로세스의 다른 스레드와 TestResidentApp.exe에 의해 발생했습니다. 이러한 프로세스는 기본 우선 순위보다 높은 우선 순위를 주기적으로 받는다고 가정할 수 있습니다.
해결
구성 또는 구성 요소를 변경하여 선점 또는 고갈 문제를 해결할 수 있습니다. 다음 해결 방법을 고려하세요.
시스템에서 문제가 있는 프로세스를 제거합니다.
문제가 있는 프로세스의 기본 우선 순위를 조정합니다.
문제가 있는 프로세스가 실행되는 시간을 변경합니다. 예를 들어 컴퓨터가 다시 부팅되면 시작 시간을 지연합니다.
문제가 있는 구성 요소를 변경할 수 있는 경우 CPU를 덜 사용하거나 더 낮은 우선 순위에서 실행되도록 다시 설계합니다.
DPC/ISR 간섭
DPC 및 ISR을 실행하여 과도한 프로세서 시간을 소요하는 경우 스레드를 실행하는 데 사용 가능한 CPU 시간이 충분하지 않을 수 있습니다. 이러한 상황은 스레드 간섭에 대해 유사한 지연을 초래할 수 있습니다. 스레드가 비디오 재생 또는 애니메이션과 같은 정기적인 고주파 속도로 작업을 완료해야 하는 경우 DPC 및 ISR의 간섭으로 인해 운영 문제가 발생할 수 있습니다.
문제 식별
많은 평가에서 추론을 사용하여 DPC/ISR 관련 문제를 식별합니다. DPC/ISR 활동은 다음 형식의 문제로 보고될 때 의심스러운 것으로 식별됩니다.
DPC D가 P 동안 m밀리초로 x번 임계값을 초과합니다. 이 DPC의 n 인스턴스는 총 t밀리초 동안 실행됩니다.
여기서 D는 DPC, m은 임계값을 설정하는 밀리초 수, x는 DPC가 임계값을 초과한 횟수, P는 현재 프로세스, n은 DPC가 실행한 인스턴스 수, t는 DPC가 임계값을 초과하여 실행한 총 시간(밀리초)입니다.
예를 들어 다음 문제는 평가에 의해 보고됩니다.
DPC sdbus.sys!SdbusWorkerDpc는 미디어 엔진 수명 동안 목표인 3.0밀리초를 153회 초과했습니다. 총 864밀리초 동안 해당 DPC의 153개 인스턴스가 실행됩니다.
문제 이벤트 또는 지연을 나타내는 활동에 대해 이 문제가 보고되면 DPC/ISR 활동이 원인일 수 있습니다.
수동으로 DPC/ISR 간섭 식별
DPC/ISR 간섭을 수동으로 식별하려면 WPA에서 추적을 열고 관심 있는 문제 이벤트를 식별합니다. Microsoft-Windows-Dwm-Core:SCHEDULE_GLITCH 또는 Microsoft-Windows-MediaEngine:DroppedFrame과 같은 평가별 일반 이벤트입니다.
이벤트 그래프 옆에 CPU별 DPC/ISR 기간 그래프를 추가합니다. CPU별 DPC/ISR 기간 그래프의 최댓값이 문제 이벤트와 일치하는 경우 DPC/ISR이 문제를 일으키는 요인일 수 있습니다.
추가 데이터의 경우 여러 문제 이벤트가 표시되기 전에 100밀리초가 발생하는 기간을 확대/축소합니다. 문제 이벤트가 발생하기 전에 중요한 DPC/ISR 작업이 100밀리초 영역의 하나 이상의 프로세서에 표시되는 경우 문제 이벤트가 DPC/IRS 활동으로 인해 발생했다는 결론을 내릴 수 있습니다.
DPC/ISR 간섭으로 인해 지연이 발생하는지 확인하려면 실행 중인 스레드를 표시하는 영역으로 확대/축소합니다. 이 스레드가 실행되고 있는 CPU 또는 CPU를 기록합니다.
DPC/ISR 그래프에서 CPU별 DPC/ISR 기간 미리 설정을 적용하고 해당 시간 범위의 관련 CPU에서 DPC/ISR 활동을 확인합니다.
그림 47 문제 이벤트 및 DPC/ISR 활동은 iexplore.exe의 스레드 864가 영향을 받는 활동과 관련되어 있음을 보여 줍니다. 스레드 864는 보기에 있는 시간 범위의 10.65%에 대해 CPU2에서 실행 중인 상태입니다. 그러나 DPC/ISR 그래프는 CPU2가 해당 시간의 10% 동안 DPC/ISR을 실행하는 데 사용 중임을 보여 줍니다.
참고 대부분의 DPC/ISR은 이 예제에 나온 것처럼 큰 영향을 미치지 않습니다.
그림 47 문제 이벤트 및 DPC/ISR 활동
그림 48 문제 이벤트와 관련 없는 DPC/ISR은 성능 문제와 관련이 없는 것으로 표시됩니다.
그림 48 문제 이벤트와 관련 없는 DPC/ISR
그림 49 DPC/ISR 간섭으로 인한 지연에서 DPC/ISR은 성능 문제를 일으키는 것으로 표시됩니다.
그림 49 DPC/ISR 간섭으로 인한 지연
조사
DPC/ISR이 문제 또는 지연과 관련되어 있음을 확인한 후에는 어떤 특정 DPC/ISR이 관련되어 있는지와 자주 발생하거나 과도한 시간 동안 실행되는 이유를 확인해야 합니다.
기술: 평가에서 보고된 DPC/ISR 문제 검토
평가에서 보고된 DPC/ISR 문제에서 DPC 또는 ISR에서 선점된 주요 프로세스를 표시하는 문제를 확장할 수 있습니다. 스택을 확장하여 영향을 받은 활동과 가장 관련이 있는 프로세스에 대한 DPC 활동을 확인하려면 다음과 같이 스택을 확장하여 DPC가 수행한 작업을 이해합니다. 그림 50 확장된 DPC 스택은 확장된 스택을 보여 줍니다.
그림 50 확장된 DPC 스택
기술: 가장 긴 DPC/ISR 찾기 및 스택 검토
평가에서 DPC/ISR을 문제로 보고하지 않는 경우 DPC/ISR 및 CPU 사용량(샘플링) 그래프를 사용하여 가장 관련성이 큰 DPC에 대한 스택 정보를 가져올 수 있습니다. 관심 있는 DPC/ISR을 찾고 해당 모듈과 기능을 확인한 다음 CPU 사용량(샘플링) 그래프에서 샘플을 찾아 전체 스택 정보를 얻는 것이 좋습니다.
가장 긴 DPC/ISR 찾기 및 스택 검토
관심 간격으로 확대/축소합니다.
DPC/ISR 그래프에서 미리 설정된 모듈/함수별 DPC/ISR 기간을 선택합니다.
기호가 로드되면 DPC/ISR 이벤트가 총 기간별로 정렬된 다음 모듈 및 함수별로 분류됩니다. 목록의 맨 위 행에는 이벤트 문제를 발생시킨 DPC/ISR 이벤트가 포함되어 있습니다. 모듈 및 함수 이름을 기록합니다.
CPU 사용량(샘플링) 그래프에서 프로세스별 사용률 미리 설정을 선택합니다. 기본적으로 이 미리 설정은 DPC/ISR 활동을 숨깁니다.
보기 편집기를 열고 고급을 클릭합니다.
필터 탭에서 필터와 일치하는 행 숨기기 설정을 필터와 일치하는 행 유지로 변경합니다. 이렇게 하면 DPC/ISR 활동을 표시할 수 있습니다.
프로세스 열을 제거하고 스택 열을 추가하여 스택별로 정렬된 DPC/ISR을 봅니다.
현재 행 선택을 취소합니다.
스택 열에서 셀을 마우스 오른쪽 단추로 클릭한 다음 이 열에서 찾기를 클릭합니다.
이 절차의 2단계에서 기록한 모듈 및 함수를 입력합니다.
현재 선택 영역에 추가를 선택하고 모두 찾기를 클릭하여 함수의 모든 인스턴스를 선택합니다.
모든 행을 선택한 후 마우스 오른쪽 단추를 클릭하고 나비/수신자 보기를 클릭합니다.
이 보기는 총 기간별로 정렬된 이 특정 함수의 활동을 보여 줍니다. 보기는 평가에서 보고된 문제의 자세한 보기에 표시되는 스택과 유사합니다. 가중치 열은 스택의 각 함수에서 소요되는 포함 시간을 밀리초 단위로 근사치를 계산합니다.
이 보기는 그림 51 대략적인 기간별로 정렬된 DPC의 수신자에 나와 있습니다.
그림 51 대략적인 기간별로 정렬된 DPC의 수신자
기술: 장기 실행 DPC/ISR 검토
DPC/ISR의 총 기간도 중요하지만 장기 실행되는 개별 DPC/ISR은 지연을 유발할 가능성이 더 큽니다. DPC/ISR 그래프에서 내림차순으로 정렬된 포괄 기간(ms) 열은 개별 DPC/ISR의 최대 기간을 표시합니다. 일부 평가 프로필에서 사용할 수 있는 미리 설정된 긴 DPC/ISR을 사용하면 이 보기를 필터링하여 포괄 기간이 1밀리초보다 긴 DPC/ISR만 표시할 수 있습니다.
참고 이 미리 설정을 사용할 수 없는 경우 보기 편집기, 고급 섹션을 열어 필터를 추가할 수 있습니다.
해결
DPC/ISR 활동은 하드웨어 또는 구성 요소 수준에서 수정해야 하는 하드웨어 또는 소프트웨어 문제를 반영하는 경우가 많습니다. 구성 수준에서 하드웨어를 교체하거나 관련 드라이버를 고정 버전으로 업그레이드할 수 있습니다. 구성 요소 수준에서 하드웨어 및 드라이버는 MSDN의 DPC/ISR에 대한 모범 사례를 따라야 하며 가능한 경우 스레드 DPC를 사용해야 합니다. 스레드 DPC는 Windows 클라이언트 버전의 디스패치 수준에서 실행되지 않습니다. DPC/ISR에 대한 모범 사례에 대한 자세한 내용은 ISR 및 DPC 동작에 대한 지침 및 스레드 DPC 개요를 참조하세요.
관련 항목
Windows Vista 및 Windows Server 2008의 PPM