3P by neo 3달전 | favorite | 댓글 1개

Brendan의 사이트: 시작하기

  • Brendan Gregg의 블로그 홈페이지는 시스템 성능, BPF 도구, Linux 성능 등에 대한 다양한 주제를 다룸.
  • 최근 게시물에는 프레임 포인터의 복귀, eBPF 다큐멘터리, eBPF 관측 도구가 보안 도구가 아님 등의 내용이 포함됨.
  • 블로그는 기술적인 내용과 함께 Brendan이 참여한 여러 컨퍼런스와 발표 내용도 공유함.

프레임 포인터의 복귀

  • 프레임 포인터가 없는 시스템에서는 스택 추적이 libc 레이어에서 멈추어, 애플리케이션 프레임이 누락됨.
  • Fedora와 Ubuntu는 기본적으로 프레임 포인터를 포함하여 libc를 컴파일하는 버전을 출시함으로써 이 문제를 해결함.
  • 프레임 포인터는 외부 프로파일러와 디버거에 의해 사용되며, 플레임 그래프에 의해 시각화됨.

프레임 포인터란?

  • x86-64 ABI 문서에 따르면 CPU 레지스터 %rbp를 스택 프레임의 "베이스 포인터"로 사용할 수 있음.
  • 이 기술은 스택 추적을 위해 널리 사용되며, Linux perf와 eBPF 등에 의해 사용됨.

2004년: 프레임 포인터 제거

  • 2004년에 gcc 개발자 Roger Sayle은 프레임 포인터 생성을 중단하는 변경을 진행함.
  • 이 변경은 성능 향상을 가져왔으나, eBPF의 등장으로 오늘날에는 일부 디버거/프로파일러가 이로 인해 문제를 겪음.

2005-2023년: 고장난 프로파일러의 겨울

  • 프레임 포인터 제거 변경이 x86-64에도 적용되었으나, 이 아키텍처는 더 많은 레지스터를 가지고 있어 큰 이득이 없었음.
  • 이로 인해 많은 디버거/프로파일러가 제대로 작동하지 않게 됨.

2014년: Java in Flames

  • Netflix에 합류했을 때, Java의 프레임 포인터 지원 부족이 모든 애플리케이션 스택을 깨뜨림을 발견함.
  • 이 문제를 해결하기 위해 JVM c2 컴파일러에 대한 수정을 개발함.

2015-2020년: 오버헤드

  • 프레임 포인터를 모든 것에 추가하는 것의 성능 오버헤드는 일반적으로 1% 미만임.
  • 특정 마이크로벤치마크에서는 오버헤드가 10%에 달할 수 있음.

2022년: 업스트림 시도

  • Google, Meta, Netflix 등 대형 기업들이 이미 프레임 포인터를 모든 것에 활성화했음을 암시함.
  • 이러한 변경을 모두에게 이익이 되도록 기본값으로 설정하는 데는 여러 어려움이 있음.

2023, 2024년: Fedora와 Ubuntu에서 프레임 포인터

  • Fedora는 프레임 포인터를 다시 활성화하는 제안을 받아들임.
  • Ubuntu도 24.04 LTS 버전에서 기본적으로 프레임 포인터를 활성화함.

2034년 이후: 프레임 포인터를 넘어서

  • 스택을 추적하는 데는 여러 가지 방법이 있으며, LBR, BTS, AET, DWARF, eBPF 스택 워킹, ORC, SFrames, 그림자 스택 등이 있음.
  • 미래에는 SFrames나 그림자 스택이 모든 스택 추적에 사용될 수 있음.

결론

  • 프레임 포인터의 복귀는 CPU 플레임 그래프를 더욱 의미 있게 만들고, Off-CPU 플레임 그래프를 처음으로 작동시키며, 다른 새로운 가능성을 열어줌.
  • 연속 프로파일러에게도 승리이며, 프로파일러가 완전히 작동하기 위해 고객에게 OS 변경을 설득할 필요가 없어짐.

