Azure App Service 플랫폼에서 메모리 덤프 캡처

이 문서에서는 메모리 덤프를 캡처하기 위한 Microsoft Azure App Service 디버깅 기능에 대한 지침을 제공합니다. 사용하는 캡처 방법은 성능 또는 가용성 문제를 해결하기 위해 메모리 덤프를 캡처하는 시나리오에 따라 결정됩니다. 예를 들어 메모리 덤프 캡처는 예외를 throw하거나 느리게 응답하는 프로세스와 과도한 메모리 사용량이 발생하는 프로세스에 대해 다릅니다. 이 컨텍스트의 프로세스는 W3WP(인터넷 정보 서비스) 작업자 프로세스( w3wp.exe)입니다.

Azure App Service 디버깅 기능에 메모리 덤프 시나리오 매핑

다음 표에서는 각 App Service 기능이 메모리 덤프를 생성하기 위해 실행하는 명령에 대한 권장 사항을 제공합니다. 메모리 덤프를 캡처하는 방법은 매우 많기 때문에 프로세스가 혼동될 수 있습니다. W3WP 메모리 덤프를 캡처하는 데 이미 능숙한 경우 이 정보는 접근 방식을 변경하기 위한 것이 아닙니다. 대신, 아직 기본 설정을 개발하지 않은 경험이 없는 사용자를 위한 지침을 제공하기를 희망합니다.

확장된 프로세스 시나리오 설명

이 섹션에는 이전 표에 표시된 6가지 시나리오에 대한 자세한 설명이 포함되어 있습니다.

응답하지 않거나 느린 시나리오

웹 서버에 대한 요청이 수행되면 일반적으로 일부 코드를 실행해야 합니다. 코드 실행은 스레드의 w3wp.exe 프로세스 내에서 발생합니다. 각 스레드에는 현재 실행 중인 내용을 보여 주는 스택이 있습니다.

응답하지 않는 시나리오는 영구적이거나 시간이 초과될 수 있습니다. 따라서 응답하지 않는 시나리오는 요청이 실행되는 데 예상보다 오래 걸리는 시나리오입니다. 느려지는 것을 고려할 수 있는 것은 코드가 수행하는 일에 따라 달라집니다. 어떤 사람들에게는 3초 지연이 느립니다. 다른 사람의 경우 15초 지연이 허용됩니다. 기본적으로 속도 저하를 나타내는 성능 메트릭이 표시되거나 슈퍼 사용자가 서버가 평소보다 느리게 응답하고 있다고 표시하면 응답하지 않거나 느린 시나리오가 있습니다.

크래시(프로세스 종료) 시나리오

Microsoft .NET Framework는 수년 동안 예외 처리를 개선했습니다. 현재 버전의 .NET에서는 예외 처리 환경이 훨씬 더 좋습니다.

지금까지 개발자가 try-catch 블록 내에 코드 조각을 배치하지 않았고 예외가 throw된 경우 프로세스가 종료되었습니다. 이 경우 개발자 코드에서 처리되지 않은 예외가 프로세스를 종료했습니다. 최신 버전의 .NET은 코드를 실행하는 프로세스가 충돌하지 않도록 이러한 "처리되지 않은" 예외 중 일부를 처리합니다. 그러나 처리되지 않은 모든 예외가 사용자 지정 코드에서 직접 throw되는 것은 아닙니다. 예를 들어 액세스 위반(예: 0xC0000005 및 0x80070005) 또는 스택 오버플로는 프로세스를 종료할 수 있습니다.

크래시(처리된 예외) 시나리오

소프트웨어 개발자는 코드가 실행되는 가능한 모든 시나리오를 결정하기 위해 특별히 주의하지만 예기치 않은 상황이 발생할 수 있습니다. 다음 오류는 예외를 트리거할 수 있습니다.

• 예기치 않은 null 값
• 잘못된 캐스팅
• 누락된 인스턴스화된 개체

코드 실행을 try-catch 코드 블록에 배치하는 것이 가장 좋습니다. 개발자가 이러한 블록을 사용하는 경우 코드는 예기치 않은 이벤트 이후의 작업을 구체적으로 관리하여 정상적으로 실패할 수 있습니다. 처리된 예외는 try 블록 내에서 throw되고 해당 catch 블록에 catch되는 예외입니다. 이 경우 개발자는 예외가 발생할 수 있다고 예상하고 해당 코드 섹션을 중심으로 적절한 try-catch 블록을 코딩했습니다.

