Escape From The Troubles : Performance

High CPU utilization 이슈를 Troubleshooting 하기 위한 자료 수집

escapetrouble — Sun, 27 Sep 2009 23:50:00 GMT

자료 수집 구분을 위해 아래 사항을 확인합니다.

1. 어떤 프로세스가 대부분의 CPU time 을 사용하고 있는가?
2. CPU time 이 Kernel mode 에 있는지 User mode 에 있는지?
(Process Explorer, Task Manager, Qslice : Kernel - Red, User - Green)

만약 CPU time 이 3rd party 프로세스에 있다면, 3rd party 업체에 적절한 담당자를 Engage 합니다.

만약 CPU time 이 System 프로세스가 아닌 특정 프로세스에 있고, 대부분 User time 에 있다면,
1. Threads 를 포함한 표준 Counters를 포함하여 Performance log 를 시작합니다.
2. 증상이 나타나는 동안 Adplus 툴을 통해 해당 프로세스에 대해 3개의 User dump 를 생성합니다.

만약 CPU time 이 System 프로세스가 아닌 특정 프로세스에 있고, 대부분 Kernel 또는 Kernel 과
User 사이에 나눠져 있다면,
1. Memory dump 수집을 위한 설정을 합니다.
2. Threads 를 포함한 기본 Counters를 포함하여 Performance log 를 시작합니다.
3. 증상이 나타나는 동안 Adplus 툴을 통해 해당 프로세스에 대해 3개의 User dump 를 생성합니다.
4. 증상이 나타나는 동안 전체 메모리 덤프를 수집합니다.

만약 CPU time 이 System 프로세스에 있다면,
1. Memory dump 수집을 위한 설정을 합니다.
2. Threads 를 포함한 기본 Counters를 포함하여 Performance log 를 시작합니다
3. CPU time 을 소모하는 Thread 에 드라이버를 Map 하기 위해 아래 단계를 진행합니다.
만약, Core OS component를 다시 가리킨다면, Memory dump 가 필요합니다.
4. 증상이 나타나는 동안 전체 메모리 덤프를 수집합니다.

Device driver를 System thread 에 Map 하는 방법
- 단일 또는 그룹의 Threads 가 CPU의 Primary consumer 인지를 확인합니다.
- Perfmon 에서 이 Thread(s) 의 시작 주소(10진수)를 수집합니다.
- 계산기 Calc.exe 를 통해 10진수(Decimal) 주소를 16진수(Hex)로 변환합니다.
- 이 주소를 Pstat 의 끝에 로드된 Driver 에 Match 시킵니다.

이 방법으로 High CPU 를 사용하고 있는 Driver를 확인합니다.

참고
< Perfmon 로그 수집 - 기본 Counters >
1. 시작 - 실행에서 cmd를 실행합니다.
2. Perfmon에 Counters를 추가하기 위해 아래 명령을 입력 후 실행합니다. (예: 수집 간격: 5분, 250MB)
    Logman.exe create counter Perf-Counter-Log -o "c:\perflogs\Perftest.blg" -f bincirc -v mmddhhmm -max 250 -c "\LogicalDisk(*)\*" "\Memory\*" "\Network Interface(*)\*" "\Paging File(*)\*" "\PhysicalDisk(*)\*" "\Processor(*)\*" "\Process(*)\*" "\Redirector\*" "\Server\*" "\System\*" -si 00:05:00
    참고: 필요에 따라 수집 간격 00:05:00 (5분)을 변경합니다.
3. 아래 명령으로 Log를 시작합니다.
    Logman.exe start Perf-Counter-Log
문제가 되는 동안의 기간을 기다립니다.
4. 아래 명령으로 Log를 중지합니다.
    Logman.exe stop Perf-Counter-Log

< Adplus 로 User dump 생성 방법 >
1. 아래 링크를 클릭하셔서 최신 버전의 Windows debugger 툴을 문제의 시스템에 설치합니다.
    <32bit 운영 체제>
    http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx
    <64bit 운영 체제>
    http://www.microsoft.com/whdc/devtools/debugging/install64bit.mspx
