8.1 응답과 처리량

  • 인프라 관점에서 사용자로부터 확인해야 할 사항들
    • 응답 속도 (Response)
      • 서비스를 이용하는 한 명의 사용자 관점 지표
    • 처리량 (Throughput)
      • 서비스 제공자 관점의 지표
    • 혹은 둘 다
  • 응답 시간이 느릴 경우
    • 로그나 실제 장비 시험 등을 통해서 구체적으로 어떤 계층에서 응답 지연이 발생하고 있는지 파악해야 한다.
    • 3계층 구조에서 각 서버의 응답 시간에 대해서는 로그 등을 보면 어느 정도 문제 파악이 가능하다.
    • 응답 시간에는 물리적 제약이 있기 때문에 한계가 보일 경우 처리량 개선이 필요하다.
  • 처리량 문제
    • 대량의 데이터를 교환하고 싶은데 영역이 부족한 경우 처리량 문제가 생긴다.
    • CPU나 메모리 주변은 대역이 넓어서 처리량도 높다
    • 디스크나 네트워크 통신 대역은 처리량이 낮아서 병목 현상이 발생하기 쉽다.

8.2 병목 현상이란?

  • 병의 목처럼 처리량의 한계가 발생하는 현상이다.
    • AP 서버에서 CPU 사용률이 높아져서 처리량이 한계에 다다르면 병목 지점이 된다.
  • 해결 방법
    • 위치를 정확히 파악하는 것이 중요하다.
    • 튜닝을 통해 병목 위치를 작은 단위로 세분화하여 병목 영역을 더 집중적으로 파헤친다.
    • 시스템 이용자 수를 제한하는 것도 방벙비다. (유량 제어)

8.3 3계층형 시스템 그림을 통해 본 병목 현상

  • CPU 병목
    • CPU 사용률은 처리 효율성을 나타내는 것으로 병목 현상 유무와는 관계가 없다.
    • CPU 사용률이 급증해서 문제가 있는지 없는지를 판단하려면 사용자 관점의 응답 속도나 시스템 전체 처리량을 확인해야한다.
    • CPU에 기인한 성능 문제의 원인
      • CPU를 이용하는 처리가 많아서 대기 행렬이 발생한 경우 (스케일 아웃 필요)
      • CPU 응답이 느린 경우 (스케일 업 필요)
    • CPU 사용률이 오르지 않는 경우
      • 디스크 I/O나 네트워크 I/O에서 막히는 경우에 CPU 사용률이 100%에 도달하지 못하는 경우가 있다.
      • I/O 처리를 다중화하거나 비동기화 함으로써 상태를 개선할 수 있다.
  • 메모리 병목
    • 메모리 영역의 병목 현상은 크게 두가지로 나눌 수 있다.
      • 영역 부족
      • 동일 영역의 경합
  • 디스크 I/O 병목
    • I/O 병목 현상은 하드디스크 등의 저장 장치에 대한 I/O 병목이다.
    • I/O가 병목 지점이 될 때는 CPU 수를 늘리거나 클럭 주파수를 높여도 소용이 없다.
      • I/O 효율을 높이든가 I/O를 줄이는 방법을 고민해야 한다.
  • 네트워크 I/O 병목
    • 네트워크를 경우한 I/O는 CPU 버스나 메모리 간 I/O보다도 응답 시간 오버헤드가 크다.
    • 처리량을 개선하는 접근법이나 네트워크 I/O 자체가 발생하지 않도록 하는 방법이 효과가 있다.
  • 애플리케이션 병목
    • 스케일 업이나 스케일 아웃이 필요한 경우
    • 알고리즘의 문제로 처리량이 낮거나 응답 속도가 낮은 경우
    • 데이터 베이스를 이용한 시스템에서는 특정 데이터에 의존하는 경우 병목 지점이 발생한다.
    • 외부 질의시 병목이 발생하는 경우도 있다.

+ Recent posts