IIS 애플리케이션 풀에서 높은 CPU 문제 해결

적용 대상: 인터넷 정보 서비스

이 문제 해결사를 통해 IIS(인터넷 정보 서비스) 애플리케이션 풀에서 지속적인 높은 CPU의 원인을 파악할 수 있습니다. 웹 애플리케이션이 요청을 제공함에 따라 CPU 사용량이 증가하는 것이 정상이라는 점을 명심해야 합니다. 그러나 CPU가 장기간 높은 수준(80% 이상) 유지되는 것을 지속적으로 확인하면 애플리케이션의 성능이 저하됩니다. 이러한 이유로 가능한 경우 해결 및 수정할 수 있도록 지속적인 높은 CPU의 원인을 이해하는 것이 중요합니다.

시나리오

IIS의 애플리케이션 풀에 90%를 초과하는 높은 CPU가 장기간 발생합니다. 애플리케이션을 테스트할 때 문제가 발생하지 않습니다. 그러나 애플리케이션이 실제 사용자 로드를 경험하면 CPU는 높은 비율로 올라가고 유지됩니다. 복구하려면 애플리케이션 풀을 다시 시작해야 하지만 이렇게 하면 CPU가 다시 높은 수준으로 올라갔습니다.

도구

데이터 수집

높은 CPU 사용 문제가 발생할 때 가장 먼저 해야 할 일은 CPU를 사용하는 프로세스를 결정하는 것입니다. 작업 관리자에서 프로세스 탭을 사용하여 이 작업을 수행할 수 있습니다. 모든 사용자의 프로세스 표시 확인란을 선택해야 합니다. 다음 이미지는 이 확인란을 선택하고 높은 수준의 CPU를 사용하는 프로세스(IIS 애플리케이션 풀을 호스팅하는 프로세스)를 보여 w3wp.exe 줍니다.

스크린샷은 Windows 작업 관리자를 보여줍니다. CP U 열 아래의 w 3 w p 실행 가능 행에 85가 강조 표시됩니다. 모든 사용자의 프로세스 표시가 선택되어 있습니다.

성능 모니터 사용하여 CPU를 사용하는 프로세스를 확인할 수도 있습니다. 성능 모니터 사용에 대한 자세한 내용은 성능 데이터 분석을 참조하세요.

특정 w3wp.exe 프로세스와 연결된 애플리케이션 풀을 식별해야 하는 경우 관리 명령 프롬프트를 열고 폴더 cd %windir%\System32\inetsrv%windir%\System32\inetsrv 전환하고 를 실행합니다appcmd list wp. 그러면 w3wp.exe 프로세스의 PID(프로세스 식별자)가 따옴표로 표시됩니다. 작업 관리자에서 사용할 수 있는 PID와 해당 PID를 일치시킬 수 있습니다.

w3wp.exe 프로세스에 높은 CPU가 발생하는 것을 확인한 후에는 문제의 원인을 확인하기 위해 다음 정보를 수집해야 합니다.

  • 성능 모니터 데이터 수집기 집합입니다.
  • w3wp.exe 프로세스의 사용자 모드 메모리 덤프입니다.

이 두 가지 모두 높은 CPU 이벤트 중에 수집해야 합니다.

성능 모니터 데이터 수집기 집합 수집

성능 모니터 데이터는 높은 CPU 문제의 원인을 결정하는 데 중요한 경우가 많습니다. 또한 애플리케이션의 성능에 대한 "큰 그림" 보기를 가져오는 데 매우 유용할 수 있습니다.

