100 % CPU를 사용하는 W3WP.EXE-어디서부터 시작해야합니까?
IIS6에서 실행되는 ASP.NET 웹앱은 주기적으로 CPU를 최대 100 %까지 사용합니다. 이 에피소드 동안 거의 모든 CPU 사용을 담당하는 것은 W3WP입니다. CPU는 몇 분에서 한 시간 이상까지 100 % 고정 상태를 유지합니다.
이것은 스테이징 서버에 있으며 사이트는이 시점에서 테스터로부터 매우 적은 트래픽을 받고 있습니다.
우리는 서버에서 ANTS 프로파일 러를 실행했지만 깨달음을 얻지 못했습니다.
이 에피소드의 원인과 그 시간 동안 CPU를 계속 사용하는 코드가 무엇인지 어디에서 찾을 수 있습니까?
- 표준 Windows 성능 카운터 (많은 GET 요청, 과도한 네트워크 또는 디스크 I / O 등과 같은 다른 상호 관련된 활동을 찾습니다) 코드는 물론 perfmon에서도 읽을 수 있습니다 (예 : CPU 사용량이 임계 값을 초과하는 경우 데이터 수집을 트리거하기 위해).
- 사용자 지정 성능 카운터 (특히 실행 시간이 불확실한 오프 박스 요청 및 기타 호출 시간)
- Visual Studio Team Test 또는 WCAT와 같은 도구를 사용한 부하 테스트
- IIS 7에서 테스트하거나 업그레이드 할 수있는 경우 요청에 특정 시간이 더 오래 걸리는 경우 추적을 생성하도록 Failed Request Tracing을 구성 할 수 있습니다.
- logparser를 사용하여 CPU 스파이크 시점에 도착한 요청 확인
- 코드 검토 / 연습 (특히 오류 발생과 같이 제대로 종료되지 않을 수있는 루프, 정적 사용과 같은 잠금 및 잠재적 스레딩 문제를 찾습니다)
- CPU 및 메모리 프로파일 링 (프로덕션 시스템에서는 어려울 수 있음)
- 프로세스 탐색기
- Windows 리소스 모니터
- 자세한 오류 로깅
- 실행 시간 세부 정보를 포함한 사용자 지정 추적 로깅 (CPU 사용 성능 카운터에 따라 조건부 일 수 있음)
- AppPool이 재활용 될 때 오류가 발생합니까? 그렇다면 단서가 될 수 있습니다.
그다지 답은 아니지만 구식으로 가서 IIS 프로세스의 이미지 스냅 샷을 캡처하고 디버깅해야 할 수도 있습니다. Tess Ferrandez 의 블로그 를 확인해보십시오. 그녀는 마이크로 소프트 에스컬레이션 엔지니어이고 그녀의 블로그는 Windows ASP.NET 디버깅에 초점을 맞추고 있지만이 블로그는 일반적으로 Windows 디버깅과 관련이 있습니다. ASP.NET 태그 (내가 연결 한 태그)를 선택하면 유사한 항목이 여러 개 표시됩니다.
CPU가 100 %까지 급증하고 계속 유지된다면 교착 상태 시나리오 나 무한 루프가있을 가능성이 큽니다. 프로파일 러는 무한 루프를 찾는 데 좋은 선택 인 것 같습니다. 그러나 교착 상태는 추적하기가 훨씬 더 어렵습니다.
Process Explorer 는 문제 해결을위한 훌륭한 도구입니다. 높은 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
엄청난 양의 데이터를 출력에 덤핑하는 재귀 쿼리에 대해 이것을 가지고있었습니다. 모든 것이 종료되고 무한 루프가 존재하지 않는지 다시 확인 했습니까?
단일 페이지로 범위를 좁히려 고 할 수 있습니다. ANTS가 같은 경우에도별로 도움이되지 않는다는 것을 알았습니다. 결국 사이트를 실행하여 페이지를 쳐서 CPU를 봅니다-다음 페이지를 쳐서 CPU를 봅니다-매우 체계적입니다 시간이 많이 걸리지 만 일부 코드 추적으로 찾을 수 없다면 운이 좋지 않을 수 있습니다.
IIS 로그 파일을 사용하여 의심스러운 페이지 집합을 추적 할 수있었습니다.
도움이 되길 바랍니다!
이것은 기껏해야 추측이지만 개발 팀은 릴리스 모드가 아닌 디버그 모드에서 애플리케이션을 빌드하고 배포 할 수 있습니다. 이로 인해 .pdb 파일이 발생합니다. 이는 응용 프로그램이 시스템 실행 중에 시스템 상태 및 디버깅 정보를 수집하기 위해 추가 리소스를 사용하여 더 많은 프로세서 사용률을 유발한다는 의미입니다.
따라서 릴리스 모드에서 빌드 및 배포하고 있는지 확인하는 것은 간단합니다.
이것은 매우 오래된 게시물이지만, 이것은 또한 일반적인 문제입니다. 제안 된 모든 방법은 매우 훌륭하지만 항상 프로세스를 가리키며 사이트가 문제를 일으키고 있음을 이미 알고있을 가능성이 많지만 특정 페이지가 처리에 너무 많은 시간을 소비하고 있는지 알고 싶습니다. 제 생각에 가장 정확하고 간단한 도구는 IIS 그 자체입니다.
- IIS의 왼쪽 창에서 서버를 클릭하기 만하면됩니다.
- 기본 창에서 '작업자 프로세스'를 클릭합니다. 어떤 응용 프로그램 풀이 CPU를 너무 많이 사용하고 있는지 이미 알고 있습니다.
- 이 풀에서 CPU 시간을 너무 많이 소비하는 페이지 ( '경과 시간'열)를 보려면이 줄을 두 번 클릭합니다 ( '모두 표시'를 클릭하여 결국 새로 고침).
로드하는 데 시간이 걸리는 페이지를 식별하는 경우 SharePoint의 개발자 대시 보드 를 사용 하여 시간이 걸리는 구성 요소를 확인합니다.
참조 URL : https://stackoverflow.com/questions/2052633/w3wp-exe-using-100-cpu-where-to-start
'programing' 카테고리의 다른 글
Distributed Lock Service (0) | 2021.01.15 |
---|---|
C 전처리 기가 먼저 주석을 제거하거나 매크로를 확장합니까? (0) | 2021.01.15 |
SQL Server에서 행 수준 잠금을 강제 할 수 있습니까? (0) | 2021.01.15 |
Gson 선택 및 필수 필드 (0) | 2021.01.15 |
VirtualBox의 Ubuntu에서 인터넷 액세스 (0) | 2021.01.15 |