catch 블록에서는 문제를 재현하고 궁극적으로 해결할 수 있도록 로깅 원본에 충분한 정보를 캡처하는 것이 유용합니다. 예외는 성능 측면에서 비용이 많이 드는 코드 경로입니다. 따라서 많은 예외가 있으면 성능에 영향을 줍니다.

크래시(처리되지 않은 예외) 시나리오

처리되지 않은 예외는 코드가 발생할 것으로 예상하지 않는 작업을 수행하려고 할 때 발생합니다. 크래시(프로세스 종료) 시나리오에서와 같이 해당 코드는 try-catch 코드 블록에 포함되지 않습니다. 이 경우 개발자는 코드의 해당 섹션에서 예외가 발생할 수 있다고 예상하지 못했습니다.

이 시나리오는 이전의 두 예외 시나리오와 다릅니다. 크래시(처리되지 않은 예외) 시나리오에서 문제의 코드는 개발자가 작성한 코드입니다. 예외를 throw하는 프레임워크 코드가 아니며 w3wp.exe 프로세스를 종료하는 처리되지 않은 예외 중 하나가 아닙니다. 또한 예외를 throw하는 코드가 try-catch 블록 내에 있지 않으므로 예외를 정상적으로 처리할 기회가 없습니다. 코드 문제 해결은 처음에는 좀 더 복잡합니다. 이 처리되지 않은 예외를 throw하는 메서드를 식별하는 예외 텍스트, 형식 및 스택을 찾는 것이 목표입니다. 이 정보를 사용하면 try-catch 코드 블록을 추가해야 하는 위치를 식별할 수 있습니다. 그런 다음 개발자는 크래시(처리되지 않은 예외) 시나리오에 존재해야 하는 예외 세부 정보를 기록하는 유사한 논리를 추가할 수 있습니다.

과도한 CPU 사용 시나리오

과도한 CPU 사용량은 무엇인가요? 이 상황은 코드의 수행에 따라 달라집니다. 일반적으로 w3wp.exe 프로세스의 CPU 사용량이 80%인 경우 애플리케이션은 다양한 증상을 일으킬 수 있는 중요한 상황에 있습니다. 몇 가지 가능한 증상은 다음과 같습니다.

• 느림
• 오류
• 기타 정의되지 않은 동작

웹 사이트에서 정적 HTML 파일을 제공하는 경우 CPU 사용량이 20%인 경우에도 과도한 것으로 간주할 수 있습니다. 메모리 덤프를 생성하여 과도한 CPU 급증에 대한 사후 문제 해결은 메모리 덤프를 사용하는 특정 방법을 결정하는 데 도움이 되지 않을 수 있습니다. 가장 좋은 방법은 가장 오래 걸리는 요청을 확인한 다음 식별된 메서드를 테스트하여 문제를 재현하는 것입니다. 이 절차에서는 버스트를 캡처한 성능 시스템에서 성능 모니터를 실행하지 않는다고 가정합니다. 대부분의 경우 모니터를 실시간으로 지속적으로 실행하여 성능 문제를 일으킬 수 있습니다.

과도한 메모리 사용 시나리오

애플리케이션이 32비트 프로세스에서 실행되는 경우 과도한 메모리 사용이 문제가 될 수 있습니다. 소량의 활동도 할당된 가상 주소 공간의 2~3GB를 사용할 수 있습니다. 32비트 프로세스는 사용 가능한 실제 메모리 양에 관계없이 총 4GB를 초과할 수 없습니다.

64비트 프로세스는 32비트 프로세스보다 더 많은 메모리를 할당합니다. 64비트 프로세스는 프로세스에서 할당된 가상 주소 공간을 사용하는 것보다 서버의 실제 메모리 양을 소비할 가능성이 높습니다.

따라서 과도한 메모리 사용 문제를 구성하는 것은 다음 요인에 따라 달라집니다.

• 비트 처리 (32비트 또는 64비트)
• "정상"으로 간주되는 메모리 사용량입니다.

프로세스가 예상보다 많은 메모리를 사용하는 경우 분석을 위해 메모리 덤프를 수집하여 메모리 리소스를 사용하는 것을 확인합니다. 자세한 내용은 너무 많은 메모리를 사용하는 경우 App Service의 메모리 덤프 만들기를 참조하세요.