GN⁺의 의견

  • 프레임 포인터의 복귀는 시스템 성능 분석과 디버깅에 큰 도움이 될 것으로 보임. 특히 복잡한 소프트웨어 시스템에서 문제를 진단하고 성능을 최적화하는 데 필수적인 도구임.
  • 이러한 변화는 오픈소스 커뮤니티의 협력과 기여의 중요성을 보여줌. Fedora와 Ubuntu의 결정은 다른 배포판에도 영향을 미칠 수 있으며, 이는 전체 리눅스 생태계에 긍정적인 변화를 가져올 것임.
  • 프레임 포인터를 다시 도입하는 것은 성능 저하와 디버깅 용이성 사이의 균형을 맞추는 문제임. 이러한 결정은 실제 운영 환경에서의 성능 테스트와 분석을 통해 더 잘 이해될 수 있음.
  • 기술적인 배경이 있는 사용자들에게는 이러한 변화가 흥미로울 수 있으며, 시스템 성능 향상에 관심이 있는 개발자나 시스템 관리자들에게 유용한 정보를 제공함.
  • 프레임 포인터와 유사한 기능을 제공하는 다른 기술이나 도구가 있다면, 예를 들어 Intel의 VTune Profiler나 AMD의 uProf와 같은 하드웨어 기반 프로파일러를 사용할 수 있음. 이러한 도구들은 프레임 포인터 없이도 성능 분석을 가능하게 함.
Hacker News 의견
  • 2000년대 초반 스택 프레임 포인터 생략이 퍼지기 시작했을 때의 경험
    • 저자는 당시 컴퓨터 과학을 공부하고 있었으며, 사용하는 컴퓨터는 오래되고 성능이 낮았음.
    • 디버깅이 어려워지자 Python을 사용하기 시작함으로써 디버깅 문제를 피함.
  • 페도라(Fedora) 배포판에서 스택 프레임 포인터를 유지하기 위한 노력
    • 스택 프레임 포인터가 큰 오버헤드를 가진다는 잘못된 믿음이 있었으나, 실제 오버헤드는 1% 미만임.
  • 애플이 ARM 아키텍처에서 스택 트레이스를 항상 의미 있게 유지한 점
    • 특정 함수는 프레임 레코드를 생성하지 않을 수 있지만, 스택 트레이스는 디버그 정보 없이도 유의미함.
  • 구글에서의 경험과 커뮤니티와의 20년간의 논쟁
    • libunwind를 gperftools에 적용하기 위한 패치 작업 및 유지보수 경험 공유.
  • 과거에 -fomit-frame-pointer 옵션으로 성능 향상을 경험한 사례
    • 32비트 프로세서에서 MySQL과 PHP를 컴파일하여 하드웨어 비용 절감.
  • Virgil 프로그래밍 언어의 스택 프레임 관리 방법
    • 동적 스택 할당이 없는 경우, 간단한 테이블 조회로 프레임 크기를 찾을 수 있음.
    • 메타데이터 디코딩을 구현하는 코드에 대한 설명.
  • 스택을 '걷는' 대신 RBP와 RSP를 사용하여 두 개의 스택을 관리하는 아이디어
    • 호출 스택이 단순히 반환 주소의 배열이 됨으로써 스택 걷기의 필요성 감소.
  • 프레임 포인터에 대한 지지와 관련된 경험 및 생각 공유
    • 프레임 포인터 활성화 여부는 사례별로 결정되어야 하며, 벤치마킹이 중요함.
    • 빌드 시스템이 이를 전체적으로 변경할 수 있는 기능을 제공하는 것의 중요성.
    • SFrame에 대한 기대감과 현재 문제를 해결할 잠재력.
  • 프로파일링이 20년 동안 문제가 되었고 이제야 해결되었다는 의견
    • 프레임 포인터의 부재가 많은 사람들에게 고통스러웠으며, 이제 리눅스가 그것을 되돌리는 것을 보며 그들의 노력이 인정받는 것 같음.
  • 시스템 프로파일링을 가능하게 하는 메커니즘의 성능에 대한 불만이 역설적임
    • 성능 문제를 식별할 수 있게 해주는 시스템에 대한 성능 불만은 성급한 최적화의 극치임.