# 메타, jemalloc에 대한 새로운 투자와 오픈소스 협력 강화 > Clean Markdown view of GeekNews topic #27585. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27585](https://news.hada.io/topic?id=27585) - GeekNews Markdown: [https://news.hada.io/topic/27585.md](https://news.hada.io/topic/27585.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-03-17T14:33:12+09:00 - Updated: 2026-03-17T14:33:12+09:00 - Original source: [engineering.fb.com](https://engineering.fb.com/2026/03/02/data-infrastructure/investing-in-infrastructure-metas-renewed-commitment-to-jemalloc/) - Points: 2 - Comments: 1 ## Topic Body - 고성능 메모리 할당자 **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의 미래를 만들어가기를 기대함 - 오픈소스 생태계 내에서 **지속 가능한 협력과 발전**을 추진할 것 ## Comments ### Comment 53216 - Author: neo - Created: 2026-03-17T14:33:12+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47402640) - Facebook 재직 시절, jemalloc의 **purging 메커니즘**을 개선하기 위해 커널 패치를 유지보수했음 커널이나 보안 커뮤니티에서는 인기가 없었지만, 벤치마크에서는 효율이 높았음 문제는 메모리를 다른 스레드로 재할당할 때 **zeroing**이 발생해 캐시 지역성과 성능에 영향을 주는 점이었음 같은 보안 도메인 내에서 메모리를 재활용할 때는 불필요한 동작이었지만, ‘보안 도메인’을 어디까지로 정의할지 합의가 어려웠음 관련 논의는 [Linux Kernel 메일링 리스트](https://marc.info/?l=linux-kernel&m=132691299630179&w=2)에 있음 - 아직도 그 패치를 언급하는 게 놀라움 HHVM에서 해당 패치 적용 전후로 **광범위한 벤치마크**를 했지만, 시스템 수준에서는 통계적으로 유의미한 차이가 없었음 일부 마이크로벤치마크에서는 개선이 있었겠지만, 전체 시스템 성능에는 영향이 없었기에 커널에서 제외되었음 - 어떤 **지표(metric)** 가 개선되었는지 궁금함 - cgroup 내에서라면 프로세스 간 메모리 내용이 새어도 괜찮다고 보는 건 위험한 생각처럼 들림 - 최근 Microsoft의 **mimalloc**을 LD_PRELOAD로 사용해 1GB **huge page**를 활용했음 메모리 집약적인 프로그램에서 약 20%의 성능 향상을 얻었음 Linux에서 오픈소스 MS 라이브러리를 써서 성능을 높이는 게 묘한 기분임 malloc 영역에 더 많은 경쟁이 필요하다고 느낌 - 여러 **allocator**를 테스트했는데, 최신 tcmalloc이 시간과 메모리 모두에서 가장 좋은 결과를 보였음 Rust로 작성된 앱들이었고, 대부분 정적으로 링크했음 예를 들어 app1에서는 glibc 대비 tcmalloc이 RSS 35% 절감, 처리 시간 30% 단축을 보였음 전체 결과는 [tcmalloc 저장소](https://github.com/google/tcmalloc/tree/24b3f29) 기준으로 테스트했음 - 예전에는 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](https://news.ycombinator.com/item?id=44264958)과 [Jemalloc Repositories Are Archived](https://news.ycombinator.com/item?id=44161128)을 추천함 - 혹시 이번 변화가 **글로벌 메모리 부족** 때문인지 궁금함 “메모리 할당기 교체로 연간 수백만 달러 절감” 같은 계산이 나올 수도 있음 - Facebook은 10년 전부터 이런 **미세 최적화로 수익 절감**을 추구했음 0.1% 효율 향상만으로도 월 10만 달러 절감이 가능했음 주된 절감 요인은 냉각비용(HVAC)과 서버 구매 감소였음 지금은 메모리 절감도 큰 이슈지만, 그때는 아니었음 - 단순히 비용뿐 아니라, **메모리 공급 지연**을 상쇄하기 위한 효율 개선도 중요함 - Meta에서는 수백만 달러 규모의 절감을 찾는 게 흔한 일임 수천 대 서버에 영향을 주면 작은 개선도 큰 숫자로 보임 이런 **정량적 개선 문화**가 자리 잡혀 있음 - 그 회사의 평판을 생각하면, 단순한 메모리 부족 이상의 **복잡한 사정**이 있을 수도 있음 - LLM, 전력, 서버 메모리 효율이 점점 더 중요해지는 시점임 10%만 빨라져도 LLM 경쟁에서 우위를 점할 수 있음 성능 개선의 **인센티브**가 매우 큼 - 호주에서 저수준 프로그래밍을 하던 중 **정리해고**를 당했음 이런 문제를 푸는 걸 정말 좋아하지만, 현지 시장은 대부분 React CRUD 위주라 아쉬움 - AU에서 **저수준 데이터 처리** 관련 채용 중임. bio에 링크 있음 - 나도 호주에서 React CRUD만 하며 같은 생각을 했음 - 원격 근무를 찾는다면 [Igalia 채용 페이지](https://www.igalia.com/jobs/open/)가 흥미로울 수 있음 - **HFT 회사(IMC trading)** 도 이런 저수준 최적화 업무를 많이 하며, 현재 호주에서 채용 중임 - **SIG**도 시드니에서 관련 포지션을 모집 중임: [SIG Careers](https://careers.sig.com/global-experienced) - World Bank 자금으로 진행된 스타트업 프로젝트에서 **Ruby + jemalloc**을 프로덕션에 배포했음 속도와 메모리 효율이 눈에 띄게 개선되어 AWS 비용을 크게 절감했음 8년 전 일인데, 왜 아직도 jemalloc이 표준으로 자리 잡지 못했는지 의문임 - 대부분은 단순히 **정보 부족** 혹은 **관성** 때문임 이미 운영 중인 시스템을 바꾸는 건, 이득이 명확해도 쉽지 않음 - jemalloc을 이용해 **메모리 누수 원인**을 추적한 사례도 있음 [GOV.UK 기술 블로그 글](https://technology.blog.gov.uk/2015/12/11/using-jemalloc-to-get-to-the-bottom-of-a-memory-leak/) 참고 - Meta가 자체 포크에서 작업하던 내용을 대규모로 병합함 [PR #2863](https://github.com/jemalloc/jemalloc/pull/2863)에서 확인 가능함 - jemalloc의 **타임라인이나 역사**가 정리된 자료가 있는지 궁금함 오픈소스 프로젝트인데 왜 Meta가 주도권을 쥐고 있는지 의문임 - 창시자 **Jason Evans**가 작년에 전체 경위를 정리함 [Jemalloc Postmortem 블로그](https://jasone.github.io/2025/06/12/jemalloc-postmortem/) 참고 - 최근 5년간 커밋을 보면 상위 6명 중 4명이 Meta 직원임 나머지 2명도 비공개로 Meta 소속일 가능성이 있음