이제 메모리 덤프가 문제를 해결하는 데 도움이 될 수 있는 다양한 프로세스 시나리오에 대해 좀 더 자세히 알아보려면 Azure App Service 플랫폼에서 메모리 덤프를 캡처하는 데 권장되는 도구에 대해 설명합니다.

확장된 Azure App Service 디버깅 기능 설명

"Azure App Service 디버깅 기능에 메모리 덤프 시나리오 매핑" 섹션의 표에서 메모리 덤프 수집을 대상으로 하는 6가지 디버깅 기능을 확인했습니다. 이러한 각 기능은 진단 도구 타일을 선택할 때 문제 진단 및 해결 페이지의 Azure Portal 내에서 액세스할 수 있습니다.

다음 섹션에서는 이러한 각 디버깅 기능에 대해 자세히 설명합니다.

자동 복구(요청 기간) 기능

자동 복구(요청 기간) 기능은 응답이 완료되는 데 예상보다 오래 걸리는 경우 메모리 덤프를 캡처하는 데 유용합니다. 이전 스크린샷의 진단 도구 타일에서 자동 복구에 대한 링크를 볼 수 있습니다. 해당 링크를 선택하여 기능으로 직접 이동하거나 진단 도구 타일을 선택하여 진단 도구 페이지에서 사용 가능한 모든 도구를 검토합니다. 이 기능을 구성하는 방법에 대한 자세한 내용은 다음 문서를 참조하세요.

• App Services 자동 복구

• Azure App Services를 사용하여 진단 작업 수집 및 자동화

자동 복구 기능은 다음 스크린샷에 표시됩니다.

"메모리 덤프 수집"이라는 또 다른 기능은 문제가 현재 발생하거나 재현 가능한 경우 이 시나리오에서 유용합니다. 이 기능은 수동 요청 시 메모리 덤프를 신속하게 수집합니다.

메모리 덤프 기능 수집

메모리 덤프 수집 기능의 구성을 이해하려면 메모리 덤프 앱 서비스 수집을 참조하세요. 이 방법을 사용하려면 수동 개입이 필요합니다. 다음 스크린샷은 메모리 덤프 수집 페이지를 보여줍니다.

이 기능을 사용하려면 메모리 덤프를 저장할 스토리지 계정을 선택합니다. 그런 다음 메모리 덤프를 수집할 서버 인스턴스를 선택합니다. 인스턴스가 하나 이상 있는 경우 디버깅 중인 문제가 해당 인스턴스에서 발생하는지 확인합니다. 작동 중인 프로덕션 애플리케이션에서 다시 시작이 최적이 아닐 수 있습니다.

충돌 모니터링 기능

크래시 모니터링 기능은 처리되지 않은 예외로 인해 W3WP 프로세스가 종료되는 경우 메모리 덤프를 캡처하는 데 유용합니다. 다음 스크린샷은 진단 도구의 크래시 모니터링 페이지를 보여줍니다.

Azure App Service에서 크래시 모니터링 기능을 구성하는 방법에 대한 단계별 연습을 보려면 Azure App Service에서 크래시 모니터링을 참조하세요.

Application Insights/Log Analytics 기능의 추적

처리된 예외는 try-catch 블록에 포함된 코드가 예기치 않거나 지원되지 않는 작업을 수행하려고 시도하는 시나리오입니다. 예를 들어 다음 코드 조각은 잘못된 작업임에도 불구하고 숫자를 0으로 나누려고 합니다.

decimal percentage = 0, number = 1000, total = 0;
try
{
  percentage = number / total;
}
catch (DivideByZeroException divEx)
{
  _logger.LogError("A handled exception just happened: -> {divEx.Message}", divEx.Message);
}

이 코드 조각은 지원되지 않는 수학 연산이 try-catch 블록 내에 배치되기 때문에 처리되는 0으로 나누기 예외를 발생합니다. Application Insights는 애플리케이션 코드에 Microsoft.ApplicationInsights NuGet 패키지를 의도적으로 포함하지 않는 한 처리된 예외를 기록하지 않으며, 정보를 기록하는 코드를 추가합니다. 코드를 추가한 후 예외가 발생하는 경우 다음 스크린샷과 같이 Log Analytics에서 항목을 볼 수 있습니다.

다음 Kusto 코드에는 Log Analytics에서 데이터를 추출하는 데 사용되는 쿼리가 포함되어 있습니다.

