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

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

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

이것은 준비 서버에 있으며 사이트는 이 시점에서 테스터로부터 매우 가벼운 트래픽만 수신합니다.

서버에서 ANTS 프로파일러를 실행했지만, 아직 실행되지 않았습니다.

어디서 이러한 에피소드의 원인과 그 동안 CPU를 사용 중으로 유지하는 코드를 찾을 수 있습니까?

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

별로 해결책은 아니지만, 오래된 학교에 가서 IIS 프로세스의 이미지 스냅샷을 캡처하고 디버깅해야 할 수도 있습니다.Tess Ferandez의 블로그도 확인해 보십시오. 그녀는 마이크로소프트 에스컬레이션 엔지니어로 Windows ASP 디버깅에 중점을 두고 있습니다.NET, 그러나 블로그는 일반적으로 윈도우 디버깅과 관련이 있습니다.ASP를 선택하는 경우.NET 태그(내가 링크한 항목)를 클릭하면 유사한 항목이 여러 개 표시됩니다.

CPU가 100%로 급증하고 이 상태를 유지하는 경우 교착 상태 시나리오나 무한 루프가 발생할 가능성이 높습니다.프로파일러는 무한 루프를 찾기 위한 좋은 선택인 것 같습니다.하지만 교착 상태는 추적하기가 훨씬 더 어렵습니다.

프로세스 탐색기는 문제 해결을 위한 훌륭한 도구입니다.CPU 사용량이 많은 문제를 찾기 위해 시도해 볼 수 있습니다.응용프로그램의 작동 방식에 대한 통찰력을 제공합니다.

Procdump를 사용하여 프로세스를 덤프하고 CPU에서 실제로 어떤 일이 발생했는지 분석할 수도 있습니다.

또한, 당신의 perfmon 카운터를 보세요.이들은 CPU 사용 시간의 상당 부분을 알려줄 수 있습니다.다음은 사용할 가장 일반적인 카운터에 대한 링크입니다.

• http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/852720c8-7589-49c3-a9d1-73fdfc9126f0.mspx?mfr=true
• http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/be425785-c1a4-432c-837c-a03345f3885e.mspx?mfr=true

대량의 데이터를 출력에 덤프하는 재귀 쿼리에 대해 이 작업을 수행했습니다. 모든 것이 종료되고 무한 루프가 존재하지 않는지 이중으로 확인했습니까?

하나의 페이지로 범위를 좁히려고 할 수도 있습니다. 우리는 같은 경우에도 개미가 별로 도움이 되지 않는다는 것을 발견했습니다. 우리가 사이트를 운영하는 것은 CPU 페이지를 보는 것이었습니다. 다음 페이지를 보는 CPU를 치는 것이었습니다. 매우 체계적이고 시간이 많이 걸리지만 코드 추적으로 찾을 수 없다면 운이 없을 수도 있습니다.

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

도움이 되길 바랍니다!

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

따라서 릴리스 모드에서 구축 및 배포를 수행하는 것이 충분히 간단합니다.

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

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

로드하는 데 시간이 걸리는 페이지를 식별하는 경우 쉐어포인트의 개발자 대시보드를 사용하여 시간이 걸리는 구성 요소를 확인하십시오.

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