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 소속일 가능성이 있음