traces
| where message has "handled"
 | project timestamp, severityLevel, message, operation_Name, cloud_RoleInstance

열은 message 예외의 근본 원인을 찾는 데 필요한 세부 정보를 저장할 수 있는 위치입니다. 이 쿼리를 작성하는 데 사용되는 코드는 0으로 나누기 코드 조각에 있습니다. 이 코드를 작성한 소프트웨어 개발자는 이러한 종류의 예외와 근본 원인을 분석하는 데 캡처하는 데 필요한 특성에 대해 물어보는 데 가장 적합한 사람입니다.

애플리케이션 코드에 이 기능을 추가하는 가장 좋은 방법은 있는 애플리케이션 코드 스택 및 버전(예: ASP.NET, ASP.NET Core, MVC, Razor 등)에 따라 달라집니다. 시나리오에 가장 적합한 방법을 확인하려면 .NET을 사용하여 Application Insights 로깅을 검토합니다.

애플리케이션 이벤트 로그(처리된 예외) 기능

다음 스크린샷과 같이 Azure Portal의 진단 도구애플리케이션 이벤트 로그 페이지에서 처리되지 않은 예외를 찾을 수도 있습니다.

이 경우 코드를 통해 기록한 것과 동일한 오류 메시지가 표시됩니다. 그러나 Application Insights 추적 로그에서 쿼리를 사용자 지정하는 방법에 대한 유연성이 손실됩니다.

Application Insights 스냅샷 디버거 기능

처리되지 않은 예외는 다음 섹션의 출력 텍스트와 같이 애플리케이션 이벤트 로그 페이지에도 기록됩니다. 그러나 Application Insights 스냅샷 디버거를 사용하도록 설정할 수도 있습니다. 이 방법은 애플리케이션에 코드를 추가할 필요가 없습니다.

애플리케이션 이벤트 로그(처리되지 않은 예외) 기능

다음 출력은 Azure Portal에 있는 진단 도구의 애플리케이션 이벤트 로그 페이지에서 가져옵니다. 처리되지 않은 애플리케이션 예외의 몇 가지 예제 텍스트가 표시됩니다.

Category: Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware
EventId: 1
SpanId: 311d8cb5d10b1a6e
TraceId: 041929768411c12f1c3f1ccbc91f6751
ParentId: 0000000000000000
RequestId: 8000006d-0001-bf00-b63f-84710c7967bb
RequestPath: /Unhandled

An unhandled exception has occurred while executing the request.

Exception:
System.DivideByZeroException: Attempted to divide by zero.
   at System.Decimal.DecCalc.VarDecDiv(DecCalc& d1, DecCalc& d2)
   at System.Decimal.op_Division(Decimal d1, Decimal d2)
   at contosotest.Pages.Pages Unhandled.ExecuteAsync()
     in C:\Users\contoso\source\repos\contosorepo\contosorepo\Pages\Unhandled.cshtml:line 12

여기서 애플리케이션 로그의 처리된 예외와는 메서드를 식별하는 스택과 예외가 throw되는 줄이 있다는 차이점이 있습니다. 또한 Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware 기능에 이 처리되지 않은 예외를 catch하는 코드가 포함되어 프로세스 종료를 방지한다고 안전하게 가정할 수 있습니다. 다음 스크린샷과 같이 실패 페이지의 예외 탭에 있는 Application Insights 에 예외가 표시됩니다.

이 보기에는 검색하는 예외뿐만 아니라 모든 예외가 표시됩니다. 애플리케이션에서 발생하는 모든 예외의 그래픽 표현은 시스템 상태에 대한 개요를 얻는 데 도움이 됩니다. Application Insights 대시보드는 애플리케이션 이벤트 로그에 비해 시각적으로 더 유용합니다.

자동 관리 CPU 모니터링 기능

과도한 CPU 사용 시나리오 중에 사전 CPU 모니터링 도구를 사용할 수 있습니다. 이 도구에 대한 자세한 내용은 CPU 문제가 발생하기 전에 완화를 참조하세요. 다음 이미지는 진단 도구의 자동 관리 CPU 모니터링 페이지를 보여줍니다.

80% 이상의 CPU 사용량을 즉각적인 조사가 필요한 중요한 상황으로 고려해야 합니다. 자동 관리 CPU 모니터링 페이지에서 다음 데이터 모니터링 범주에 따라 메모리 덤프를 캡처하려는 시나리오를 설정할 수 있습니다.

