공개SW 개발자센터


- 공개SW개발자센터는 공개SW 리더로 성장할 개발자와 커뮤니티를 지원합니다 -

공개SW역량프라자에서는 오픈프론티어로 활동중인 개발자들이 진행하는 프로젝트를 소개합니다.


perf란 Linux 명령어 중의 하나이며 Linux Kernel 프로젝트에서 관리되는 성능측정 도구(profiler tool)이다. 리눅스 내의 특정 프로그램이나 시스템 전체를 분석할 수 있다. 예를 들면 내가 만든 프로그램의 어느 함수가 CPU를 많이 사용하는지, 어느 코드 부분이 메모리 할당을 얼마나 하는지 등을 어셈블리 및 소스 코드 레벨로 파악할 수 있고 시스템 전체적으로도 page-fault, context-switch, cache-misses 등이 몇 번이나 일어났는지를 파악할 수 있다. 또한, 특정 커널 함수가 불리는지, 불린다면 얼마나 불리는지도 파악 할 수 있다.


perf는 perf_events로도 불린다. 왜냐하면, perf는 결국 event들을 수집하고 통계를 내주는 프로그램이기 때문이다. perf에 있어서 수집할 event란 CPU-cycles, cache-references, page-fault, system call, irq 등을 예로 들 수 있다. 다시 말하면 event가 발생한다는 것은, 예를 들면 cache-miss가 몇 번 발생했는가, 대상 프로그램이 실행되는 동안 몇 개의 instruction이 실행되었는가 등을 의미한다. perf는 그러한 여러 가지 종류의 event들을 수집하고 통계를 내준다.


이러한 event들은 4가지로 구분할 수 있다. 하드웨어적으로 PMU(Performance Monitoring Unit)로 수집 가능한 하드웨어 이벤트, 커널에서 제공하는 소프트웨어 이벤트, tracepoint 이벤트, 사용자가 정의하는 probepoint 이벤트가 있다. event에 대해서는 본문에서 자세히 알아보도록 하겠다.

프로젝트명perf (linux-perf)
개요Linux 기반 성능측정분석 도구
특징

- Linux kernel
- performance events subsystem
- Linux kernel 소스 내부 C프로그램, Command line tool
- 특정 프로그램 또는 시스템 전체 성능 분석 
- 각종 CPU 에서 지원하는 PMU 기능 제어

- 각종 이벤트(cpu-cycles, cache-misses등) 정보 수집

- 수집된 성능분석 정보 기반 통계 view 제공 (TUI, GUI등)

- Assembly 또는 source code 단위 overhead분석

- Kernel API( 무엇이 얼마나 불려지는지 등) Tracing 기능

목표perf 프로젝트에 기여
기대효과

- 복잡, 다양해지는 각 커널 버전에 맞춰 성능분석

- 커널 또는 프로그램 속도 저하없이 성능 분석

- 각종 최신 CPU(x86, ARM, SPARC, etc.) 에도 이용 가능

- 커널, 시스템 과의 호환성 문제 및 성능저하 원인분석 용이

리퍼지토리

http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/ Branch : perf/core

Source directroy : tools/perf, kernel/events 등



[목차]

  1. Linux Kernel – perf 프로젝트 Time Line
  2. Perf 사용 사례
  3. Events
    1. 3.1. Events란?

      a. Profiling 목적 

       - Hardware Event

       - Software Event

      b. Tracing 목적

       - Tracepoint Event

       - Probepoint Event

     3.2. Event Sampling 과정

     3.3. System Layer 기반에서 본 Event

 4. Perf 기능소개

    1. 4.1. 이벤트 발생횟수 세기(Counting)

      a. 이벤트 수식어옵션(Modifiers)      

  1.      4.2. 이벤트 발생횟수 세기(Counting)
  2.      4.3. 이벤트 발생과정 추적하기(Tracing)
  3.       a. 정적 추적(Static Tracing)
  4.       b. 동적 추적(Dynamic Tracing)


