programing

100 % CPU를 사용하는 W3WP.EXE-어디서부터 시작해야합니까?

sourcetip 2021. 1. 15. 20:25
반응형

100 % CPU를 사용하는 W3WP.EXE-어디서부터 시작해야합니까?


IIS6에서 실행되는 ASP.NET 웹앱은 주기적으로 CPU를 최대 100 %까지 사용합니다. 이 에피소드 동안 거의 모든 CPU 사용을 담당하는 것은 W3WP입니다. CPU는 몇 분에서 한 시간 이상까지 100 % 고정 상태를 유지합니다.

이것은 스테이징 서버에 있으며 사이트는이 시점에서 테스터로부터 매우 적은 트래픽을 받고 있습니다.

우리는 서버에서 ANTS 프로파일 러를 실행했지만 깨달음을 얻지 못했습니다.

이 에피소드의 원인과 그 시간 동안 CPU를 계속 사용하는 코드가 무엇인지 어디에서 찾을 수 있습니까?


  1. 표준 Windows 성능 카운터 (많은 GET 요청, 과도한 네트워크 또는 디스크 I / O 등과 같은 다른 상호 관련된 활동을 찾습니다) 코드는 물론 perfmon에서도 읽을 수 있습니다 (예 : CPU 사용량이 임계 값을 초과하는 경우 데이터 수집을 트리거하기 위해).
  2. 사용자 지정 성능 카운터 (특히 실행 시간이 불확실한 오프 박스 요청 및 기타 호출 시간)
  3. Visual Studio Team Test 또는 WCAT와 같은 도구를 사용한 부하 테스트
  4. IIS 7에서 테스트하거나 업그레이드 할 수있는 경우 요청에 특정 시간이 더 오래 걸리는 경우 추적을 생성하도록 Failed Request Tracing을 구성 할 수 있습니다.
  5. logparser를 사용하여 CPU 스파이크 시점에 도착한 요청 확인
  6. 코드 검토 / 연습 (특히 오류 발생과 같이 제대로 종료되지 않을 수있는 루프, 정적 사용과 같은 잠금 및 잠재적 스레딩 문제를 찾습니다)
  7. CPU 및 메모리 프로파일 링 (프로덕션 시스템에서는 어려울 수 있음)
  8. 프로세스 탐색기
  9. Windows 리소스 모니터
  10. 자세한 오류 로깅
  11. 실행 시간 세부 정보를 포함한 사용자 지정 추적 로깅 (CPU 사용 성능 카운터에 따라 조건부 일 수 있음)
  12. AppPool이 재활용 될 때 오류가 발생합니까? 그렇다면 단서가 될 수 있습니다.

그다지 답은 아니지만 구식으로 가서 IIS 프로세스의 이미지 스냅 샷을 캡처하고 디버깅해야 할 수도 있습니다. Tess Ferrandez 의 블로그 를 확인해보십시오. 그녀는 마이크로 소프트 에스컬레이션 엔지니어이고 그녀의 블로그는 Windows ASP.NET 디버깅에 초점을 맞추고 있지만이 블로그는 일반적으로 Windows 디버깅과 관련이 있습니다. ASP.NET 태그 (내가 연결 한 태그)를 선택하면 유사한 항목이 여러 개 표시됩니다.


CPU가 100 %까지 급증하고 계속 유지된다면 교착 상태 시나리오 나 무한 루프가있을 가능성이 큽니다. 프로파일 러는 무한 루프를 찾는 데 좋은 선택 인 것 같습니다. 그러나 교착 상태는 추적하기가 훨씬 더 어렵습니다.


Process Explorer 는 문제 해결을위한 훌륭한 도구입니다. 높은 CPU 사용량 문제를 찾기 위해 시도해 볼 수 있습니다. 애플리케이션이 작동하는 방식에 대한 통찰력을 제공합니다.

Procdump 를 사용하여 프로세스를 덤프하고 CPU에서 실제로 발생한 일을 분석 할 수도 있습니다 .


또한 perfmon 카운터를 살펴보십시오. 그들은 CPU 시간이 많이 소비되는 곳을 알려줄 수 있습니다. 사용하는 가장 일반적인 카운터에 대한 링크는 다음과 같습니다.


엄청난 양의 데이터를 출력에 덤핑하는 재귀 쿼리에 대해 이것을 가지고있었습니다. 모든 것이 종료되고 무한 루프가 존재하지 않는지 다시 확인 했습니까?

단일 페이지로 범위를 좁히려 고 할 수 있습니다. ANTS가 같은 경우에도별로 도움이되지 않는다는 것을 알았습니다. 결국 사이트를 실행하여 페이지를 쳐서 CPU를 봅니다-다음 페이지를 쳐서 CPU를 봅니다-매우 체계적입니다 시간이 많이 걸리지 만 일부 코드 추적으로 찾을 수 없다면 운이 좋지 않을 수 있습니다.

IIS 로그 파일을 사용하여 의심스러운 페이지 집합을 추적 할 수있었습니다.

도움이 되길 바랍니다!


이것은 기껏해야 추측이지만 개발 팀은 릴리스 모드가 아닌 디버그 모드에서 애플리케이션을 빌드하고 배포 할 수 있습니다. 이로 인해 .pdb 파일이 발생합니다. 이는 응용 프로그램이 시스템 실행 중에 시스템 상태 및 디버깅 정보를 수집하기 위해 추가 리소스를 사용하여 더 많은 프로세서 사용률을 유발한다는 의미입니다.

따라서 릴리스 모드에서 빌드 및 배포하고 있는지 확인하는 것은 간단합니다.


이것은 매우 오래된 게시물이지만, 이것은 또한 일반적인 문제입니다. 제안 된 모든 방법은 매우 훌륭하지만 항상 프로세스를 가리키며 사이트가 문제를 일으키고 있음을 이미 알고있을 가능성이 많지만 특정 페이지가 처리에 너무 많은 시간을 소비하고 있는지 알고 싶습니다. 제 생각에 가장 정확하고 간단한 도구는 IIS 그 자체입니다.

  1. IIS의 왼쪽 창에서 서버를 클릭하기 만하면됩니다.
  2. 기본 창에서 '작업자 프로세스'를 클릭합니다. 어떤 응용 프로그램 풀이 CPU를 너무 많이 사용하고 있는지 이미 알고 있습니다.
  3. 이 풀에서 CPU 시간을 너무 많이 소비하는 페이지 ( '경과 시간'열)를 보려면이 줄을 두 번 클릭합니다 ( '모두 표시'를 클릭하여 결국 새로 고침).

로드하는 데 시간이 걸리는 페이지를 식별하는 경우 SharePoint의 개발자 대시 보드사용 하여 시간이 걸리는 구성 요소를 확인합니다.

참조 URL : https://stackoverflow.com/questions/2052633/w3wp-exe-using-100-cpu-where-to-start

반응형