2. 덤프 파일을 저장할 위치에 대한 C:\temp\dump 폴더를 생성합니다.
3. 작업 관리자에서 문제의 프로세스에 대한 PID를 확인합니다.
4. 도스창을 실행하신 후 Debugging Tools for Windows 가 설치된 폴더로 이동하신 후 아래를 실행합니다.
   <PID> 는 위의 3번에서 확인한 PID 번호입니다.

C:\Program Files\Debugging Tools for Windows> Adplus -hang -p <PID> -o c:\temp\dump

   (위의 명령 실행 시 Defaul script interpreter를 WScript.exe 에서 CScript.exe로 변경한다는 안내 창을
   받을 수 있습니다. CScript로 변경하는 이 메시지에 OK를 누르십시오. 또한, _NT_SYSBOL_PATH 가 설정되어야
   된다는 메시지를 오류 메시지는 무시합니다).

    참고!
    286350 How To Use ADPlus to Troubleshoot "Hangs" and "Crashes"
    http://support.microsoft.com/?id=286350

< Memory dump 수집을 위한 설정>
1. 시작 - 실행에서 regedit 을 실행하여 레지스트리 편집기를 오픈합니다.
2. 아래 레지스트리 키 위치에서 “편집 - 새로 만들기 - DWORD 값"을 선택하신 후 아래 정보에 맞게
   데이타를 추가합니다.

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters (PS/2 키보드)
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\kbdhid\Parameters    (USB 키보드)

     값 이름: CrashOnCtrlScroll
     값 형식: REG_DWORD
     값 데이타: 1

3. 덤프 유형 설정을 위해 아래 레지스트리 키 위치로 이동합니다.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl

3. 해당 키의 CrashDumpEnabled 값을 두 번 클릭하신 후 데이타를 1로 설정합니다.

참고: 1은 전체 메모리 덤프, 2는 커널 메모리 덤프, 3은 작은 메모리 덤프

4. 레지스트리 편집기 창을 종료합니다.
5. 설정 변경 적용을 위해 시스템을 재 시작합니다.

Windows 2008 Server Core에서 성능 로그 수집하는 방법

escapetrouble — Wed, 19 Aug 2009 03:58:00 GMT

Windows 2008 Server Core를 설치하신 경우, 성능 모니터 UI를 통하여 성능 로그를 수집할 수 없습니다. 이 경우, 다른 Full installation된 Windows Server 2008에서 성능 로그 수집을 위한 설정을 xml 파일로 저장 후, Server Core에서 이를 다시 import하는 방법으로 성능 로그를 수집할 수 있습니다.

아래는 이와 같은 방법으로 Windows 2008 Server에서 성능 로그를 수집하는 방법을 설명합니다.

1. 성능 로그를 수집하고자 하는 Server Core에 연결할 수 있는 full install된 다른 Windows 2008 서버에서 먼저 아래 작업을 진행합니다.

1) 시작->실행->perfmon.exe를 실행합니다.

2) Data Collector Set -> User Defined 마우스 오른쪽 클릭 -> New -> Data Collector Set 실행

3) 이름에 ServerPerf 라고 입력합니다.

4) Create Manually (고급) 선택

5) Create data logs에서 Performance Counter 체크

6) Add 버튼을 클릭합니다.

7) Select counters from computer에서 성능 로그를 수집하고자 하는Server Core 컴퓨터를 선택하고, 수집하고자하는 성능 카운터 개체를 모두 추가합니다.

8) 샘플 간격은 적절히 설정합니다.

9) Data 저장 장소를 C:\PerfLog 로 설정합니다.

10) 생성된 ServerPerf Data collector set을 마우스 오른쪽 클릭하고, 속성을 실행합니다.

11) Stop condition 탭에서 아래 내용을 설정합니다.

A. 제한(Limit)에 도달하면, data collector set를 재시작합니다 를 체크합니다.

B. 최대 사이즈에 100MB를 입력합니다.

12) ServerPerf Data collector set을 마우스 오른쪽 클릭하고, 템플릿으로 저장 (Save template)을 실행하여, 설정 내용을 ServerPerf.xml로 저장합니다.

