7 월에 Azure 웹 앱을 다시 배포했으며 약 3 주 전까지 완벽하게 실행되었습니다. 그 당시에는 CPU 사용률이 지속적으로 80 %에서 100 % 사이에 있음을 알 수 있었으며 트래픽이 증가하지 않았습니다. 처음으로 이것을 보았을 때, 이것이 내 앱이 아니거나 트래픽 증가로 인한 것으로 결론을 내린 후 웹 앱 서비스를 다시 시작했고 CPU 사용률이 정상 5 %에서 15 %로 돌아 왔습니다. 그런 다음 며칠 후 다시 그것을하기 시작했습니다. 다시 한 번 다시 시작하여 문제가 해결되었습니다.Web App Service - 얼마나 자주 다시 시작해야합니까?
내 질문은 여기 있습니다. 웹 서비스를 매일 다시 시작해야하는 것이 정상입니까? 그리고 그렇다면 왜?
코드에 변경된 사항이없고 트래픽이 증가하지 않았다고 가정하면 이는 정상이 아닙니다. 앱을 설치하지 않은 Azure 웹 앱은 거의 항상 0 %의 CPU 사용률을 유지해야합니다. Microsoft는 진단 및 모니터링 도구를 백그라운드에서 실행하여 매우 일시적인 스파이크를 유발할 수 있기 때문에 "거의 항상"이라고 말합니다. 해당 문제의 스레드에 대해서는 See here입니다.
내 권장 사항은 다음과 같습니다
CPU 못과이 말뚝을 박는 상태를 유지, 당신의 SCM 사이트에 로그인합니다. Process Explorer를 확인하고 w3wp.exe인지 확인하십시오 (CPU에 고정되어있는 w3wp.exe가 있습니다).
마음에 들지 않는 사이트 익스텐션이나 WebJob이 없는지 확인하십시오. 사이트 확장 -> 설치된 탭에서 SCM 사이트에 설치된 Site Extensions를 확인할 수 있습니다. 모든 WebJob은 SCM 프로세스 탐색기에 1 단계와 별개의 프로세스로 표시됩니다.
Azure 포털에 로그인하고 웹 응용 프로그램 관리 블레이드를 찾습니다. 진단 및 문제 해결 블레이드로 이동하십시오. 여기에서 "인스턴스 별 메트릭"을 시도하고 모든 성능 카운터를 검토하여 문제의 단서를 제공하는지 확인할 수 있습니다. 예를 들어, SignalR을 한 번 실행하고 스레드 수를 제어 할 수 없다는 사실을 발견했을뿐입니다.
진단 및 문제 해결 블레이드에서 응용 프로그램 이벤트를 선택할 수도 있습니다.
웹 응용 프로그램에 Application Insight를 설치하면 약간의 문제가 발생할 수 있습니다. 며칠 동안 문제를 해결할 수있는 충분한 공간을 확보 할 수있는 무료 티어가 있습니다. 이 코드가 바나나로 바뀌면 여기서 통찰력을 얻을 수 있습니다.
여기에는 완전성을 위해 실패한 요청 추적 로그가 포함됩니다. 그러나 이것들은 Application Insights에 나타날 것입니다.
이러한 모든 가능성을 모두 소진 한 경우 Microsoft에 지원 티켓을 제출하십시오. 위의 링크에서 알 수 있듯이 진단 도구에 액세스 할 수 없기 때문에 진단 도구 나 인프라 프로세스가 폭주 할 가능성을 없앨 수 있습니다. CPU 스파이크가 w3wp.exe로 인해 CPU가 급증하면 얼마나 많은 도움이 될지 모르겠다.
은 물론, 앱을 재배치하기 심각하게 쉽게하고 말도 안되는 번거 로움이 아니라면, 당신은 단지 그것을 제공-다시 수와 같은 동작을 볼 수 있는지 확인합니다.
@RandyMinder, 문제를 해결하는 행운이 있었나요? –
아니요. 앱 서비스를 마지막으로 다시 시작한 이후로 문제가 다시 발생하지 않았기 때문에 아니요. –
롭의 제안에 추가. 예. 문제를 해결하기 위해 웹 애플리케이션을 재시작하지 말고 오히려 증가 된 CPU 소비를 유발하는 요인을 파악하십시오. 먼저 프로세스 덤프를 작성한 후 프로세스 덤프를 분석하십시오. https://blogs.msdn.microsoft.com/asiatech/2016/01/20/how-to-capture-dump-when-intermittent-high-cpu-happens-on-azure-web-app/ Azure 서비스 상태를 확인하는 것이 좋습니다. 모든 문제 : https://docs.microsoft.com/en-us/azure/service-health/service-health-overview – Ajay