다음을 통해 공유


성능 문제 격리(C#, Visual Basic, F#)

이 문서에서는 프로파일링 도구를 사용하여 성능 문제를 조사하고 문제 영역을 격리하는 방법을 알아봅니다.

여기서는 단계별 지침을 제공하는 대신 프로파일링 도구를 효과적으로 사용하는 방법과 데이터를 해석하는 방법을 보여 줍니다. CPU 사용량 도구와 마찬가지로 .NET 카운터 도구도 성능 조사를 위한 좋은 시작점입니다. 흥미로운 데이터를 식별하면 다른 프로파일링 도구를 사용하여 더 자세히 조사할 수 있습니다. 도구를 비교하려면 어떤 도구를 선택해야 하나요?를 참조하세요.

예제 앱 정보

이 문서의 스크린샷은 시뮬레이션된 데이터베이스에 대해 쿼리를 실행하는 ASP.NET 앱을 기반으로 합니다. 예제는 진단 샘플을 기반으로 합니다.

조사 시작

  • 성능 데이터를 수집하는 동안 .NET 카운터 메트릭을 확인하여 조사를 시작합니다.
  • 다음으로 문제를 격리하는 데 도움이 되는 추가 인사이트를 얻으려면 CPU 사용량 도구, 계측 도구 등의 다른 프로파일링 도구 중 하나를 사용하여 추적을 수집하는 것이 좋습니다.

데이터 컬렉션에는 다음 단계가 필요합니다(이 문서에는 표시되지 않음).

  • 앱을 릴리스 빌드로 설정합니다.
  • 성능 프로파일러에서 .NET 카운터 도구를 선택합니다(Alt+F2). (이후 단계에는 계측 도구가 포함됩니다.)
  • 성능 프로파일러에서 앱을 시작합니다.

성능 카운터 확인

앱을 실행하는 동안 .NET 카운터 도구에서 카운터를 봅니다. 초기 조사에서 주목해야 할 몇 가지 주요 메트릭은 다음과 같습니다.

  • CPU Usage. CPU 사용량이 높거나 낮을 때 성능 문제가 발생하는지 확인하려면 이 카운터를 확인하세요. 이는 특정 유형의 성능 문제에 대한 단서가 될 수 있습니다. 예:
    • CPU 사용량이 높은 경우 CPU 사용량 도구를 사용하여 코드를 최적화할 수 있는 영역을 식별합니다. 이에 대한 자습서는 코드를 최적화하고 컴퓨팅 비용을 줄이기 위한 초보자 가이드를 참조하세요.
    • CPU 사용량이 낮은 경우 계측 도구를 사용하여 벽시계 시간을 기준으로 호출 횟수와 평균 함수 시간을 식별합니다. 이렇게 하면 경합 또는 스레드 풀 부족과 같은 문제를 식별하는 데 도움이 될 수 있습니다.
  • Allocation Rate. 요청을 제공하는 웹앱의 경우 속도가 상당히 안정적이어야 합니다.
  • GC Heap Size. 메모리 사용량이 지속적으로 증가하고 잠재적으로 누수가 발생하는지 확인하려면 이 카운터를 확인하세요. 높아 보이는 경우 메모리 사용 도구 중 하나를 사용할 수 있습니다.
  • Threadpool Thread Count. 요청을 처리하는 웹앱의 경우 이 카운터를 확인하여 스레드 수가 안정적으로 유지되는지 아니면 꾸준한 속도로 증가하는지 확인하세요.

다음은 CPU Usage가 낮은 반면 ThreadPool Thread Count가 상대적으로 높은 것을 보여주는 예입니다.

.NET 카운터 도구에 표시된 카운터의 스크린샷

CPU 사용량이 적은 스레드 수가 꾸준히 증가하면 스레드 풀 부족을 나타내는 지표일 수 있습니다. 스레드 풀은 새 스레드를 계속 회전시켜야 합니다. 스레드 풀 고갈은 풀에 새 작업 항목을 처리하는 데 사용할 수 있는 스레드가 없을 때 발생하며 종종 애플리케이션의 응답 속도가 느려집니다.

CPU 사용량이 적고 스레드 수가 상대적으로 많으며 스레드 풀이 부족할 수 있다는 이론을 바탕으로 계측 도구 사용으로 전환합니다.

호출 횟수 및 타이밍 데이터 조사

계측 도구의 추적을 살펴보고 스레드에 무슨 일이 일어나고 있는지 더 자세히 알아볼 수 있는지 살펴보겠습니다.

진단 데이터가 로드되면 먼저 Top Insights 및 핫 경로를 보여 주는 초기 .diagsession 보고서 페이지를 검사. 계측 추적에서 실행 부하 과다 경로는 앱에서 함수 시간이 가장 긴 코드 경로를 표시합니다. 이러한 섹션에서는 개선할 수 있는 성능 문제를 빠르게 식별하는 데 도움이 되는 팁을 제공할 수 있습니다.

수집된 추적에서 보고서의 세부 정보 열기 링크를 사용한 다음 플레임 그래프를 선택합니다.

계측 도구의 플레임 그래프의 스크린샷

플레임 그래프 시각화는 QueryCustomerDB 함수가 앱 실행 시간의 상당 부분을 담당한다는 것을 보여줍니다.

QueryCustomerDB 함수를 마우스 오른쪽 단추로 클릭하고 호출 트리에서 보기를 선택합니다.

계측 도구의 호출 트리의 스크린샷

호출 트리 보기에서 실행 부하 과다 경로(플레임)에 잠재적인 성능 문제를 가리키는 QueryCustomerDB 함수가 포함되어 있음을 알 수 있습니다.

다른 함수에 소요된 시간에 비해 QueryCustomerDB 함수의 SelfAvg Self 값은 매우 높습니다. TotalAvg Total과 달리 Self 값은 다른 함수에 소요된 시간을 제외하므로 성능 병목 상태를 찾기에 적합합니다.

Self 값이 높지 않고 상대적으로 낮다면 QueryCustomerDB 함수가 호출한 실제 쿼리를 살펴보는 것이 좋습니다.

QueryCustomerDB 함수를 두 번 클릭하여 함수의 소스 코드를 표시합니다.

public ActionResult<string> QueryCustomerDB()
{

    Task dbTask = QueryCustomerFromDbAsync("Dana");
    return "success:tasksleepwait";
}

약간의 조사를 통해 이 코드가 await를 사용하지 않고 비동기 API를 호출하고 있음을 발견했습니다. 이는 스레드 풀 고갈의 일반적인 원인이며 스레드를 차단할 수 있는 sync-over-async 코드 패턴입니다.

해결하려면 await를 사용합니다.

public async Task<ActionResult<string>> TaskAsyncWait()
{
    Customer c = await PretendQueryCustomerFromDbAsync("Dana");
    return "success:taskasyncwait";
}

데이터베이스 쿼리와 관련된 성능 문제가 발견되면 데이터베이스 도구를 사용하여 특정 호출이 더 느린지 조사할 수 있습니다. 이 데이터는 쿼리를 최적화할 수 있는 기회를 나타낼 수 있습니다. 데이터베이스 도구를 사용하여 성능 문제를 조사하는 방법을 보여주는 자습서는 코드를 최적화하고 컴퓨팅 비용을 줄이기 위한 초보자 가이드를 참조하세요. 데이터베이스 도구는 ADO.NET 또는 Entity Framework Core를 사용하여 .NET Core를 지원합니다.

Visual Studio에서 개별 스레드 동작에 대한 시각화를 얻으려면 디버깅하는 동안 병렬 스택 창을 사용할 수 있습니다. 이 창에는 대기하는 스레드, 스레드가 대기 중인 스레드 및 교착 상태에 대한 정보와 함께 개별 스레드가 표시됩니다.

스레드 풀 고갈에 대한 자세한 내용은 ThreadPool 고갈 감지를 참조하세요.

다음 단계

다음 문서 및 블로그 게시물은 Visual Studio 성능 도구를 효과적으로 사용하는 방법을 배우는 데 도움이 되는 자세한 정보를 제공합니다.