13) ServerPerf.xml 파일을 성능 로그를 수집 하고자 하는 Server Core 서버의 C:\Temp폴더로 복사합니다. (성능 로그를 수집 하고자 하는 Server Core 서버에서 C:\Temp 폴더를 생성합니다)

2. 성능 로그를 수집 하고자 하는 Server Core 에서 아래 작업을 진행합니다.

1) Server Core 명령 실행 창에서 아래 명령을 실행합니다.

C:\temp\logman import -n ServerPerf -xml ServerPef.xml

C:\temp\logman start ServerPerf

2) 위 명령을 실행하면, Server Core 에서 성능 모니터가 로그 수집을 시작합니다.

3) C:\PerfLog 폴더에 데이터가 수집되는지 확인합니다.

System Paged Pool 메모리 부족으로 인한 System Hang 증상

escapetrouble — Mon, 15 Jun 2009 11:04:00 GMT

Paged Pool 메모리는 시스템의 제한된 리소스로 여러 커널 모드 프로그램에서 공유하여 사용하는 커널 리소스입니다. Paged Pool 메모리가 소진될 경우, 시스템의 행 증상이 발생하게 됩니다. Paged Pool 메모리의 소진 현상의 원인 분석 및 재발 방지책을 찾기 위해서는 특정 커널 모드 프로그램이 paged pool 메모리를 과도하게 사용하고 있지 않은지 또는 시스템의 paged pool 메모리 구성이 너무 작게 설정되어 있지 않은지 등을 복합적으로 점검해 볼 필요가 있습니다.

먼저, Paged Pool 메모리 부족 현상이 발생하면 시스템 이벤트 2020 오류가 발생하게 됩니다.

이벤트 ID: 2020
원본: Srv
설명: 풀이 비었으므로, 서버가 시스템의 페이징 풀에서 할당하지 못했습니다.

현재 소모된 paged pool 메모리는 성능 모니터 (Perfmon.exe)에서 메모리/Pool Paged Bytes 카운터를 통하여 확인할 수 있습니다.

Windows 행 메모리 덤프가 수집되었다면 현재 시스템의 paged pool 메모리의 최대값 및 소모량을 좀 더 정확히 확인할 수 있습니다.

kd> !vm 1

*** Virtual Memory Usage ***
      Physical Memory:     16270   (   65080 Kb)
      Page File: \??\E:\pagefile.sys
         Current:     98304Kb Free Space:     61044Kb
         Minimum:     98304Kb Maximum:       196608Kb
      Available Pages:      5543   (   22172 Kb)
      ResAvail Pages:       6759   (   27036 Kb)
      Locked IO Pages:       112   (     448 Kb)
      Free System PTEs:    45089   ( 180356 Kb)
      Free NP PTEs:         5145   (   20580 Kb)
      Free Special NP:       336   (    1344 Kb)
      Modified Pages:        714   (    2856 Kb)
      NonPagedPool Usage:    877   (    3508 Kb)
      NonPagedPool Max:     6252   (   25008 Kb)
      PagedPool 0 Usage:     729   (    2916 Kb)
      PagedPool 1 Usage:     432   (    1728 Kb)
      PagedPool 2 Usage:     436   (    1744 Kb)
      PagedPool Usage:      1597   (    6388 Kb)
      PagedPool Maximum:   13312   (   53248 Kb)
      Shared Commit:        1097   (    4388 Kb)
      Special Pool:          229   (     916 Kb)
      Shared Process:       1956   (    7824 Kb)
      PagedPool Commit:     1597   (    6388 Kb)
      Driver Commit:         828   (    3312 Kb)
      Committed pages:     21949   (   87796 Kb)
      Commit limit:        36256   ( 145024 Kb)

!poolused 4 명령을 통해서 Paged pool memory를 많이 소모한 순으로 Paged pool tag를 리스트할 수 있습니다.

!poolused 4

