리눅스 성능

 (brendangregg.com)
3P by GN⁺ | ★ favorite | 댓글 1개
  • Brendan Gregg의 Linux Performance 페이지는 리눅스 성능 조사를 시작할 때 필요한 관측성·분석·벤치마킹·튜닝 자료를 한곳에 모은 링크 허브임
  • 핵심 도구 흐름은 perf, eBPF, bcc, bpftrace, Flame Graphs로 이어지며, 명령 예제부터 추적 도구와 시각화까지 바로 접근할 수 있음
  • 문서 자료는 Netflix의 2015년 성능 분석 글, EC2 튜닝, Linux load averages, frame pointers, gdb 예제와 두 권의 성능 책으로 확장됨
  • 강연 목록은 40분 개요, 90분 도구 튜토리얼, 컨테이너 성능 분석, SRE 체크리스트처럼 상황별 학습 경로를 제공함
  • 각 도구 지도는 이미지 오른쪽 아래의 연도로 최신성을 확인해야 하며, 통합 다이어그램은 다른 개별 다이어그램만큼 완전하지 않음

성능 자료 허브와 도구 지도

  • 이 페이지는 Brendan Gregg가 만든 Linux performance 자료를 모아 둔 링크 허브임
  • 오른쪽 도구 지도 이미지는 슬라이드 덱에 맞도록 큰 글꼴로 만들어졌고, 출력해 사무실 벽에 붙여도 되는 형식임
  • 도구 지도는 리눅스 성능 작업을 다음 영역으로 나눠 보여줌
  • 각 이미지가 얼마나 최신인지는 오른쪽 아래의 연도를 확인해야 함
  • 관측성, 정적 성능 튜닝, perf-tools/bcc를 합친 고해상도 다이어그램도 별도로 제공됨
    • png
    • svg
    • 이 통합 다이어그램은 다른 개별 다이어그램만큼 완전하지 않음

바로 연결되는 주요 도구

  • perf: perf one-liners, 예제, 시각화 자료
  • eBPF tools: BPF/bcc 추적 도구와 예제
  • perf-tools: Ftrace 기반 perf 도구 모음
  • bcc: BPF/bcc 성능 도구 모음
  • bpftrace: BPF/bpftrace 성능 도구 모음
  • Flame Graphs: perf와 다른 프로파일러를 이용한 Flame Graph 사용법

문서와 학습 자료

eBPF, ftrace, perf 심화 글

상황별 추천 강연

  • Linux Systems Performance, USENIX LISA 2019

    • 40분 동안 Linux 시스템 성능을 관측성, 방법론, 벤치마킹, 프로파일링, 추적, 튜닝의 6개 측면으로 요약함
    • video, youtube, slides, PDF

  • Linux Performance 2018, PerconaLive 2018

    • 2018년 Linux performance의 최근 변화와 기능을 20분 키노트로 요약함
    • youtube, slideshare, PDF

  • Linux Performance Tools, Velocity 2015

    • 90분 튜토리얼로 성능 관측성, 벤치마킹, 튜닝, 정적 성능 튜닝, 추적 도구와 방법론, 라이브 데모를 다룸
    • youtube playlist, slideshare, PDF

  • How Netflix Tunes EC2 Instances for Performance, AWS re:Invent 2017

    • 성능 관측성보다 튜닝에 초점을 맞추며, Netflix 배경, AWS EC2 인스턴스 타입과 기능, Linux kernel tunables, 관측성을 다룸
    • youtube, slideshare

  • Container Performance Analysis, DockerCon 2017

    • 호스트와 컨테이너 중 병목 위치를 찾고, 컨테이너 앱을 프로파일링하며, 커널로 더 깊이 들어가는 방법을 다룸
    • youtube, slideshare

  • Broken Linux Performance Tools, SCaLE14x 2016

    • Linux 시스템 도구, 지표, 통계, 시각화, 측정 오버헤드, 벤치마크에서 자주 생기는 문제와 “What You Can Do” 조언을 함께 다룸
    • youtube, slideshare, PDF

  • Using Linux perf at Netflix, Kernel Recipes 2017

    • CPU 프로파일링과 Flame Graphs 작동에 초점을 맞추며, perf_events 속성과 Java, Node.js, VM, 컨테이너 프로파일링 시 stack traces와 symbols 문제를 포함함
    • youtube, slideshare

  • Give me 15 minutes and I'll change your view of Linux tracing, LISA 2016

  • Performance analysis superpowers with Linux eBPF, O’Reilly Velocity 2017

    • Linux 4.x 시리즈에 추가된 enhanced BPF, 즉 eBPF를 성능 분석, 관측성, 디버깅에 활용하는 내용을 다룸
    • 프런트엔드는 BPF 인터페이스와 도구 모음을 제공하는 오픈소스 프로젝트 bcc임
    • youtube, slideshare, PDF

  • Linux Performance Analysis: New Tools and Old Secrets, LISA 2014

    • ftrace와 perf_events 도구, 그리고 주로 ftrace를 쓰는 perf-tools를 다룸
    • ftrace는 Linux 커널에 여러 해 동안 내장되어 있었지만 거의 발견되지 않은 추적기로 소개됨
    • youtube, slideshare, PDF

  • Performance Checklists for SREs, SREcon 2016

    • 후반부에 Linux incident performance response용 체크리스트를 포함하며, 급한 Linux 성능 분석에도 유용할 수 있음
    • youtube, usenix, slideshare, PDF