1. Linux Kernel – perf 프로젝트 Time Line

Linux Kernel은 수많은 sub project들로 나뉘어서 관리된다. 커널 소스의 MAINTAINERS 파일을 열어보면 확인 가능한 것처럼 perf 프로젝트는 Performance Events Subsystem이라는 이름으로 되어있으며 공식적으로 https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 저장소에서 관리가 되고, perf/core 브랜치가 개발의 주가 되는 브랜치라고 볼 수 있다. 총 C 소스 라인은 10만 라인 정도 되고, 모든 소스를 합하면 약 13만 라인가량 된다.

아래 그림은 perf프로젝트가 처음 만들어질 때부터 간략하게 역사 그래프를 만들어본 것이다. 본격적으로 perf 라는 이름으로 시작된 것은 2009년이고 약 7년 이상 개발되어오고 있다. 기간이 오래되긴 했으나 상당히 활발하게 개발이 진행되고 있으며 1주에 약 20~50개 정도의 새로운 PATCH가 LKML을 통해서 제안되고 적용되고 있다. 여러 가지 빌드 이슈나 기능문제, 사용법 등은 다음 메일링 리스트 linux-perf-users@vger.kernel.org를 활용하면 도움받을 수 있다.


hy_1.png

[그림 1] perf 프로젝트의 역사


2. Perf 사용 사례

perf는 여러 가지 profiling/tracing 목적으로 이용할 수 있다. 다음 사례는 git이라는 프로그램이 2009년에 겪은 성능 이슈를 perf로 분석한 사례이다.

http://osdir.com/ml/git/2009-08/msg00147.html 링크로 확인할 수 있듯이, 2009년 8월경에 git 프로그램 내부에서 Mozila SHA1 encryption 관련 성능문제가 발생했었고 perf를 통해서 문제 상황 분석 및 확인을 할 수 있었다.


ex perf_2.png

[그림 2]perf 사용 사례


3. Events


  1. 3.1. Event 란?
  2. Kernel/App이 실행됨에 따라 하드웨어/소프트웨어적으로 발생하는 모든 action을 Event라고 통칭한다. perf에서 가장 중요한 것이 Event이다. Event에 대한 전반적인 이해가 동반되지 않으면 perf를 정확하게 이용할 수 없으니, Event에 대해서 알아보자.

    위에서 설명했듯이 event들은 4 종류로 구분할 수 있다. 하드웨어적으로 PMU(Performance Monitoring Unit) 또는 PMC(Performance Monitoring Counters)로 수집 가능한 이벤트 외에도 커널에서 제공하는 소프트웨어, tracepoint (ftrace 활용), 사용자에 의해서 정의될 수 있는 Event probepoint가 있다. 


    kinds_3.png

    [그림 3]Event의 종류와 예시


 a. Profiling 목적
perf에서 profiling이란 결국 sampling을 통해서 각각의 Event 정보(언제/어디서/얼마나 등)를 수집하고 그 데이터를 분석, 통계 내는 기능을 의미한다. 그러한 목적에 쓰일 수 있는 Event는 다음과 같이 2가지 종류로 구분된다. 예를 들면 내가 만든 프로그램의 어떤 함수가 cpu-cycles 기준으로 overhead가 가장 높은지 확인하고 성능분석을 할 수 있다.
Hardware Event
아래와 같이 perf list 명령에 인자를 주면 하드웨어 이벤트들을 확인할 수 있다. 하지만 모든 환경에서 다음과 같은 결과가 출력되진 않는다. CPU의 종류가 어떤 것이냐에 따라 지원되는 HW 이벤트는 달라질 수 있다.

hw event_4.png
[그림 4]Hardware Event

- Software Event

sw event_5.png
[그림 5]Software Event

 b. Tracing 목적