• CPU 임계값
• 임계값 초
• 모니터 빈도

CPU 임계값 은 대상 프로세스에서 사용하는 컴퓨터 CPU의 양을 식별합니다(이 경우 W3WP). 임계값 초는 CPU 임계값에서 CPU가 사용된 시간입니다. 예를 들어 총 30초 동안 CPU 사용량이 75%인 경우 메모리 덤프가 캡처됩니다. 사전 CPU 모니터링 페이지에 구성된 대로 프로세스는 15초마다 임계값 위반을 확인합니다.

자동 복구(메모리 제한) 기능

자동 복구(메모리 제한) 기능은 프로세스가 예상보다 많은 메모리를 사용하는 경우 메모리 덤프를 캡처하는 데 유용합니다. 다시 비트(32 또는 64)에 주의하세요. 32비트 프로세스 컨텍스트에서 메모리 압력이 발생하며 메모리 사용량이 예상되는 경우 비트를 64로 변경하는 것이 좋습니다. 일반적으로 비트도를 변경하는 경우 애플리케이션을 다시 컴파일해야 합니다.

비트 수를 변경해도 사용되는 메모리 양이 줄어들지 않습니다. 프로세스에서 총 메모리를 4GB 이상 사용할 수 있습니다. 그러나 메모리 사용량이 예상대로 사용되지 않는 경우 이 기능을 사용하여 메모리를 사용하는 항목을 확인할 수 있습니다. 그런 다음 메모리 소비를 제어하는 작업을 수행할 수 있습니다.

"확장된 Azure App Service 디버깅 기능 설명" 섹션에서 첫 번째 스크린샷의 진단 도구 타일에서 자동 복구에 대한 링크를 볼 수 있습니다. 해당 링크를 선택하여 기능으로 직접 이동하거나 타일을 선택하고 진단 도구 페이지에서 사용 가능한 모든 도구를 검토합니다. 자세한 내용은 Azure App Service 진단 개요의 "자동 복구" 섹션을 참조하세요.

자동 복구 기능은 다음 스크린샷에 표시됩니다.

메모리 제한 타일을 선택하면 해당 메모리 제한이 위반될 때 메모리 덤프 캡처를 트리거하는 메모리 값을 입력하는 옵션이 있습니다. 예를 들어 값으로 6291456 입력하면 6GB 메모리를 사용할 때 W3WP 프로세스의 메모리 덤프가 사용됩니다.

메모리 덤프 수집 기능은 현재 문제가 발생하거나 재현 가능한 경우 이 시나리오에서 유용합니다. 이 기능은 수동 요청 시 메모리 덤프를 신속하게 수집합니다. 자세한 내용은 "메모리 덤프 수집" 섹션을 참조하세요.

확장된 명령 설명

메모리 덤프 수집의 예술은 연구, 경험 및 완벽에 약간의 시간이 걸립니다. 배운 대로 다른 절차는 "확장된 프로세스 시나리오 설명" 섹션의 표에 나열된 것처럼 프로세스가 표시하는 증상을 기반으로 합니다. 반면, 다음 표에서는 Azure App Service의 메모리 덤프 캡처 명령을 Kudu 콘솔에서 수동으로 실행하는 procdump 명령과 비교합니다.

Azure App Service의 메모리 덤프 캡처 기능에 사용하는 명령은 덤프를 수동으로 캡처한 경우 사용할 procdump 명령과 다릅니다. 이전 섹션을 검토하는 경우 Azure App Service의 메모리 덤프 컬렉션 포털 기능이 구성을 노출한다는 것을 알 수 있습니다. 예를 들어 테이블의 과도한 메모리 사용 시나리오에서 플랫폼이 실행하는 명령에는 메모리 임계값이 포함되지 않습니다. 그러나 일반 procdump 명령 열에 표시된 명령은 메모리 임계값을 지정합니다.

DaaS(Diagnostics as a Service)라는 도구는 Azure App Service 디버깅 포털에 지정된 구성을 관리하고 모니터링합니다. 이 도구는 웹앱을 실행하는 VM(가상 머신)에서 웹 작업으로 실행됩니다. 이 도구의 이점은 웹 팜에서 특정 VM을 대상으로 지정할 수 있다는 것입니다. procdump를 직접 사용하여 메모리 덤프를 캡처하려고 하면 특정 인스턴스에서 해당 명령을 식별, 대상 지정, 액세스 및 실행하는 것이 어려울 수 있습니다. DaaS에 대한 자세한 내용은 DaaS – Azure 웹 사이트에 대한 서비스로서의 진단을 참조하세요.

