▲

메타, jemalloc에 대한 새로운 투자와 오픈소스 협력 강화

 (engineering.fb.com)
2P by GN⁺ 24일전 | ★ favorite | 댓글 1개
  • 고성능 메모리 할당자 jemalloc은 Meta 소프트웨어 스택에서 Linux 커널, 컴파일러와 함께 핵심 인프라 역할을 해온 기반 컴포넌트
  • 최근 몇 년간 jemalloc 개발을 이끌어온 핵심 엔지니어링 원칙에서 점차 벗어나면서 기술 부채가 누적되어 진행이 느려짐
  • 커뮤니티 피드백을 수용하고 프로젝트 창립자 Jason Evans를 포함한 구성원들과 논의를 거쳐, 원래의 오픈소스 저장소가 재활성화(unarchived) 됨
  • 향후 기술 부채 정리, Huge-Page 할당자 개선, 메모리 효율성 향상, AArch64 최적화 등에 집중할 계획
  • Meta가 jemalloc의 장기적 스튜어드십을 재확인하며, 커뮤니티와의 협력을 통해 프로젝트를 발전시키겠다는 방향으로 전환

jemalloc의 위치와 중요성

  • jemalloc은 고성능 메모리 할당자로, Meta 소프트웨어 스택에서 일관되게 높은 레버리지를 제공해온 컴포넌트
  • 하드웨어 변화와 상위 레이어 소프트웨어 변화에 맞춰 지속적으로 적응해왔으며, Linux 커널과 컴파일러와 함께 Meta 인프라의 안정성과 성능에 기여함

원칙에서의 이탈과 반성

  • 기반 소프트웨어 컴포넌트는 실용성과 원칙 사이에서 가장 높은 수준의 엄격함이 필요
  • jemalloc이 제공하는 높은 레버리지 때문에 단기 이익을 실현하려는 유혹이 존재하며, 이를 거부하려면 조직 차원의 강한 자기 규율이 필요
  • 최근 몇 년간 jemalloc 개발을 이끌어온 핵심 엔지니어링 원칙에서 점진적 이탈이 발생했음
  • 일부 결정은 즉각적 이점을 제공했으나, 그 결과로 생긴 기술 부채가 진행을 저해
  • 커뮤니티 피드백을 진지하게 받아들이고, 프로젝트 창립자 Jason Evans를 포함한 커뮤니티 구성원들과 만남을 진행
  • 스튜어드십이 jemalloc의 장기적 건강에 미친 영향을 깊이 성찰하고, 접근 방식 변화를 공유
  • 기술 부채 제거와 jemalloc을 위한 장기 로드맵 재구축 작업 착수

새로운 장: 저장소 아카이브 해제와 향후 계획

  • 커뮤니티와의 대화 결과, 원래의 jemalloc 오픈소스 저장소가 재활성화(unarchived) 됨
  • Meta가 프로젝트의 스튜어드 역할을 계속할 수 있게 되었으며, 유지보수 부담 축소와 코드베이스 현대화에 집중할 방향
    • 기술 부채 정리: 리팩토링과 개선을 통해 모든 사용자에게 효율적이고 신뢰할 수 있으며 사용하기 쉬운 상태 유지
    • Huge-Page 할당자(HPA): Transparent Hugepages(THP)를 더 잘 활용하여 CPU 효율성 향상
    • 메모리 효율성: 패킹, 캐싱, 퍼징 메커니즘 개선을 통한 메모리 효율 최적화
    • AArch64 최적화: ARM64 플랫폼에서 기본 상태로 좋은 성능을 보장

커뮤니티와의 협력 강화

  • 메타는 행동을 통한 신뢰 구축을 강조하며, jemalloc의 건강한 발전을 목표로 함
  • 커뮤니티의 피드백과 참여를 환영하며, 함께 jemalloc의 미래를 만들어가기를 기대함
  • 오픈소스 생태계 내에서 지속 가능한 협력과 발전을 추진할 것

함께 보면 좋은 글 β