perf에서 tracing은 각 tracepoint가 될 수 있는 Event들의 정보를 수집하여 특정 Event들의 발자취, 즉 Event 발생과정을 추적할 수 있다. 예를 들면 perf의 call-graph view를 통해서 Event가 발생하기까지 누가 누구를 호출했는지 모든 과정을 보면서 실행과정은 어떠한지, 문제 상황이 있는지 등을 사용자가 추적할 수 있다. 이런 목적을 위해서 쓰이는 Event는 2가지 종류로 구분된다.
- Tracepoint Event
말 그대로 추적 가능한 이벤트이다. block이라고 하면 Block Device 레벨에서 벌어지는 I/O 등을 각각 이벤트라 하고 그와 관련된 모든 과정(호출과정, 언제, 어떻게, 얼마나 등)을 추적할 수 있다.

Tracepoint Event_6.png
[그림 6] Tracepoint Event

-  Probepoint Event
Probepoint는 사용자 정의 Event로 특정 함수명을 dynamic tracepoint로 정의 내릴 수 있다. 다만 커널 debug info를 가지고 있는 상태여야 한다. 만약 debug 정보가 없다면 커널을 빌드할 때 설정에서 debug info를 포함하여 재빌드한 후 커널을 변경해서 부팅하여 perf probe를 정상 이용할 수 있다. 아래 예는 tcp_sendmsg라는 커널 함수를 사용자 정의 Event로 선언하고 그것을 확인하는 과정이다. 다음과 같이 등록하여 이 함수의 argument 정보나 변수정보, 리턴 값은 무엇인지, 소스 몇 라인에서 특정 local 변수가 어떤 값을 가졌는지 등을 전부 동적 추적이 가능하다.

Probepoint Event_7.png
[그림 7]Probepoint Event


  1. 3.2. Event Sampling 과정
  2. 우선 perf_event_open 시스템 콜을 통해서 이벤트 샘플링이 가능하다. 이벤트 샘플링이라 하면 결국 해당 이벤트에 대한 정보(언제/어떻게/얼마나)를 수집한다는 뜻이다. 우선 perf_event_open 특정 이벤트 정보와 함께 시스템 콜을 하면 file descriptor를 리턴 받게 된다. 성능정보를 측정할 수 있는 file descriptor를 통해서 각각의 event들과 연결할 수 있게 되는데 동시에 여러 이벤트들을 수집 가능하게 Grouping도 가능하다. 그러면 각 event들을 enable 하거나 disable 할 수 있다. 이는 ioctl() 나 prctl() 시스템 콜을 통해서 컨트롤이 가능하다. 이 과정을 아래 그림으로도 살펴볼 수 있다.

    Sampling_8.png

    [그림 8] Event Sampling 과정 1


    위의 과정이 끝나면 우선 특정 이벤트에 대해서 정보를 수집(sampling)하거나 단순히 이벤트 발생횟수를 세는 것(counting)이 가능해 진 것이다. sampling을 한다고 하면 우선 mmap() 시스템 콜을 통해서 특정 메모리 영역(버퍼)에 정보를 받을 준비를 한 후에 특정 이벤트들이 발생할 때마다, 혹은 지정된 특정주기(ex. Page fault 10 번당 한번씩)마다 그와 관련된 정보들을 측정 정보를 버퍼에 쓴다. 버퍼에 쓰는 과정은 hw/sw 인터럽트(ex. PMU활용)가 발생할 때마다 쓰게 된다. 그리고 perf command가 mmap()를 통해서 성능정보 수집하기 때문에 kernel에서 user의 copying 없이 데이터 수집이 가능하다. 실제 수집준비가 끝난 뒤 수집하는 과정은 다음 그림으로도 확인할 수 있다.


    sp_9.png

    [그림 9]Event Samping 과정 2


    3.3. System Layer 기반에서 본 Event

    아래 그림은 Linux kernel의 주요 5가지 subsystem 기준으로 system layer를 나눠본 것이다.
    아래와 같이 프로세스 관리(process management), 메모리 관리(memory management), 디바이스 드라이버(device driver), 파일 시스템(file system), 네트워킹(Networking) 5가지로 나누어보았을 때 각각에 영역에 대한 이벤트는 다음 그림으로 살펴볼 수 있다.

    layer_10.png
    [그림 10] Linux Kernel의 주요 5가지 subsystem 기준으로 나눈 system layer



