1장 - 성능 튜닝 소개

Defining Performance Tuning Concepts

 

튜닝이란?

Performance Tuning은 보유한 자원과 운영 환경을 활용해 시스템이 가능한 최고의 성능으로 동작하여 아래를 향상시키기 위해 시스템 설정을 조정하는 과정이다.

• 컴퓨터 자원의 활용도
• 데이터 throughput (처리량)
• 사용자 경험

이는 하드웨어/소프트웨어/시스템간의 다양한 상호작용 을 이해하고 있어야 한다.

튜닝 목표

명확한 목표를 설정하여 성과를 계량해야 함.

목표 설정시 시스템의 사용방식과 잠재적 트레이드오프(등가교환)을 고려해야 함.

• low latency (빠른 응답) VS high throughput (높은 완료된 작업수; 처리량)
• batch processing (report 같은) VS interactive users (실시간 상호작용)

real-time application이 예측 가능한 latency를 요구한다면 예측불가능한 지연을 최소화하거나 제거하도록 튜닝해야 함.

일반적으로 튜닝은 특정 유형의 워크로드에 맞출 설정 최적화를 목표로 하는데, 이 목표 외에 다른 프로세스가 이러한 튜닝으로 인해 성능저하가 올 수도 있다.

예를 들어, network buffers에 할당되는 메모리 양을 늘리면 네트워크로의 throughput이 상승할 수 있다. 하지만 시스템 전체 사용가능한 메모리 양이 줄어 다른 프로세스에 영향을 줄 수 있다. 사용가능한 메모리가 줄어들면 paging/swapping이 증가해 disk I/O에 영향을 줄 수 있다.

중요한 성능 지표 : throughput & latency

• 튜닝의 궁극적 목표는 : throughput을 올리고, latency를 최소화함.
• 하지만 이 두가지는 모두 올리는것은 어려운 경우가 대부분이다. 즉 성능 튜닝 결정은 흔히 트레이드오프가 요구되며, 이로 인해 throughput과 latency가 서로 상충되는 경우가 많다.
• throughput : 특정 시간동안 자원이 전송하거나 처리할 수 있는 데이터의 양
• latency : 자원이 데이터 전송/처리를 시작하기 위해 기다려야 하는 지연시간
• storage, memory, CPU, network device 등에서 두 값을 확인할 수 있다.

용량 산정

시스템 워크로드를 지원하는 데 필요한 자원을 추정하는 프로세스

하드웨어, 소프트웨어, 네트워크 연결성, 전력, 열 등까지 고려 범위가 된다.

효과적인 용량 산정은 원하는 워크로드를 처리할 수 있도록 적절히 설계된 architecture에 의존한다.

좋은 용량 산정 프로세스는 아래 개념에 집중한다.

• Scalability : 확장성
• Limitations : 일반적인 성능 지표와 시스템의 한계 지표
• Critical Resource : 핵심적인 부품. 예를들어 GPU 같은..

 

 

Discussing Performance Tuning Methodology

시스템 성능 향상을 위해 다양한 방법론과 전략을 적용할 수 있다.

변경하기 전에 개선사항을 조사하면서 시스템 현재 성능을 분석해야 한다.

시스템 분석을 시작하는 방법을 아는것이 이 과정의 중요한 단계이다.

USE (Utilization Saturation and Errors)

USE 방법은 높은 사용률이나 포화 상태로 인해 성능이 저하되는 하드웨어 리소스를 포함하는 복잡한 시스템에서 가장 효과적이다.

개요

• 성능 전문가 Brendan Gregg가 개발한 것임. 튜닝 전문가로부터 높은 평가를 받는 방법이다.
• 이 분석은 기준을 설정하는데 필수적이며, 결과적으로 성능 향상을 위한 시스템 변경을 시작할 수 있다.
• 주요 개념은 개별 리소스를 먼저 식별하고, 각 리소스의 오류/사용률/포화상태를 확인함
• 높은 사용률이나 포화상태로 인해 성능이 저하되는 하드웨어 리소스를 포함하는 복잡한 시스템에서 가장 효과적이다.
• 소프트웨어 리소스를 처리하는데는 효과적이지 않다. USE를 쓸때는 하드웨어 리소스에 중점을 두어야 한다.
• 하드웨어 리소스는 모든 IT 시스템 토폴로지의 시작점이다.

용어

• 자원(Resources) : 서버에 있는 기능적 하드웨어 (CPU, Memory, NIC, Disk, Controller 등)
• 사용률(Utilization) : 리소스가 작업처리에 사용된 평균 시간
• 포화 상태(Saturation) : 리소스에 처리할 수 없는 추가 작업이 있는 정도. 이 작업은 일반적으로 대기열에 대기되나, 리소스 유형에 따라 거부되는 경우도 있다. 다시 말하면 자원에 작업이 대기열로 쌓여서 즉시 처리가 안되는 상태이다. 사용률은 실제로 자원이 일하고 있는 비율인데, saturation은 그 자원 위에 더 이상 수용할 여지가 없는지를 보여준다. (자원이 처리해야 할 작업이 대기하고 있는 정도, 큐/길이 등)
• 오류(Errors) : 오류 이벤트 수

지표 및 리소스 유형

CPU