Perfmon 데이터는 실시간으로 보거나 나중에 검토할 수 있는 데이터 수집기 집합에서 수집할 수 있습니다. 높은 CPU 문제를 해결하려면 데이터 수집기 집합을 수집해야 합니다. 높은 CPU 문제를 해결하기 위한 데이터 수집기 집합을 만들려면 다음 단계를 수행합니다.

  1. Windows 제어판 관리 도구를 엽니다.
  2. 성능 모니터 두 번 클릭합니다.
  3. 데이터 수집기 집합 노드를 확장합니다.
  4. 사용자 정의 를 마우스 오른쪽 단추로 클릭하고 새로 만들기 ->데이터 수집기 집합을 선택합니다.
  5. 데이터 수집기 집합의 이름으로 높은 CPU 를 입력합니다.
  6. 수동으로 만들기(고급)를 선택합니다.
  7. 다음을 선택합니다.
  8. 데이터 로그 만들기를 선택합니다.
  9. 성능 카운터 확인란을 선택합니다.
  10. 다음을 선택합니다.
  11. 추가를 선택합니다. 애플리케이션이 ASP.NET 애플리케이션이 아닌 경우 19단계로 진행합니다.
  12. 카운터 목록의 맨 위로 스크롤하고 .NET CLR 메모리를 선택합니다.
  13. 인스턴스 목록에서 모든 인스턴스를> 선택합니다<.
  14. 추가를 선택하여 추가된 카운터 목록에 카운터를 추가합니다.
  15. 카운터 목록에서 ASP.NET 선택한 다음 , 추가를 선택합니다.
  16. 카운터 목록에서 ASP.NET 애플리케이션 을 선택합니다.
  17. 인스턴스> 목록에서 모든 인스턴스를 선택합니다.<
  18. 추가를 선택합니다.
  19. 카운터 목록에서 프로세스를 확장합니다. (프로세서가 아닌 프로세스를 확장해야 합니다.)
  20. Process 개체에서 % Processor Time을 선택합니다.
  21. 인스턴스> 목록에서 모든 인스턴스를 선택합니다.<
  22. 추가를 선택합니다.
  23. 카운터 목록에서 스레드 를 확장합니다.
  24. Thread 개체에서 % Processor Time을 선택합니다.
  25. 인스턴스> 목록에서 모든 인스턴스를 선택합니다.<
  26. 추가를 선택합니다.
  27. 인스턴스 목록에서 ID 스레드 를 선택합니다.
  28. 추가를 선택합니다.

이제 대화 상자가 다음 이미지와 같이 표시됩니다.

데이터 컬렉션 0 1 속성 대화 상자를 보여 주는 스크린샷 I D 스레드는 성능 카운터 탭에서 선택됩니다.

확인 -다음을> 선택합니다. 데이터 수집기 집합이 저장되는 위치를 기록해 둡다. (필요한 경우 이 위치를 변경할 수 있습니다.) 그런 다음 마침을 선택합니다.

데이터 수집기 집합이 아직 실행되고 있지 않습니다. 시작하려면 사용자 정의 노드 아래에서 높은 CPU를 마우스 오른쪽 단추로 클릭하고 메뉴에서 시작을 선택합니다.

디버그 진단 규칙 만들기

높은 CPU 조건이 발생할 때 사용자 모드 프로세스 덤프를 수집하는 가장 쉬운 방법은 디버그 진단을 사용하는 것입니다.

DebugDiag를 다운로드하여 서버에 설치하고 실행합니다. 설치 후 시작 메뉴에서 찾을 수 있습니다. DebugDiag를 실행하면 규칙 유형 선택 대화 상자가 표시됩니다. 애플리케이션 풀에 대한 크래시 규칙을 만들려면 다음 단계를 수행합니다.

  1. 성능 -다음을> 선택합니다.
  2. 성능 카운터 ->다음을 선택합니다.
  3. 성능 트리거 추가를 선택합니다.
  4. Processor(Process 아님) 개체를 확장하고 % 프로세서 시간을 선택합니다. Windows Server 2008 R2에 있고 프로세서가 64개 이상인 경우 Processor 개체 대신 Processor Information 개체를 선택합니다.
  5. 인스턴스 목록에서 _Total 선택합니다.
  6. 추가 ->확인을 선택합니다.
  7. 새로 추가된 트리거를 선택한 다음 임계값 편집을 선택합니다. 성능 카운터 선택 대화 상자를 보여 주는 스크린샷
  8. 드롭다운에서 를 선택합니다.
  9. 임계값을 80으로 변경합니다.
  10. 초 수에 대해 20 을 입력합니다. 필요한 경우 이 값을 조정할 수 있지만 거짓 트리거를 방지하기 위해 몇 초를 지정하지 않도록 주의해야 합니다.
  11. 확인을 선택합니다.
  12. 다음을 선택합니다.
  13. 덤프 대상 추가를 선택합니다.
  14. 드롭다운에서 웹 애플리케이션 풀 을 선택합니다.
  15. 앱 풀 목록에서 애플리케이션 풀을 선택합니다.
  16. 확인을 선택합니다.
  17. 다음을 선택합니다.
  18. 다음을 다시 선택합니다.
  19. 원하는 경우 규칙의 이름을 입력하고 덤프가 저장될 위치를 기록해 둡니다. 원하는 경우 이 위치를 변경할 수 있습니다.
  20. 다음을 선택합니다.
  21. 지금 규칙 활성화를 선택한 다음 마을 선택합니다.