4. Perf 기능소개


  1. 4.1. 이벤트 발생횟수 세기(Counting)
  2. 특정 이벤트들의 발생 횟수가 몇 개인지 측정한다. 구체적으로 어떻게 카운팅을 할 수 있는지 예를 들어보겠다. pwd라는 명령이 있다. 간단하게 perf를 통해서 pwd라는 프로그램이 대표적인 몇 개의 이벤트를 몇 번이나 발생시키는지를 알아보자. 'perf stat pwd'라고 명령어를 입력하면 pwd라는 프로그램에 대해서 기본적인 이벤트들을 몇 번이나 발생시키는지 아래 표와 같이 확인할 수 있다.


    basic_11.png 

    [그림 11]기본 이벤트 Counting


    하지만 위의 사용은 사용자가 원하는 특정 이벤트를 지정한 것은 아니다. 만약에 pwd라는 프로그램에 대해서 CPU 사이클이 얼마나 도는지에 대해서 알고 싶다면 다음과 같이 측정할 수 있다.


    spec_12.png 

    [그림 12] 특정 이벤트 Counting


    또한, 특정 이벤트들의 발생횟수를 살펴보고 싶다면 Modifier를 이용할 수 있다. (중복사용도 가능하다)

a. 이벤트 수식어옵션(Modifiers)


Modifiers_13.png
[그림 13] Modifiers

  1. 4.2. 성능분석하기(Profiling)
  2. Hardware 또는 Software 이벤트 정보수집(sampling)을 통해서 분석하고, 통계 view를 통해서 성능을 분석할 수 있다. Knapsack problem 알고리즘 풀이 프로그램이 있다. 본 프로그램의 성능에 대해서 perf를 통해서 분석해보자. 우선 본 프로그램을 테스트 스크립트와 함께 실행시키면서 이벤트 관련 정보를 수집한다. 6623856 출력 값은 이 프로그램의 실행 결과이다.

    Profiling_14.png
    [그림 14]Profiling 과정 1

    특정 이벤트를 지정하지 않으면 기본적으로 cycles 이벤트를 기준으로 측정하게 된다.
    측정이 끝나면 perf.data라는 파일이 생성되게 되는데 이 파일이 현재 폴더에 존재하면 그 파일을 기준으로 perf report 기능이 다음과 같이 동작할 수 있다.

    pf_15.png
    [그림 15]Profiling 과정 2

  1. 4.3. 이벤트 발생과정 추적하기(Tracing)
  2. Tracepoint/Probepoint 이벤트에 대한 다양한 정보(누가/언제/어디서/얼마나/어떻게 등)를 수집하여 이벤트의 근원지부터 결과까지의 전 과정을 추적할 수 있다.

    a. 정적 추적(Static Tracing)
    정적 추적이라 하면 위의 성능분석(Profiling)과 유사한 명령을 통해서 이용할 수 있지만 목적이 다르다. 성능을 분석하는 부분은 Overhead를 보면서 성능의 언밸런스를 찾는 게 초점이라면 Tracing은 특정 이벤트가 발생의 근원부터 언제, 어떻게, 어떤 과정을 통해서 이벤트가 발생했는지 전 과정을 살펴볼 수 있고 그것을 통해서 실행과정에 문제가 있는지 혹은 어떠한 과정을 토대로 문제가 생겨나는지를 추적할 수 있다.
    static_16.png 
    [그림 16]Static Tracing

    b. 동적 추적(Dynamic Tracing)
    정적 추적(Static Tracing)은 우선 event sampling을 한 후에 수집이 완료된 perf.data를 통해서 분석 결과를 펼쳐놓고 추적하는 거라면 동적 추적(Dynamic Tracing)은 현재 실행되고 있는 커널, 프로세스를 대상으로 특정함수, 변수 등에 대해서 추적이 가능하다. 예를 들면 tcp_sendmsg 라는 커널함수가 불렸는지, 불렸다면 인자는 무엇이었는지, 그 함수의 리턴 값은 무엇인지 언제 몇 번 불렸는지 등을 하나하나 추적 가능하다. 아래와 같이 추적하고 싶은 함수명 tcp_sendmsg(커널함수)을 probe로 추가하고

    Dynamic_17.png
    [그림 17]Dynamic Tracing 1

    아래와 같이 --list 옵션을 통해서 다음과 같이 확인할 수 있다.

    dy_18.png
    [그림 18]Dynamic Tracing 2

    지정해둔 사용자 정의 이벤트 'probe:tcp_sendmsg'를 4초간 추적하고 상태를 본다.
    -R옵션은 --raw-samples라는 옵션으로 열려있는 모든 카운터들로부터 sample 기록 모두를 수집한다는 내용이다. 아래와 같이 따로 추가하지 않아도 기본옵션으로 지정된다.
    dt_19.png
    [그림 19]Dynamic Tracing 3

    