• 대기열과 우선순위를 처리하는 처리 리소스이다.
• 성능 측정 지표 : 사용률(percentage of use), 부하 평균(load average), 대기열 평균(queue average)

Memory

• 용량 리소스
• 성능 측정 지표 : 사용 가능한 용량(free capacity), 처리량(throughput), 오류(errors)

스토리지 리소스

• 용량 및 I/O 리소스이다.
• 성능 측정 지표 : 사용 가능한 공간(free space), IOPS(초당 I/O 작업수; I/O Operations per Second), I/O 대기시간(wait time), 처리량(throughput)

네트워크 리소스

• I/O 리소스
• 성능 측정 지표 : 처리량(throughput), 왕복시간(round-trip-time), 대기시간(latency), 패킷손실(Packet loss), 오류(Errors), 충돌(Collisions)

USE Workflow

1. 가장 먼저 자원을 식별하고, 에러가 있는지 확인한다. error는 0이 아니라면 조사할 가치가 있다. 특히 성능 저하가 진행되는 동안 증가한다면 꼭 봐야 한다.
2. 그다음 현재 분석 상황이 성능 쪽인지 트러블슈팅쪽인지 확인한다.
3. 성능쪽이든 트러블슈팅쪽이든, 높은 인터럽트/에러발생 건의 원인은 성능이 근본원인일 수 있다. 따라서 saturation과 utilization에 대한 분석을 시작하기 전에 항상 높은 인터럽트/에러발생을 먼저 탐지하고 수정해야 한다. 한마디로, 성능분석하기 전에 보이는 에러나 특이사항을 먼저 해결해야 한다.
4. 높은 사용량이 있는지?
   Full utilization(100%)은 보통 병목(bottleneck)의 신호이다; 병목을 확인하려면 saturation과 그 영향을 점검하라. 장기간(수초 또는 수분 이상) 높은 utilization(70% 이상)은 순간적으로 100%에 도달하는 짧은 버스트를 숨길 수 있다. 일부 시스템 자원(예: 하드 디스크)은 높은 우선순위 작업이라도 동작 중에는 중단될 수 없다. utilization이 70%를 넘으면 전체 시스템 성능에 영향을 주는 큐잉 지연이 더 자주, 그리고 눈에 띄게 발생할 수 있다. 반면 CPU 같은 자원은 거의 언제든지 인터럽트되거나(또는 "preempted"될 수) 서로 다른 우선순위를 처리해 workload를 관리할 수 있다.
5. Saturation이 있는지? saturation은 어떤 수준이든 (0이 아니면) 문제가 될 수 있다.
6. 모든 자원이 다 체크되었는지?

usage는 자원이 실제로 일을 하고 있는 비율을 말한다. 예를들어 CPU가 100초중 70초 동안 작업을 처리했다면 활용율은 70%이다.

사용량이 100%인것이 문제일 수 있지만, 작업 특성상 일정 시간동안 계속 꽉 차 있어야 정상인 경우도 있다. 그래서 포화도(saturation)과 영향(처리지연, 오류증가) 등을 함께 확인해야 한다.

지속적으로 70% 이상인 경우, 주의해야 한다. 이 수준 이상이라면 짧은 순간의 100% 치솟음이 숨겨질 수 있어서 성능 저하 원인 갈피를 잡기 어려울 수 있다.

특히 하드디스크 같은 경우 작업 중 중단할 수 없기때문에 70%를 넣으면 큐가 쌓이고 대기시간이 늘어나 전체 성능에 눈에 띄는 영향을 줄 가능성이 크다. 디스크의 I/O 작업은 완료될 때까지 멈출 수 없다. 대기 큐가 길어지면 즉시 성능저하로 이어진다.

CPU는 스케줄러가 사용자를 교체해 가며 작업을 분할처리(선점)할 수 있다. 우선순위를 달리주면 중요한 작업을 먼저 처리하도록 조정이 가능하다.

기타 : AI확인, SAR에서 포화도 확인 (맞는지 검증 필요)

• CPU 포화 의심: sar -q 로 runq-sz / ldavg 확인 → iostat/ps 확인.
• 디스크 포화 의심: iostat -x 로 avgqu-sz / await / %util 확인 → I/O 패턴 분석.
• 메모리 포화 의심: sar -r, vmstat, 스왑 지표 확인.
• 네트워크 포화 의심: sar -n DEV 로 throughput/errs 확인.
• 보조: sar -w 로 cswch/s·proc/s 확인해 스케줄링·오버헤드 요인 점검.

변경 적용하기

1. 작업 전에, 테스트 워크로드를 실행하고 나오는 메트릭 값들을 수집한다. 이후 변경작업 후에 다시 측정하여 비교한다.
2. 변경을 진행할 때는 일반적으로 한번에 하나씩 항목을 변경하고 그 결과를 측정한다. 관련없다고 하여 여러가지를 동시에 하면 변경의 효과를 판단하기 어렵다. 즉 여러번 작업을 해야 할 수밖에 없다.
3. 변경 수행한 후, 동일한 테스트 워크로드를 다시 수행한다. 실제로 메트릭의 변화가 있는지 본다.
4. 또 다시 변경을 원복하고 최초 메트릭과 같이 나오는지 확인하면 변경된 효과에 대해 한층 더 확신을 가질 수 있다.
5. 최종적으로 변경을 적용하고 문서화한다.