외부 추천 자료

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 실시간 앱을 돌리는 Debian/Ubuntu VPS에서 tuned를 쓰고 있는데 꽤 잘 동작함
    커널 매개변수, 즉 sysctl 설정이나 커널 튜너블을 직접 바꾸는 것보다 단순함
    https://access.redhat.com/documentation/en-us/red_hat_enterp...
    sudo apt install tuned

    • SAP 워크로드에도 Tuned를 쓰고 있고 아주 마음에 듦

  • Brendan Gregg가 이제 Intel에 있는 줄 몰랐음
    https://en.wikipedia.org/wiki/Brendan_Gregg
    바이럴 영상 Shouting in the Data Center의 주인공이기도 함
    https://www.youtube.com/watch?v=tDacjrSCeq4
    진짜 천재임

  • 원문에서 다루는 거의 모든 내용은 지연 시간이 아니라 네트워크, 디스크, 기타 입출력, CPU의 처리량/대역폭에 관한 것이라는 점은 짚고 넘어갈 만함
    많은 사람에게 성능은 처리량을 뜻하니 이해는 됨. 하지만 처리량보다 지연 시간이 훨씬 중요한 경우도 있고, Linux에서 지연 시간을 튜닝하려면 다른 도구 묶음이 필요함

    • 꽤 타당한 지적임. 처리량을 늘리는 것보다 지연 시간을 줄이는 쪽이 훨씬 어렵기도 해서[1], 지연 시간에 신경 쓰는 일이 중요할 때가 많음
      사람들이 최적화할 수 있는 또 다른 축은 와트당 성능이지만 여기서는 길게 말하지 않겠음
      처리량 최적화가 곧 지연 시간 최적화가 되는 경우도 있음. 예를 들어 더 많은 프로세스를 한 박스에 올릴 수 있으면 프로세스와 통신 대상 사이의 평균 거리가 줄어 평균 지연 시간도 낮아짐
      지연 시간을 최적화할 때 아주 당연한 일은 처리량이 병목이 되지 않을 만큼 충분히 늘리는 것임
      지연 시간을 공격적으로 최적화한다면 Linux 튜닝 자체는 많지 않은 느낌임. 틀렸을 수도 있지만, 대체로 코어 고정, tickless 실행, 사용자 공간 네트워킹, 그리고 페이지 크기·SMT·절전 설정·하드웨어 선택 같은 하드웨어 쪽 조정이 주가 되는 듯함
      [1] https://pdfs.semanticscholar.org/bce7/5f78d340cac32dccd8631f...
    • bandwidth보다는 throughput이라고 부르는 편이 맞아 보임. 의미는 비슷하지만, 처리량과 지연 시간의 대비는 오래전부터 논의되어 왔음
      때로는 둘 다 개선할 수 있지만, 보통은 트레이드오프임
    • 지연 시간 튜닝과 관련해 추천할 만한 도구나 자료가 궁금함
    • 시스템의 실시간 특성을 위해 지연 시간을 줄이는 게 목표라면, 기본 Linux 배포판에서 아무리 여러 노브를 만져도 만족스러운 시스템이 되지 않을 가능성이 큼

  • 기다리는 것도 좋은 전략임
    Linux 6.5부터 스케줄러는 한 SMT “코어”가 바쁠 때 다른 “코어”에 뭔가를 배치하는 게 최선이 아닐 수 있음을 이해함. 실제로는 컨텍스트 전환 비용이 매우 낮은 단일 코어에 가깝기 때문임
    이 덕분에 매우 병렬적인 작업들이 체감될 정도로 더 빠릿해졌고, CPU 사용률 그래프에서도 보임
    캐시 일관성과 NUMA 문제 때문에 결과는 다를 수 있음

    • 이전 커널에서도 SMT 비활성화만으로 더 빠릿한 효과를 얻을 수 있고, 일부 부채널 공격도 막으며 전력 효율도 올라감

  • 관련 글:
    Linux Performance - https://news.ycombinator.com/item?id=13498485 - 2017년 1월, 댓글 64개
    Linux Performance - https://news.ycombinator.com/item?id=8205057 - 2014년 8월, 댓글 22개

  • 어떤 튜너블 매개변수를 바꾸고 싶어 하면서도 왜 그 변경이 원하는 효과를 낼지, 애초에 왜 그 값으로 설정되어 있는지 설명하지 못한다면 운영 환경에서는 못 바꾸게 할 것임
    “Chesterton의 튜너블 매개변수”라고 부를 만함

    • 가상의 이유를 설명할 수 있다 해도, 어차피 운영 환경 밖에서 벤치마크하면 되지 않나?

  • Brendan의 eBPF 작업을 생각하면, 이 자료는 다양한 성능 상황에서 더 쉽게 모니터링하고 평가하는 방법으로 받아들여짐
    조정과 튜닝에는 트레이드오프가 있고, 보통 하나를 최적화하면 다른 쪽이 손해를 보는 경우가 많음
    부가적으로, btop은 glances를 대체하는 올인원 TUI 시스템 성능·부하 뷰어로 매우 유용했음. 개발자들이 이를 얼마나 활용하고 있는지, 더 나은 TUI 모니터링 도구를 만들 동기가 있는지도 궁금함
    서버에 들어가면 제일 먼저 tmux를 띄우고 창 하나를 btop에 할당함

  • 나에게 Linux 성능 “튜닝”은 Spectre/Meltdown 완화책 비활성화와 같음
    이 경우 계산 노드는 인터넷 접근이 없는 VPC 안에서 돌아가니 위험이 꽤 낮아 보임

    • 어떤 CPU를 쓰느냐에 따라 다름. Zen 4에서는 완화책 비활성화가 지원되지 않았고 버그나 크래시를 일으켰음
      그 특정 크래시는 고친 것 같지만 그래도 추천하지 않음. AMD와 Intel의 최신 CPU는 최소한 기본 완화책을 켠 상태로 실행되도록 설계되어 있음

  • 북마크해 둠. 곧 작업 중인 일에 유용할 것 같음
    아직 슬라이드를 전부 읽지는 않았지만, 커널 빌드 옵션으로 의미 있는 성능 향상을 본 적이 있는지가 궁금함
    예전에 Gentoo를 쓰며 빌드 플래그를 만질 때는 커널 Makefile을 바꿔 -O3를 쓰고 -march=native 패치를 적용하곤 했음. 돌아보면 Phoronix 벤치마크상 여러 워크로드에 오히려 해로운 것으로 보이는데, 반대 사례를 본 적이 있는지 궁금함

  • 좋은 사이트임. Linux 성능을 튜닝이든 모니터링이든 요약하려는 성향이 있어서 깊게 숨을 들이쉬게 됨
    이 주제는 깊고, 관측 도구의 종류도 아주 많음. 최소한 uptime, dmesg, iostat은 깊이 알아야 함. 이 도구들은 부하, 메모리, CPU 등 여러 시스템 측면을 훑어보며 상태 진단의 첫 단서를 줌. 내가 부르는 “한번 들여다보자” 체크리스트의 100쪽 중 1쪽임
    성능 분석 방법론에서는 시스템 동작과 워크로드 특성을 전체적으로 평가하기 위해 신중한 벤치마크를 권함. 변경 전후 시나리오를 비교하고, 먼저 작은 변경을 한 뒤 이득이 있다고 판단되는 것들을 점진적으로 합쳐야 함. 실험실과 운영 환경은 절대 똑같이 동작하지 않음
    여기서부터 까다로워짐. perf 같은 도구로 하는 CPU 프로파일링과 flame graph 같은 시각화는 CPU 활동을 표적 분석하게 해 주고, 하드웨어 이벤트 추적까지 더해 계산 효율을 최적화할 수 있음. “앱 문제예요, 개발팀 최신 릴리스 전엔 괜찮았어요” 수준 이상을 알아야 함
    관리자로서 개발자와 이야기할 때는 Linux에서 ftrace와 BPF 같은 도구가 필요해짐. 커널 함수 실행과 시스템 호출을 자세히 추적할 수 있어 문제 해결과 성능 최적화에 중요함. 반대로 개발자라면 관리자의 직감을 검증해야 할 수도 있음. 말처럼 신뢰하되 검증해야 함
    자기 코드라면 BPF를 알아야 함. BPF는 효율적인 커널 내부 추적을 가능하게 할 뿐 아니라 bcc와 bpftrace를 통한 고급 맞춤 프로파일링 도구 개발도 밀어 주며, 시스템 성능을 더 깊게 들여다보게 해 줌
    마지막으로, 이건 정말 어렵다. 튜닝은 CPU와 메모리부터 네트워크 설정까지 수많은 시스템 구성요소와 커널 매개변수를 조정해 다양한 워크로드에서 성능과 신뢰성을 최적화하는 일임. 아니면 네트워크 탓으로 돌리면 됨
    실제로는 변경 관리에 대한 좋은 태도가 필요함. 코드나 커널 매개변수를 쫓는 일은 모두를 압도할 수 있고, 시간에 쫓기는 상황에서는 압박 때문에 사람의 실수 가능성이 더 커짐

답변달기
GeekNews BeeBS 게시판 오픈! 자유로운 이야기와 소소한 일상을 함께 나눠보세요.