[필자소개]

stw_20.png
손태웅
• 주요경력

(2016) NIPA Open Frontier Lab 3기
(2015) Linux kernel - perf 프로젝트 contributor 활동 중
(2014) (주) XS 선임연구원 (네트워크, 서버, ARM, NAS 등)

(2013) NIPA 창의도전형 R&D 2기

(2012) NIPA SW Maestro 3기

(2011) (주) MTOME 개발연구원 (임베디드, WinAPI 등)

• 활동 커뮤니티 - 
• 전문분야Linux kernel, Profiling, C


by 공개SW역량프라자에 의해 작성된 이 저작물은 크리에이티브 커먼즈 저작자표시-변경금지 4.0 국제 라이선스에 따라 이용할 수 있습니다.
      List of Articles
      번호 제목 글쓴이 날짜 조회 수
      공지 오픈프론티어 개발 프로젝트 연재 OSS 2016-08-06 2455
      25 [3기 정진영 개발자] XPUSH (실시간 커뮤니케이션 플랫폼) file OSS_ 2017-02-20 1233
      24 [3기 방진호 개발자] Blink (웹브라우저 크롬의 레이아웃 엔진) file OSS_ 2017-02-20 1127
      » [3기 송태웅 개발자] Linux Kernel - perf(리눅스 서버의 버전별, 기능별 성능측정 분... file OSS_ 2017-02-08 2907
      22 [2기 채수원 개발자] Yona (설치형 프로젝트 호스팅 SW) file OSS_ 2017-02-08 1292
      21 [2기 김현종 개발자] UrQA (Android Crash Report 도구) file OSS_ 2017-02-07 1022
      20 [2기 임정민 개발자] 구름IDE (클라우드 통합 개발 환경) file OSS_ 2017-02-07 1283
      19 [3기 김영근 개발자] Pandas (빠르고 유연한 데이터 처리를 위한 파이썬 라이브러리) file OSS 2016-12-22 1629
      18 [3기 윤제상 개발자] Apache Zeppelin (빅데이터 처리툴 Spark의 실행과 데이터 시각... file OSS 2016-12-16 2399
      17 [3기 신정규 개발자] 텍스트큐브/메모리큐브 (개인화에 집중한 설치형 블로그 서비스 ... file OSS 2016-12-16 1137
      16 [3기 김종광 개발자] IoT분야의 통신, DB, 데이터 분석을 지원하는 개발지원플랫폼 file OSS 2016-12-15 1258


      사이트하단 로고, 하단메뉴, 트위터 바로가기

      퀵메뉴모음
      퀵메뉴열기
      퀵메뉴닫기