Redjen TIL
Redjen TIL

Contents

성능 모니터링 및 테스트

   2724 words   6 minutes 

성능 모니터링 및 테스트

서버 자원 사용률 점검 항목

  • CPU
    • CPU 자원 부족?
    • CPU 사용 유형 중 시스템 이나 IO wait 사용률이 높은지?
    • 프로세스 별 CPU 사용률 분표가 균등한지?
  • 메모리
    • 메모리 부족?
    • 서버 전체 또는 개별 프로세스 단위로 메모리 사용량 지속 증가?
  • 디스크
    • 디스크 서비스 시간은 대기시간 포함해 얼마인지?
    • 파일 시스템 중 공간 부족한 곳 있는지?
  • 네트워크
    • 네트워크 데이터 전송량 얼마인지?
    • 재전송량 많은지?
    • RTT 높은지?

리눅스 기본 명령어

man, cd, ls, cat, grep, pipe 등..

리눅스 시스템 모니터링 도구들

  • top : 프로세스 표시
  • ps : 현재 프로세스 스냅샷 리포트
  • vmstat : 가상 메모리 통계
  • sar : 시스템 활동 정보 수집 및 리포트
  • iostat : CPU 통계, 장치나 파티션의 io 통계
  • netstat : 네트워크 연결, 라우팅 테이블, 인터페이스 통계, 마스쿼레이드 연결, 멀티캐스트 정보
  • mpstat : 프로세서 관련 통계
  • pidstat : 리눅스 task 관련 통계

CPU

다음 작업들에 사용된 시간의 백분율 확인

  • user-level application thread
  • kernel thread
  • interrupt 처리

Load average - 물리적 CPU vs 논리적 CPU 논리적 CPU (운영체제가 인식하는 CPU) = 프로세스 * 코어 * 하드웨어 스레드 CPU는 특정 시점에 단 하나의 작업만 수행할 수 있음 Run queue : 실행 준비 완료 되었지만 대기 중인 프로세스들의 큐

Kernel-Time

  • kernel-level code를 실행하는데 소비한 시간
  • system call 처리
  • interrupt 처리 User-Time : user-level application 코드를 실행하는데 소비한 시간 Elapsed Time : 프로세스가 시작해서 종료할 때까지의 경과 시간 CPU Time : 프로세스가 실제로 논리 CPU를 사용한 시간

모니터링 도구

  1. uptime
    1. 시스템 실행 중인 시간 확인
    2. load average : 특정 시간 단위의 load 평균 값
    3. 15분 평균보다 1분, 5분 평균 값이 크다면 부하가 증가 중임
    4. load average가 크면 문제?
      1. 다른 지표와 같이 봐야 함
      2. CPU 코어가 몇 개인지? 일부 자원이 대기 상태에 있지는 않은지?
  2. vmstat
    1. 가상 메모리 통계 정보
    2. r : 실행 중 또는 run queue 에 대기 중인 task 수
    3. b : uninterruptible sleep task 수
    4. us : user time (%)
    5. sy : kernel time (%)
    6. id : idle time (%)
  3. ps
    1. 프로세스 상태 확인
    2. USER : 프로세스 소유자
    3. PID : 정수 형태의 프로세스 고유 식별자
    4. %CPU : CPU 사용률
    5. TIME : 해당 프로세스 생성 이후부터 소비한 전체 CPU 시간 (user + system)
    6. COMMAND : 명령어
    7. ELAPSED : 프로세스가 시작된 후 현재까지 시간
  4. top
    1. USER : 프로세스 소유자
    2. PID : 프로세스 고유 식별자
    3. 기본적으로 CPU 사용률을 기준으로 정렬되어 있음
  5. pstack, jstack (java)
    1. 쓰레드 덤프를 생성하여 stack trace 확인 가능
    2. 전체 쓰레드 개수를 확인 가능.
    3. 쓰레드가 획득한 락이나 상태도 확인 가능
    4. Thread Dump Analyzer 등 활용하면 더 쉽게 파악 가능
    5. 쓰레드 덤프 확인할 때에는 2회 이상 생성해야 더 정확한 결과 획득 가능