▲
GN⁺ 24일전  [-]
Hacker News 의견들

  • Facebook 재직 시절, jemalloc의 purging 메커니즘을 개선하기 위해 커널 패치를 유지보수했음
    커널이나 보안 커뮤니티에서는 인기가 없었지만, 벤치마크에서는 효율이 높았음
    문제는 메모리를 다른 스레드로 재할당할 때 zeroing이 발생해 캐시 지역성과 성능에 영향을 주는 점이었음
    같은 보안 도메인 내에서 메모리를 재활용할 때는 불필요한 동작이었지만, ‘보안 도메인’을 어디까지로 정의할지 합의가 어려웠음
    관련 논의는 Linux Kernel 메일링 리스트에 있음

    • 아직도 그 패치를 언급하는 게 놀라움
      HHVM에서 해당 패치 적용 전후로 광범위한 벤치마크를 했지만, 시스템 수준에서는 통계적으로 유의미한 차이가 없었음
      일부 마이크로벤치마크에서는 개선이 있었겠지만, 전체 시스템 성능에는 영향이 없었기에 커널에서 제외되었음
    • 어떤 지표(metric) 가 개선되었는지 궁금함
    • cgroup 내에서라면 프로세스 간 메모리 내용이 새어도 괜찮다고 보는 건 위험한 생각처럼 들림

  • 최근 Microsoft의 mimalloc을 LD_PRELOAD로 사용해 1GB huge page를 활용했음
    메모리 집약적인 프로그램에서 약 20%의 성능 향상을 얻었음
    Linux에서 오픈소스 MS 라이브러리를 써서 성능을 높이는 게 묘한 기분임
    malloc 영역에 더 많은 경쟁이 필요하다고 느낌

    • 여러 allocator를 테스트했는데, 최신 tcmalloc이 시간과 메모리 모두에서 가장 좋은 결과를 보였음
      Rust로 작성된 앱들이었고, 대부분 정적으로 링크했음
      예를 들어 app1에서는 glibc 대비 tcmalloc이 RSS 35% 절감, 처리 시간 30% 단축을 보였음
      전체 결과는 tcmalloc 저장소 기준으로 테스트했음
    • 예전에는 Dr. Dobbs나 BYTE 같은 잡지에 커스텀 메모리 할당기 광고가 많았음
      Turbo Pascal조차도 메모리 할당기를 직접 정의할 수 있는 API를 제공했음
      결국 “one size fits all” 접근은 오래전부터 한계가 있었음
    • GC 언어의 장점 중 하나는 할당/해제 비용이 묶여서 프로파일링 시 더 명확히 드러난다는 점임
    • 예전 Apache Portable Runtime의 메모리 풀 개념이 인상 깊었음
      요청마다 풀을 만들고, 요청이 끝나면 전체를 한 번에 해제하는 구조였음
      malloc도 이런 식으로 진화할 여지가 많다고 생각함
    • 경우에 따라 malloc보다 직접 mmap으로 huge page를 매핑하는 게 더 효율적임
      할당 패턴이 단순하다면 서드파티 malloc보다도 나은 결과를 얻을 수 있음
      malloc을 마법 같은 블랙박스로 보지만 실제로는 그렇게 뛰어나지 않음

  • 우리 팀은 2년 전 glibc malloc에서 jemalloc으로 마이그레이션했음
    Python 서비스에서 메모리 사용량이 15~20% 줄었음
    다만 컨테이너 환경에서는 oversize_threshold 조정이 중요했음 — 잘못 설정하면 OOM이 발생함
    장기 실행 서비스에서 jemalloc과 mimalloc을 비교한 벤치마크가 있는지 궁금함

  • 관련 참고글로 Jemalloc Postmortem과
    Jemalloc Repositories Are Archived을 추천함

  • 혹시 이번 변화가 글로벌 메모리 부족 때문인지 궁금함
    “메모리 할당기 교체로 연간 수백만 달러 절감” 같은 계산이 나올 수도 있음

    • Facebook은 10년 전부터 이런 미세 최적화로 수익 절감을 추구했음
      0.1% 효율 향상만으로도 월 10만 달러 절감이 가능했음
      주된 절감 요인은 냉각비용(HVAC)과 서버 구매 감소였음
      지금은 메모리 절감도 큰 이슈지만, 그때는 아니었음
    • 단순히 비용뿐 아니라, 메모리 공급 지연을 상쇄하기 위한 효율 개선도 중요함
    • Meta에서는 수백만 달러 규모의 절감을 찾는 게 흔한 일임
      수천 대 서버에 영향을 주면 작은 개선도 큰 숫자로 보임
      이런 정량적 개선 문화가 자리 잡혀 있음
    • 그 회사의 평판을 생각하면, 단순한 메모리 부족 이상의 복잡한 사정이 있을 수도 있음
    • LLM, 전력, 서버 메모리 효율이 점점 더 중요해지는 시점임
      10%만 빨라져도 LLM 경쟁에서 우위를 점할 수 있음
      성능 개선의 인센티브가 매우 큼

  • 호주에서 저수준 프로그래밍을 하던 중 정리해고를 당했음
    이런 문제를 푸는 걸 정말 좋아하지만, 현지 시장은 대부분 React CRUD 위주라 아쉬움

    • AU에서 저수준 데이터 처리 관련 채용 중임. bio에 링크 있음
    • 나도 호주에서 React CRUD만 하며 같은 생각을 했음
    • 원격 근무를 찾는다면 Igalia 채용 페이지가 흥미로울 수 있음
    • HFT 회사(IMC trading) 도 이런 저수준 최적화 업무를 많이 하며, 현재 호주에서 채용 중임
    • SIG도 시드니에서 관련 포지션을 모집 중임: SIG Careers

  • World Bank 자금으로 진행된 스타트업 프로젝트에서 Ruby + jemalloc을 프로덕션에 배포했음
    속도와 메모리 효율이 눈에 띄게 개선되어 AWS 비용을 크게 절감했음
    8년 전 일인데, 왜 아직도 jemalloc이 표준으로 자리 잡지 못했는지 의문임

    • 대부분은 단순히 정보 부족 혹은 관성 때문임
      이미 운영 중인 시스템을 바꾸는 건, 이득이 명확해도 쉽지 않음

  • jemalloc을 이용해 메모리 누수 원인을 추적한 사례도 있음
    GOV.UK 기술 블로그 글 참고

  • Meta가 자체 포크에서 작업하던 내용을 대규모로 병합함
    PR #2863에서 확인 가능함

  • jemalloc의 타임라인이나 역사가 정리된 자료가 있는지 궁금함
    오픈소스 프로젝트인데 왜 Meta가 주도권을 쥐고 있는지 의문임

    • 창시자 Jason Evans가 작년에 전체 경위를 정리함
      Jemalloc Postmortem 블로그 참고
    • 최근 5년간 커밋을 보면 상위 6명 중 4명이 Meta 직원임
      나머지 2명도 비공개로 Meta 소속일 가능성이 있음
답변달기