과도한 CPU 사용 량은 플랫폼이 권장되는 procdump 패턴과 일치할 수 있도록 메모리 덤프 컬렉션을 관리하는 또 다른 이유입니다. 이전 표와 같이 procdump 명령은 CPU 사용량이 80%(-n 3)보다 크거나 같은 경우 30초 간격(#-ma-s #30초)의 전체 메모리 덤프 3개를 수집합니다.-c 80 마지막으로, 명령에 procdump -accepteula -ma -n 3 -s # -c 80 <PID>프로세스 ID(<PID>)를 제공합니다.

"자동 관리 CPU 모니터링" 섹션에서 포털 구성을 볼 수 있습니다. 간단히 하기 위해 이 섹션에서는 CPU 임계값(), 임계값 초-s(-c) 및 모니터 빈도의 처음 세 가지 구성 옵션만 표시했습니다. 다음 스크린샷은 작업 구성, 최대 작업 (-n) 및 최대 지속 시간이 사용 가능한 추가 기능임을 보여 줍니다.

메모리 덤프를 캡처하기 위한 다양한 방법을 연구한 후 다음 단계는 캡처를 연습하는 것입니다. IIS 디버깅 랩 및 Azure Functions와 함께 GitHub의 코드 예제를 사용하여 두 테이블에 나열된 각 시나리오를 시뮬레이션할 수 있습니다. Azure App Service 플랫폼에 코드를 배포한 후 이러한 도구를 사용하여 지정된 각 시나리오에서 메모리 덤프를 캡처할 수 있습니다. 시간이 지남에 따라 연습 후에 Azure App Service 디버깅 기능을 사용하여 메모리 덤프를 캡처하는 방법을 완벽하게 만들 수 있습니다. 다음 목록에는 메모리 덤프 컬렉션에 대해 계속 알아볼 때 고려해야 할 몇 가지 제안이 포함되어 있습니다.

• 메모리 덤프를 캡처하면 상당한 시스템 리소스가 소비되고 성능이 더욱 저하됩니다.

• 첫 번째 기회에 메모리 덤프를 캡처하는 것은 너무 많이 캡처하기 때문에 최적이 아닙니다. 이러한 첫 번째 기회 메모리 덤프는 관련이 없을 가능성이 큽니다.

• W3WP 메모리 덤프를 캡처하기 전에 Application Insights를 사용하지 않도록 설정하는 것이 좋습니다.

메모리 덤프를 수집한 후 다음 단계는 메모리 덤프를 분석하여 문제의 원인을 확인한 다음 해당 문제를 해결하는 것입니다.

다음 단계(메모리 덤프 분석)

메모리 덤프를 분석하는 방법은 이 문서의 범위를 벗어났습니다. 그러나 Defrag Tools 학습 시리즈 및 반드시 알아야 할 WinDbg 명령 목록과 같은 해당 주제에 대한 많은 리소스가 있습니다.

이전 스크린샷에서 작업 구성 옵션을 발견했을 수 있습니다. 이 옵션의 기본 설정은 CollectAndKill입니다. 이 설정은 메모리 덤프가 수집된 후 프로세스가 종료됨을 의미합니다. CollectKillAndAnalyze라는 설정은 수집된 메모리 덤프를 분석합니다. 이 시나리오에서 플랫폼 분석은 WinDbg에서 메모리 덤프를 열고 분석할 필요가 없도록 문제를 찾을 수 있습니다.

Azure App Service 플랫폼에서 성능 문제를 해결하고 진단하기 위한 다른 옵션이 있습니다. 이 문서에서는 메모리 덤프 수집에 중점을 두고 이러한 방법을 사용하여 진단에 접근하기 위한 몇 가지 권장 사항을 제시합니다. 이미 수집 프로시저를 연구하고, 경험하고, 완성했으며, 수집 프로시저가 잘 작동하는 경우 이러한 절차를 계속 사용해야 합니다.

도움을 요청하십시오.

질문이 있거나 도움이 필요한 경우 지원 요청을 생성하거나Azure 커뮤니티 지원에 문의하세요. Azure 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.