Memory

Virtual Memory

  • 각 프로세스 별로 큰 선형 메모리 공간을 제공
  • 물리 메모리 위치는 운영체제에 의해 관리
  • 물리 메모리보다 큰 가상 메모리 공간 제공 가능
  • Demand Paging -> 일종의 lazy loading
  • 특정 Page를 다른 프로세스들 간에 매핑 (shared memory)

더 이상 할당할 메모리가 없다면? disk에서 swap (page in / out) - 비용이 비싸다

Page Fault : 유효하지 않는 virtual address 접근하려 할 때 발생

  • Major fault : 물리 메모리에 없어 디스크로부터 읽어온 경우
  • Minor fault : 물리 메모리에는 있지만 다른 프로세스의 개입. 디스크 개입 없는 경우

Buffer Cache : 데이터 버퍼로 block device driver에 의해 사용 디스크 장치의 고정된 크기의 block을 캐싱

Page Cache : 디스크 상에 저장된 데이터의 접근 속도 향상을 위한 캐시

  • 수정 가능한 크기의 페이지를 캐싱
  • 파일 / 디렉토리 IO 성능 향상
  • 가능한 많은 메모리 영역을 사용
  • 어플리케이션에서 사용할 메모리가 부족해지면 kswapd daemon에 의해 반납

Virtual Memory Size

  • 프로세스가 접근할 수 있는 가상 메모리 크기
  • 공유 라이브러리의 영역 미포함
  • Demand Paging : 메모리 할당 시점이 아닌 페이지 접근이 이뤄질 때 실제 물리 메모리 할당

Resident Set Size

  • 메인 메모리에 할당된 메모리 크기
  • 공유 라이브러리의 영역 포함
  • SWAP 미포함

모니터링 도구

vmstat : 가상 메모리 통계 정보

  • free : 사용 가능한 메모리 양
  • buff : 버퍼 캐시에 있는 메모리
  • cache : 페이지 캐시에 있는 메모리
  • si : page in 된 메모리
  • so : page out 된 메모리
  • 리눅스는 가능한 많은 공간을 페이지 캐시로 할당하려 함

ps : 프로세스 상태 확인

  • %MEM : 주 메모리 사용량 (RSS)의 전체 시스템에 대한 비율

top : 리눅스 프로세스 목록 확인

  • VIRT : 가상 메모리 영역 크기
  • RES : 주 메모리에서 사용하는 영역 크기 (공유 메모리 영역 포함)
  • %MEM : 주 메모리 사용량의 전체 시스템에 대한 비율
  • Shift + M : 메모리 사용량으로 정렬
  • Shift + P : CPU 사용량으로 정렬

sar

  • pgpgin/s : 초당 page in 된 용량 (KB)
  • pgpgout/s : 초당 page out 된 용량 (KB)
  • fault/s : 초당 major + minor page fault 횟수
  • majfit/s : 초당 major page fault 횟수
  • pgscank : kswapd daemon에 의해 스캔 된 페이지 수

Java Garbage Collector

  • Eden : 새로 생성한 대부분의 객체가 위치하는 곳
  • Survivor : Eden 영역 gc 후 살아남은 객체가 이동하는 곳
  • Old : Survivor 영역을 n회 이상 이동한 객체가 이동하는 곳

jstat : Java Virtual Machine Statistics Monitoring Tool

  • 힙 영역 통계 (크기, 비율 등) 확인 가능
  • 클래스 로더 통계 확인 가능
  • gc 소요된 시간 / gc 횟수 = 대략적인 gc 평균 시간

gclog

  • JVM 옵션 사용하여 로그를 남길 수 있음
  • Gc 발생한 시간, 이유를 알 수 있음
  • 나이 대별 객체의 정보 확인 가능
  • gc 전후의 메모리 사용량도 확인 가능