13-15단계에서 사용되는 것과 동일한 기술을 사용하여 여러 덤프 대상을 추가하여 여러 애플리케이션 풀의 덤프를 만들 수 있습니다.

이 규칙은 11 덤프 파일을 만듭니다. 처음 10개는 크기가 상당히 작은 "미니 덤프"가 됩니다. 최종 덤프는 전체 메모리가 있는 덤프가 될 것이며, 해당 덤프는 훨씬 더 커질 것입니다.

높은 CPU 문제가 발생하면 Perfmon 데이터 수집기 집합의 데이터 수집을 중지하려고 합니다. 이렇게 하려면 사용자 정의 노드 아래에 나열된 높은 CPU 데이터 수집기 집합을 마우스 오른쪽 단추로 클릭하고 중지를 선택합니다.

데이터 분석

높은 CPU 이벤트 후에는 검토할 데이터 집합이 두 개 있습니다. Perfmon 데이터 수집기 집합 및 메모리 덤프 먼저 Perfmon 데이터를 검토해 보겠습니다.

성능 데이터 분석

문제에 대한 Perfmon 데이터를 검토하려면 사용자 정의 노드 아래에 나열된 높은 CPU 데이터 수집기 집합을 마우스 오른쪽 단추로 클릭하고 최신 보고서를 선택합니다. 다음 스크린샷과 유사한 보고서가 표시됩니다.

성능 모니터 창을 보여 주는 스크린샷

가장 먼저 검토하려는 명시적 카운터를 추가할 수 있도록 현재 카운터를 모두 제거하는 것입니다. 목록에서 첫 번째 카운터를 선택합니다. 그런 다음 목록의 맨 아래로 스크롤하고 Shift 키를 누른 상태에서 마지막 카운터를 선택합니다. 모든 카운터를 선택한 후에는 Delete 키를 눌러 제거합니다.

이제 다음 단계를 사용하여 Process / % Processor Time 카운터 를 추가합니다.

  1. Perfmon의 오른쪽 창에서 아무 곳이나 마우스 오른쪽 단추로 클릭하고 카운터 추가를 선택합니다.
  2. Process 개체를 확장합니다.
  3. 목록에서 % Processor Time 을 선택합니다.
  4. instance 목록에서 모든 인스턴스>를 선택합니다<.
  5. 추가를 선택합니다.
  6. 확인을 선택합니다.

이제 데이터 수집기 집합이 실행되는 동안 컴퓨터의 각 프로세스에서 사용한 프로세서 시간의 그래프를 보여 주는 디스플레이가 표시됩니다. 가장 높은 수준의 CPU를 사용하는 프로세스를 격리하는 가장 쉬운 방법은 Perfmon의 주요 기능을 사용하도록 설정하는 것입니다.

이렇게 하려면 목록에서 첫 번째 카운터를 선택한 다음 Ctrl + H를 누릅니다. 이렇게 하면 선택한 프로세스가 그래프에 굵은 검은색 선으로 표시됩니다.

키보드의 아래쪽 화살표를 사용하여 CPU 사용량이 가장 많은 프로세스를 찾을 때까지 프로세스 목록을 아래로 이동합니다. 다음 스크린샷에서는 w3wp.exe 프로세스가 컴퓨터에서 많은 양의 CPU를 사용하고 있음을 명확하게 확인할 수 있습니다. 이렇게 하면 IIS 애플리케이션 풀이 컴퓨터에서 높은 CPU 사용률을 발생시키는 것을 확인합니다.

성능 모니터 창을 보여 주는 스크린샷 Perfmon은 w 3 w p 실행 파일의 C P U 사용량을 보여 줍니다.