Paged pool memory를 많이 소모한pool tag를 확인한 후, 아래 findstr 명령을 통하여 해당 pool tag로부터 어떤 드라이버가 해당 pool tag를 사용하였는지 확인할 수 있습니다.

findstr /m /l tag *.sys

<예>

아래 표는 Windows Server 2003 (32-bit) 시스템의 대략적인 최대 kernel resource table 입니다. 3GB 옵션이 활성화되어 있는 경우, Paged pool 메모리의 최대값은 그렇지 않은 경우에 비해 50% 정도로 줄어듭니다. 3GB 옵션이 반드시 필요한 경우가 아니라면 시스템에서 3GB 옵션은 제거하는 것이 paged pool 메모리 고갈 현상을 막을 수 있습니다.

3GB 옵션을 사용하지 않았더라도 System PTE를 기본값 이상을 늘릴 경우, 상대적으로 paged pool 메모리의 최대치를 줄어들게 되고, paged pool 메모리의 고갈 이슈가 쉽게 발생할 수 있습니다. 시스템에 System PTE가 기본값 이상으로 설정되어 있는지는 아래 레지스트리 키의 SystemPages 값을 통하여 확인할 수 있습니다.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Memory Management

다른 접근 방법으로는 Free System PTE가 여유가 있는 시스템에서 paged pool 메모리의 고갈 현상이 발생한다면, 아래 KB의 내용을 참조하여 paged pool 메모리의 최대치를 더 늘려주는 방법을 고려해 볼 수 있습니다.

서버가 시스템의 페이지된 풀에서 메모리를 할당할 수 없다
http://support.microsoft.com/?id=312362

Windows 2003 터미널 서비스 세션에서 Copy & Paste가 불규칙적으로 동작하지 않는 현상

escapetrouble — Wed, 27 May 2009 11:55:00 GMT

Windows 2003 터미널 서비스 세션에서 Local Client로 또는 Local Client에서 Windows 2003 터미널 서비스 세션으로 copy & paste가 동작하지 않는 현상이 간헐적으로 발생할 수 있습니다. 이 문제 증상을 이해하기 위해서는 Windows에서 Clipboard가 어떻게 동작하는지 내부 동작 메커니즘을 이해해야 할 필요가 있습니다. Clipboard 동작과 관련한 주요 문제는 Clipboard viewer chain 과 관련이 있습니다. Clipboard viewer chain이란 local clipboard의 변경 사항에 대한 알림을 받기 원하는 응용 프로그램들의 연결 리스트입니다. 즉, Clipboard viewer chain에 등록된 응용 프로그램 만이 clipboard의 변경 사항에 대해서 업데이트를 받게 됩니다. 그러나, 여기서 Windows clipboard chain 동작 메카니즘 상의 중요한 주의 사항이 있습니다. Clipboard viewer chain은 OS 시스템이 아닌 application 들에 의하여 control되는 메커니즘을 가지고 있습니다. 즉, Clipboard viewer chain에 등록된 application들은 Clipboard 가 정상적으로 동작하기 위하여 아래와 같은 작업을 할 책임이 있습니다.

“응용 프로그램은 Clipboard 의 업데이트 내용을 받은 후, 체인의 그 다음 viewer에게 알림 전달”

예를 들어, 현재 시스템의 Clipboard viewer 체인에 아래 4개의 application이 등록되어 있는 경우,

A -> B -> C -> D (RDPCLIP.exe)

Clipboard에 update가 발생하면, 시스템은 첫번째 viewer인 A 응용 프로그램에게 Clipboard 변경 메시지를 전달하게 됩니다. A응용 프로그램은 Clipboard 메시지를 받은 후, 그 알림 내용을 B 응용 프로그램에게 알릴 필요가 있습니다. 또한, B 응용 프로그램은 Clipboard 메시지를 전달 받은 후, 그 다음 viewer인 C 응용 프로그램에게 메시지를 전달하게 됩니다. 또한, C 응용 프로그램은 D응용 프로그램에게 Clipboard 메시지를 전달해야 합니다. 예를 들어, A, B, C는 사용자 응용 프로그램이고, D 는 터미널 서비스 세션에서 Clipboard 동작을 관린하는 RDPCLIP.exe 라고 할 수 있습니다.