Heap Dump / MAT

  • jdk 설치하면 같이 설치되는 jmap으로 확인 가능
  • 힙 덤프는 부하가 크기 때문에 운영 환경에서는 신중히 고려해야
  • 텍스트가 아닌 바이너리 데이터 -> MAT등 전용 도구 필요

Disk

비교적 흔하게 접할 수 있는 문제. 자주 발생하지 않을 것 같지만 잊을만 하면 발생 df -h : 마운트 포인트별로 사용 중인 용량의 비율 확인 가능 du -h : 하위 폴더 별 사용 중인 디스크 공간의 크기를 확인 가능

다른 모니터링 도구들

Pinpoint

  • APM
  • Servermap 제공
  • Realtime active thread chart
  • Request / Response Scatter chart
  • call stack
  • inspector : CPU 사용량, Memory / GC, TPS, JVM Arguments

VisualVM

  • Java App 모니터링 및 트러블슈팅 도구
  • local / remote Java process 모니터링 가능
  • jvmstat, JMX, Serviceability Agent
  • CPU / 메모리 사용량, GC 추이
  • 프로파일링
  • 쓰레드 / 힙 덤프 생성 및 확인

성능 테스트

목적

  • 신규 버전 출시 준비 상태 점검
  • 인프라 / 시스템 아키텍쳐 성능 검증
  • 소프트웨어 성능 평가
  • 성능 튜닝을 통한 효율 향상

주요 용어 정리

Transaction : 시간 당 처리율을 나타내는 지표 기준

  • 요청 기준 : 서버 입장에서 요청 하나하나 == 하나의 Transaction
  • 사용자 기준 : 사용자가 한 화면을 보기 위해 필요한 모든 요청 묶음을 하나의 트랜잭션
  • 사용자 기준 트랜잭션으로 측정 / 목표를 세워야 실 환경하고 유사
  • 하지만 테스트가 너무 힘들어짐

동시 사용자 : 시스템과 접속을 유지하고 있는 사용자 수

  • 요청 사용자 : 서버에 요청 후 응답 대기 상태 사용자
  • 비요청 사용자 : 서버에 요청을 보내고 있지 않은 사용자 (화면의 내용을 읽는 등)

처리량 : 시스템이 일정 시간 내에 처리 가능한 트랜잭션 수 평가 단위 : TPS / PPS

응답시간 : 요청한 후 응답을 받을 때 까지 소요된 시간

  • 클라이언트 처리 부분 : 렌더링, FE 로직
  • 클라이언트 외 부분
    • 네트워크 처리 시간 : DNS, 업로드, 다운로ㅡ
      • 서버 응답시간:
        • 서버 처리 시간 : 웹 + 어플리케이션 + 데이터 베이스
        • 연계 응답 식나 : 연계 서버 + 타 서버

성능 테스트 절차

  1. 테스트 환경 파악
    1. 테스트 / 운영 환경에 대한 파악 (hw, sw, 네트워크 환경 등..)
    2. 테스트 도구
  2. 요구되는 성능 기준 파악
    1. 응답 시간
    2. 시스템 사용률 (cpu, 메모리)
  3. 테스트 계획 수립
    1. 주요 시나리오 정리
    2. 테스트 데이터 정의
    3. 측정 결과 데이터 정의
  4. 테스트 환경 설정
    1. 테스트 환경 / 도구 준비 (nGrinder, JMeter …)
    2. 리소스 (서버) 모니터링 환경 준비
  5. 테스트 구현
    1. 테스트 시나리오에 따른 구현 (nGrinder 스크립트 작성)
  6. 테스트
    1. 테스트 실행 및 모니터링
  7. 분석 및 리포트
    1. 결과 / 지표 데이터 분석
    2. 필요하다면 반복 테스트

ab

wrk

nGrinder

  • Grinder에 기반한 성능 테스트 도구
  • Jython script을 이용한 테스트 시나리오 작성
  • 웹 기반 도구 제공
    • 테스트 시나리오 관리
    • 테스트 실행
    • 모니터링
    • 결과 확인 및 리포트 제공
Updated on 2022-12-21
Back | Home