Perfmon은 애플리케이션에서 성능 문제를 결정하는 데 매우 유용할 수 있습니다. Perfmon 로그에 수집된 데이터는 실행 중인 요청 수(ASP.NET 및 ASP.NET Applications 개체 사용)를 표시할 수 있으며 애플리케이션의 성능에 대한 다른 중요한 성능 데이터를 표시할 수도 있습니다.

높은 CPU 문제를 일으키는 원인의 루트로 이동하려면 DebugDiag를 사용하여 만든 덤프를 검토해 보겠습니다.

DebugDiag를 사용한 덤프 분석

DebugDiag에는 자동화된 덤프 분석을 수행하여 많은 문제를 인식할 수 있습니다. 이 특정 문제의 경우 DebugDiag의 성능 분석기는 높은 CPU 문제의 근본 원인을 식별하는 데 적합합니다. 분석기를 사용하려면 다음 단계를 수행합니다.

  1. DebugDiag에서 고급 분석 탭을 선택합니다.
  2. 성능 분석기를 선택합니다.
  3. 데이터 파일 추가를 선택합니다.
  4. 덤프가 만들어진 위치에 대한 브라우저입니다. 기본적으로 C:\Program Files\DebugDiag\Logs 폴더의 하위 폴더가 됩니다.
  5. 덤프 중 하나를 선택한 다음 Ctrl + A를 눌러 해당 폴더의 모든 덤프를 선택합니다.
  6. 열기를 선택합니다.
  7. 분석 시작을 선택합니다.

DebugDiag는 덤프를 구문 분석하고 분석을 제공하는 데 몇 분 정도 걸립니다. 분석을 완료하면 다음 이미지와 비슷한 페이지가 표시됩니다.

인터넷 Explorer 보여 주는 스크린샷 디버그 Diag 분석 보고서 페이지가 표시됩니다.

보고서의 맨 위에 높은 CPU가 검색되었음을 알 수 있습니다. 오른쪽 열에는 평균 CPU 시간별 상위 7개 스레드에 대한 링크가 포함된 권장 사항이 표시됩니다. 해당 링크를 선택하면 상위 CPU 소비자가 수행한 일에 대한 정보가 표시됩니다. 예를 들어 다음 스크린샷은 해당 스레드가 내 애플리케이션에서 수행하는 작업을 보여 줍니다.

브라우저의 함수 통계 페이지를 보여 주는 스크린샷

이 샘플에서는 FastApp 애플리케이션의 default.aspx 페이지가 실행되고 있습니다. 호출 스택(페이지 아래쪽)을 자세히 살펴보면 이 스레드가 문자열 연결을 수행하고 있음을 확인할 수 있습니다. (호출 스택에서 에 대한 호출 System.String.Concat 을 확인합니다.) 다른 상위 CPU 스레드를 분석하는 경우 동일한 패턴이 표시됩니다.

다음 단계는 FastApp 애플리케이션의 Page_Loaddefault.aspx 페이지에서 이벤트를 검토하는 것입니다. 이렇게 하면 다음 코드를 찾을 수 있습니다.

htmlTable += "<table>";
for (int x = 0; x < 5000; x++)
{
htmlTable += "<tr>" + "<td>" + "Cell A" + x.ToString() + "</td>";
    htmlTable += "<td>" + "Cell B" + x.ToString() + "</td>" + "</tr>";
}
htmlTable += "</table>";

이러한 종류의 코드는 확실히 높은 CPU를 일으킬 것입니다.

결론

Perfmon 및 DebugDiag를 사용하면 애플리케이션 풀에서 높은 CPU의 원인을 확인하는 데 도움이 될 수 있는 데이터를 쉽게 수집할 수 있습니다. 이러한 기술을 사용하여 근본 원인을 찾을 수 없는 경우 Microsoft 지원에 문의하여 추가 지원을 받을 수 있습니다. Microsoft 지원 엔지니어는 문제의 원인을 확인하는 데 도움을 줄 수 있습니다. 사례를 열 때 Perfmon 데이터 및 덤프를 준비하면 엔지니어가 도움을 주는 데 필요한 시간을 크게 줄일 수 있습니다.

다른 리소스