- O alocador de memória de alto desempenho jemalloc tem sido um componente fundamental que atua como infraestrutura central na stack de software da Meta, ao lado do kernel Linux e dos compiladores
- Nos últimos anos, houve um afastamento gradual dos princípios centrais de engenharia que guiavam o desenvolvimento do jemalloc, acumulando dívida técnica e desacelerando o progresso
- Após incorporar o feedback da comunidade e discutir com integrantes do projeto, incluindo seu fundador Jason Evans, o repositório original de código aberto foi reativado (unarchived)
- Daqui para frente, o foco será reduzir a dívida técnica, melhorar o alocador de Huge Pages, aumentar a eficiência de memória e otimizar para AArch64
- A Meta reafirma sua administração de longo prazo do jemalloc e muda sua direção para evoluir o projeto em colaboração com a comunidade
Posição e importância do jemalloc
- O jemalloc é um alocador de memória de alto desempenho e tem sido um componente que oferece alavancagem consistentemente alta na stack de software da Meta
- Ele tem se adaptado continuamente às mudanças de hardware e de software nas camadas superiores, contribuindo para a estabilidade e o desempenho da infraestrutura da Meta junto com o kernel Linux e os compiladores
Desvio dos princípios e reflexão
- Componentes fundamentais de software exigem o mais alto nível de rigor no equilíbrio entre pragmatismo e princípios
- Como o jemalloc oferece alta alavancagem, existe a tentação de buscar ganhos de curto prazo, e resistir a isso exige forte autodisciplina em nível organizacional
- Nos últimos anos, ocorreu um afastamento gradual dos princípios centrais de engenharia que orientavam o desenvolvimento do jemalloc
- Algumas decisões trouxeram benefícios imediatos, mas a dívida técnica resultante passou a dificultar o avanço
- A Meta levou a sério o feedback da comunidade e se reuniu com membros dela, incluindo o fundador do projeto, Jason Evans
- A empresa refletiu profundamente sobre o impacto de sua administração na saúde de longo prazo do jemalloc e compartilhou uma mudança de abordagem
- Também iniciou o trabalho de remover a dívida técnica e reconstruir um roadmap de longo prazo para o jemalloc
Um novo capítulo: reativação do repositório e planos futuros
- Como resultado do diálogo com a comunidade, o repositório original de código aberto do jemalloc foi reativado (unarchived)
- Isso permite que a Meta continue no papel de administradora do projeto, com foco em reduzir a carga de manutenção e modernizar a base de código
- Redução da dívida técnica: manter o projeto eficiente, confiável e fácil de usar para todos os usuários por meio de refatorações e melhorias
- Alocador de Huge Pages (HPA): melhor aproveitamento de Transparent Hugepages (THP) para aumentar a eficiência de CPU
- Eficiência de memória: otimização da eficiência de memória por meio de melhorias em mecanismos de empacotamento, cache e purging
- Otimização para AArch64: garantir bom desempenho por padrão em plataformas ARM64
Reforço da colaboração com a comunidade
- A Meta enfatiza a construção de confiança por meio de ações e busca o desenvolvimento saudável do jemalloc
- A empresa dá boas-vindas ao feedback e à participação da comunidade e espera construir em conjunto o futuro do jemalloc
- Também pretende promover colaboração e evolução sustentáveis dentro do ecossistema de código aberto
1 comentários
Comentários do Hacker News
Na época em que trabalhou no Facebook, manteve um patch de kernel para melhorar o mecanismo de purging do jemalloc
Ele não era popular na comunidade de kernel ou de segurança, mas mostrava boa eficiência nos benchmarks
O problema era que, ao realocar memória para outra thread, ocorria zeroing, o que afetava a localidade de cache e o desempenho
Ao reutilizar memória dentro do mesmo domínio de segurança, isso era uma operação desnecessária, mas era difícil chegar a um consenso sobre até onde definir o “domínio de segurança”
A discussão relacionada está na lista de e-mails do Linux Kernel
Foram feitos benchmarks extensivos no HHVM antes e depois de aplicar esse patch, mas no nível do sistema não houve diferença estatisticamente significativa
Pode ter havido melhora em alguns microbenchmarks, mas como não impactava o desempenho do sistema como um todo, ele foi removido do kernel
Recentemente usei o mimalloc da Microsoft via LD_PRELOAD para aproveitar huge pages de 1 GB
Obtive cerca de 20% de ganho de desempenho em um programa intensivo em memória
É uma sensação curiosa melhorar o desempenho no Linux usando uma biblioteca open source da MS
Sinto que falta mais concorrência no espaço de malloc
Eram apps escritos em Rust, e a maioria foi linkada estaticamente
Por exemplo, no app1, o tcmalloc mostrou redução de 35% no RSS e 30% menos tempo de processamento em comparação com o glibc
Os resultados completos foram testados com base no repositório do tcmalloc
Até o Turbo Pascal oferecia uma API para definir o próprio alocador de memória
No fim das contas, a abordagem “one size fits all” já mostrava seus limites há muito tempo
Criava-se um pool por requisição, e quando a requisição terminava, tudo era liberado de uma vez
Acho que ainda há bastante espaço para o malloc evoluir nessa direção
Se o padrão de alocação for simples, é possível obter resultados melhores do que com mallocs de terceiros
As pessoas tratam malloc como uma caixa-preta mágica, mas na prática ele não é tão extraordinário assim
Nossa equipe migrou do glibc malloc para o jemalloc há 2 anos
O uso de memória caiu de 15% a 20% em serviços Python
Mas, em ambiente de contêineres, ajustar o oversize_threshold foi importante — se configurado errado, ocorria OOM
Fico curioso se existe algum benchmark comparando jemalloc e mimalloc em serviços de longa duração
Como leitura relacionada, recomendo Jemalloc Postmortem e
Jemalloc Repositories Are Archived
Fico me perguntando se essa mudança tem a ver com uma escassez global de memória
Pode ser que apareçam contas do tipo “trocar o alocador de memória economiza milhões de dólares por ano”
Só 0,1% de ganho de eficiência já podia representar economia de US$ 100 mil por mês
Os principais fatores de economia eram custo de refrigeração (HVAC) e redução na compra de servidores
Hoje, economizar memória também é um grande tema, mas naquela época não era
Se impactar milhares de servidores, até uma melhoria pequena vira um número grande
Existe essa cultura de melhoria quantitativa
Ficar só 10% mais rápido já pode dar vantagem na corrida dos LLMs
O incentivo para melhorar desempenho é enorme
Enquanto fazia programação de baixo nível na Austrália, fui demitido
Gosto muito de resolver esse tipo de problema, mas é uma pena que o mercado local seja majoritariamente focado em React CRUD
Em um projeto de startup financiado pelo World Bank, colocamos Ruby + jemalloc em produção
Houve melhora perceptível em velocidade e eficiência de memória, reduzindo bastante os custos na AWS
Isso foi há 8 anos, e ainda assim fico me perguntando por que o jemalloc não virou padrão até hoje
Mudar um sistema que já está em produção não é fácil, mesmo quando o ganho é claro
Também há um caso de uso do jemalloc para rastrear a causa de um vazamento de memória
Veja o post do blog técnico do GOV.UK
A Meta fez um grande merge do que vinha desenvolvendo em seu próprio fork
Dá para conferir na PR #2863
Fico curioso se existe algum material que organize a linha do tempo ou a história do jemalloc
É um projeto open source, então por que a Meta parece ter tanto controle sobre ele?
Veja o blog Jemalloc Postmortem
Os outros 2 também podem ser da Meta de forma não pública