이 상태에서 C 응용 프로그램이 Clipboard viewer chain 에서 빠져 나오고자 할 경우, 정상적인 경우는 아래와 같은 clipboard chain이 형성되어 있어야 합니다.

A -> B -> D (RDPCLIP.exe)

그러나, 어떤 이유로 C 응용 프로그램은 종료되었으나, 아래 와 같이 Clipboard viewer chain 에 C 응용 프로그램 정보가 여전히 남아 있다면, Clipboard viewer chain은 깨지게 되고, 터미널 서비스 세션과 local client에서 copy & paste가 동작하지 않는 문제 증상이 발생할 수 있습니다. 왜냐하면, clipboard 업데이트 메시지를 받은 B 응용 프로그램은 C 응용 프로그램에게 메시지를 전달하게 되는데, C 응용 프로그램은 이미 종료된 상태이기 때문입니다.

A -> B -> C -> D (RDPCLIP.exe)

그럼, C 응용 프로그램은 종료되었으나, Clipboard viewer chain 에 C 응용 프로그램 정보가 남아 있을 수 있는 경우는 어떤 경우에 발생할 수 있을까요? 다음은 그런 문제 상황을 설명합니다.

Clipboard 데이터는 공유 데이터로서, 특정 한 순간에는 하나의 응용 프로그램에서만 접근해야 합니다. (이는 멀티 태스크 환경에서 동기화 문제를 의미합니다.) 그러나, 아래와 같이 RDPCLIP.exe가 Clipboard 데이터를 열거하는 동안 응용 프로그램 C가 clipboard chain으로부터 빠져나오기 위해 clipbaord에 접근한다면, 실패하게 됩니다. 이 경우, 응용 프로그램 C는 Clipboard chain의 접근에 실패한 것을 체크하고, 다시 한번 시도를 해야 하지만 이를 체크하지 않고, 응용 프로그램 C가 종료되는 경우, 위와 같은 문제 상황이 발생할 수 있게 됩니다.

1. App C in the remote session opens the clipboard.

2. App C in the remote session copies data to the clipboard.

3. App C in the remote session closes the clipboard.

4. RDPCLIP is notified that the clipboard has been updated.

5. RDPCLIP opens the clipboard to enumerate through the data types.

6. RDPCLIP begins to enumerate through the data types.

7. App C in the remote session tries to open the clipboard.

8. RDPCLIP finishes enumerating through the data types.

9. App C in the remote session fails to open the clipboard.

10. RDPCLIP closes the clipboard.

다른 동기화 문제와 마찬가지로 이와 같은 문제 증상은 버그를 가지고 있는 응용 프로그램 C가 실행 중이 하더라도 항상 문제 증상이 발생하는 것은 아닙니다. 이는 동기화 문제를 일으킬 수 있는 Timing 조건 (Racing Condition)이 충족되었을 경우에만 발생하여 아주 불규칙적인 패턴으로 문제 증상이 발생하게 되는 것입니다.

결론적으로 말씀 드리면, 이 문제는 Clipboard viewer chain을 깨는 버그 응용프로그램에 의하여 발생하게 됩니다. 물론, Windows 의 Clipboard 동작 메커니즘이 응용 프로그램의 오동작에 의하여 깨질 수 있다는 Clipboard 디자인 상의 약점에 대하여 Windows Clipboard 동작 메커니즘이 비난 받을 수는 있을 것입니다. 저희 마이크로소프트 기술지원부서에도 이 문제에 대하여 본사 개발부서로 이 문제에 대한 개선을 요청하였으나, 이는 간단한 hot fix 형태로 문제를 해결할 수 없는 제품의 디자인 자체를 변경해야 하는 부분이기 때문에 hot fix의 요청은 거절되었고, 다음 버전의 Windows에서는 디자인을 변경하도록 결정되었습니다. 실제, Windows 2008 서버와 Windows Vista 클라이언트를 사용하는 경우, 응용 프로그램에 의해 제어되던 Clipboard의 동작 메커니즘은 Windows의 서브 시스템이 제어하도록 변경되었고, 위에서 설명 드린 문제점은 발생하지 않는 것으로 보고되어 있습니다.

