▲

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

 (engineering.fb.com)
1P by GN⁺ 14시간전 | ★ favorite | 댓글 1개
  • 고성능 메모리 할당기 jemalloc이 메타의 핵심 인프라 구성요소로, 장기적 성능과 안정성 향상에 기여함
  • 메타는 코드베이스 현대화와 유지보수 부담 감소를 목표로 jemalloc 개발에 다시 집중하고 있음
  • 최근 커뮤니티와의 논의를 통해 기술 부채 제거와 장기 로드맵 재구축을 추진 중임
  • 개선 계획에는 Huge-Page 할당기 강화, 메모리 효율 향상, AArch64 최적화 등이 포함됨
  • 메타는 오픈소스 커뮤니티와의 협력을 통해 jemalloc의 지속적 발전을 도모하고 있음

jemalloc의 역할과 중요성

  • jemalloc은 메타 소프트웨어 스택에서 오랫동안 핵심적인 고성능 메모리 할당기로 사용되어 왔음
    • 하드웨어 및 상위 소프트웨어의 변화에 맞춰 지속적으로 적응해 왔음
    • Linux 커널과 컴파일러와 함께 안정적이고 성능 높은 인프라 구축에 기여함
  • 메타는 jemalloc이 장기적으로 제공한 신뢰성과 성능상의 이점을 인정하고 있음

원칙 회복과 커뮤니티 피드백

  • jemalloc과 같은 기초 소프트웨어 구성요소는 높은 수준의 엔지니어링 엄격함이 요구됨
  • 최근 몇 년간 일부 결정이 단기적 이익을 가져왔으나, 결과적으로 기술 부채가 누적되어 개발 속도를 저하시킴
  • 메타는 커뮤니티의 피드백을 수용하고, 프로젝트 창립자 Jason Evans를 포함한 구성원들과 논의함
    • 이를 통해 기술 부채 제거와 장기적 로드맵 재정비를 시작함

새로운 단계로의 전환

  • 커뮤니티와의 협의 결과, jemalloc 오픈소스 저장소가 재활성화(unarchived) 되었음
  • 메타는 프로젝트의 관리자로서 역할을 지속하며, 코드베이스 현대화와 유지보수 효율화를 추진 중임
  • jemalloc을 최신 및 차세대 하드웨어와 워크로드에 맞게 지속적으로 진화시킬 계획임

향후 개발 중점 영역

  • 기술 부채 감소: 코드 정리, 리팩터링, 사용성 및 신뢰성 향상
  • Huge-Page 할당기 개선: 투명한 Hugepage(THP)를 활용해 CPU 효율성 향상
  • 메모리 효율성 강화: 패킹, 캐싱, 퍼징 메커니즘 개선으로 최적화된 메모리 사용 달성
  • AArch64(ARM64) 최적화: 기본 설정만으로도 우수한 성능을 제공하도록 개선

커뮤니티와의 협력 강화

  • 메타는 행동을 통한 신뢰 구축을 강조하며, jemalloc의 건강한 발전을 목표로 함
  • 커뮤니티의 피드백과 참여를 환영하며, 함께 jemalloc의 미래를 만들어가기를 기대함
  • 오픈소스 생태계 내에서 지속 가능한 협력과 발전을 추진함
▲
GN⁺ 14시간전  [-]
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 소속일 가능성이 있음
답변달기