[참고 자료]

Why does my shared clipboard not work? (Part 1)

http://blogs.msdn.com/rds/archive/2006/11/16/why-does-my-shared-clipboard-not-work-part-1.aspx

Why does my shared clipboard not work? (Part 2)

http://blogs.msdn.com/rds/archive/2006/11/20/why-does-my-shared-clipboard-not-work-part-2.aspx

Windows 2003 서버 / Windows XP 클라이언트 환경에서 이 문제 증상이 발생할 경우, 문제 증상을 해결할 수 있는 방법은, Client에서 RDP 세션을 disconnect 후 다시 connect할 수 있습니다. 이 경우, 깨어진 Clipboard viewer chain 에 RDPCLIP.exe가 다시 등록되기 때문에 Clipboard가 다시 동작할 수 있게 됩니다. 또는 Windows 2008 Server와 Windows Vista로 업그레이드할 실 경우, Clipboard 동작 메커니즘이 향상되어 응용 프로그램에 의한 Clipboard viewer chain의 깨짐 현상을 방지할 수 있습니다.

[Tool] User Mode Process Dumper를 이용하여 user process dump 를 수집하는 방법

escapetrouble — Thu, 23 Oct 2008 09:46:00 GMT

Windows에서 User mode process dump를 수집하는 방법은 몇 가지가 있습니다. Windows에 내장되어는 Dr. Watson 디버거를 사용하는 방법과 WinDBG를 이용하는 방법이 많이 사용되고 있지만, 여기서는 User Mode Process Dumper라는 tool을 이용한 user process dump 를 수집하는 방법을 소개합니다. User Mode Process Dumper는 GUI 기반의 tool이고 rule을 미리 생성해 놓으면 시스템 부팅 과정의 process crash 덤프를 수집할 수 있습니다. 예를 들어, 시스템 로그인 과정에서 explorer.exe가 crash되는 경우, explorer.exe의 프로세스의 crash 덤프를 수집할 경우 매우 유용하게 사용할 수 있습니다.

다음 실제로 explorer.exe가 crash될 때, explorer.exe의 프로세스 crash 덤프를 수집하기 위한 설정 방법을 step by step으로 설명하고 있습니다.

User Mode Process Dumper 자료 수집
1. 아래 링크를 통하여 user dump tool을 다운로드 받아 설치합니다.
http://www.microsoft.com/downloads/details.aspx?FamilyID=e089ca41-6a87-40c8-bf69-28ac08570b7e&DisplayLang=en
2. 더블 클릭하여 실행하면 실행 파일이 C:\kktools\userdump81\ folder에 저장됩니다.
3. C:\kktools\userdump81\x86\setup.exe를 실행하여 setup process실행합니다.
4. 설치 과정에서 “Dump on process termination” 기능을 enable합니다.
5. 설치가 끝나면, 제어판에서 Process dumper 를 실행합니다
6. New 를 클릭하시고, dump를 수집할 process를 입력합니다.
=> 여기에 수집하고자하는 process 이름, 예를 들면, explorer.exe 를 입력합니다.
7. 해당 아이템을 Double click 하여 process monitor rule 대화상자를 실행합니다.
8. Use custom rules 을 실행합니다
9. Dump file folder text 상자에 덤프 파일이 저장될 경로를 입력합니다.
10. All Exceptions 를 선택합니다.
11. Minidump type은 Complete, Save mode는 Cyclic Saving(5 times) 를 선택합니다.
12. Monitor process exit 을 선택하고 Minidump type은 Complete 를 선택합니다.
13. 문제 증상을 재현하면, 9번에 설정한 경로에 process덤프가 생성될 것입니다.

** 자료 수집 이후, 덤프 설정을 제거하기 위해서는 제어판/Process dumper/Process Monitoring에서 explorer.exe 를 선택 후, Remove 버튼을 클릭하시면 됩니다.