- El asignador de memoria de alto rendimiento jemalloc ha sido un componente fundamental que ha servido como infraestructura clave dentro del stack de software de Meta, junto con el kernel de Linux y los compiladores
- En los últimos años, al alejarse gradualmente de los principios de ingeniería centrales que habían guiado el desarrollo de jemalloc, se acumuló deuda técnica y el progreso se ralentizó
- Tras escuchar los comentarios de la comunidad y dialogar con integrantes del proyecto, incluido su fundador Jason Evans, el repositorio open source original fue reactivado (unarchived)
- En adelante, el enfoque estará en limpiar la deuda técnica, mejorar el asignador de Huge Pages, aumentar la eficiencia de memoria y optimizar para AArch64
- Meta reafirma su stewardship de largo plazo sobre jemalloc y cambia su rumbo para hacer avanzar el proyecto en colaboración con la comunidad
La posición e importancia de jemalloc
- jemalloc es un asignador de memoria de alto rendimiento que de forma constante ha ofrecido un alto impacto dentro del stack de software de Meta
- Se ha adaptado continuamente a los cambios de hardware y del software en capas superiores, y junto con el kernel de Linux y los compiladores ha contribuido a la estabilidad y el rendimiento de la infraestructura de Meta
Desviación de los principios y reflexión
- Los componentes de software base requieren el más alto nivel de rigor entre la practicidad y los principios
- Debido al alto impacto que ofrece jemalloc, existe la tentación de perseguir beneficios de corto plazo, y para resistirla se necesita una fuerte autodisciplina a nivel organizacional
- En los últimos años se produjo una desviación gradual de los principios de ingeniería centrales que guiaban el desarrollo de jemalloc
- Algunas decisiones ofrecieron beneficios inmediatos, pero la deuda técnica resultante obstaculizó el progreso
- Se tomaron en serio los comentarios de la comunidad y se realizaron encuentros con miembros de la comunidad, incluido el fundador del proyecto, Jason Evans
- Hubo una reflexión profunda sobre el impacto que la stewardship había tenido en la salud de largo plazo de jemalloc, y se compartió un cambio de enfoque
- Se inició el trabajo para eliminar la deuda técnica y reconstruir una hoja de ruta de largo plazo para jemalloc
Un nuevo capítulo: desarchivo del repositorio y planes a futuro
- Como resultado del diálogo con la comunidad, el repositorio open source original de jemalloc fue reactivado (unarchived)
- Esto permitió que Meta continúe en su papel de steward del proyecto, con un enfoque en reducir la carga de mantenimiento y modernizar la base de código
- Limpieza de deuda técnica: mantenerlo eficiente, confiable y fácil de usar para todos los usuarios mediante refactorizaciones y mejoras
- Asignador de Huge Pages (HPA): mejorar el aprovechamiento de Transparent Hugepages (THP) para aumentar la eficiencia de CPU
- Eficiencia de memoria: optimizar la eficiencia de memoria mediante mejoras en los mecanismos de packing, caching y purging
- Optimización para AArch64: garantizar un buen rendimiento predeterminado en plataformas ARM64
Mayor colaboración con la comunidad
- Meta enfatiza la construcción de confianza mediante acciones y apunta a un desarrollo saludable de jemalloc
- Da la bienvenida a la retroalimentación y participación de la comunidad, y espera construir juntos el futuro de jemalloc
- Impulsará una colaboración y evolución sostenibles dentro del ecosistema open source
1 comentarios
Comentarios en Hacker News
Cuando trabajaba en Facebook, mantuvo un parche del kernel para mejorar el mecanismo de purging de jemalloc
No era popular en la comunidad del kernel ni en la de seguridad, pero en los benchmarks mostraba buena eficiencia
El problema era que al reasignar memoria a otro hilo ocurría zeroing, lo que afectaba la localidad de caché y el rendimiento
Era una operación innecesaria cuando la memoria se reutilizaba dentro del mismo dominio de seguridad, pero era difícil llegar a un acuerdo sobre hasta dónde definir un “dominio de seguridad”
La discusión relacionada está en la lista de correo del kernel de Linux
En HHVM hicieron benchmarks extensivos antes y después de aplicar ese parche, pero a nivel de sistema no hubo una diferencia estadísticamente significativa
Puede que en algunos microbenchmarks sí hubiera mejoras, pero como no impactaba el rendimiento del sistema completo, quedó fuera del kernel
Hace poco usaron mimalloc de Microsoft con LD_PRELOAD para aprovechar huge pages de 1 GB
Obtuvieron alrededor de un 20% de mejora de rendimiento en un programa intensivo en memoria
Se siente curioso mejorar el rendimiento en Linux usando una librería open source de MS
Sienten que hace falta más competencia en el espacio de malloc
Eran aplicaciones escritas en Rust y la mayoría estaban enlazadas estáticamente
Por ejemplo, en app1 tcmalloc mostró una reducción de 35% en RSS y una disminución de 30% en tiempo de procesamiento frente a glibc
Todos los resultados se probaron con base en el repositorio de tcmalloc
Incluso Turbo Pascal ofrecía una API para definir directamente el asignador de memoria
Al final, el enfoque de “one size fits all” ya mostraba sus límites desde hace mucho
Se creaba un pool por cada solicitud y, al terminar la solicitud, se liberaba todo de una sola vez
Creo que malloc todavía tiene mucho margen para evolucionar en esa dirección
Si el patrón de asignación es simple, puede dar mejores resultados incluso que un malloc de terceros
Se suele ver malloc como una caja negra mágica, pero en realidad no es tan extraordinario
Nuestro equipo migró de glibc malloc a jemalloc hace dos años
En servicios de Python, el uso de memoria bajó entre 15% y 20%
Eso sí, en entornos de contenedores fue importante ajustar oversize_threshold — si se configura mal, provoca OOM
Me pregunto si hay benchmarks que comparen jemalloc y mimalloc en servicios de larga ejecución
Como lecturas relacionadas, recomiendan Jemalloc Postmortem y
Jemalloc Repositories Are Archived
Me pregunto si este cambio tendrá que ver con una escasez global de memoria
Podrían salir cálculos del tipo “cambiar el asignador de memoria ahorra millones de dólares al año”
Con apenas 0.1% de mejora en eficiencia podían ahorrar 100 mil dólares al mes
Los principales ahorros venían del costo de enfriamiento (HVAC) y de comprar menos servidores
Ahora el ahorro de memoria también es un tema importante, pero en ese momento no lo era
Si afecta a miles de servidores, incluso una mejora pequeña se traduce en cifras grandes
Esa cultura de mejora cuantitativa está bien arraigada ahí
Con solo 10% más de velocidad ya se puede ganar ventaja en la competencia de los LLM
Los incentivos para mejorar el rendimiento son enormes
En Australia despidieron a alguien que trabajaba en programación de bajo nivel
Le encanta resolver este tipo de problemas, pero le decepciona que el mercado local esté mayormente enfocado en React CRUD
En un proyecto startup financiado por el Banco Mundial desplegaron Ruby + jemalloc en producción
La velocidad y la eficiencia de memoria mejoraron de forma notable, lo que redujo mucho los costos en AWS
Fue hace 8 años, y aun así se preguntan por qué jemalloc todavía no se ha vuelto el estándar
Cambiar un sistema que ya está en operación no es fácil, incluso cuando el beneficio parece claro
También hay un caso en el que usaron jemalloc para rastrear la causa de una fuga de memoria
Ver la entrada del blog técnico de GOV.UK
Meta fusionó en gran escala trabajo que venía haciendo en su propio fork
Se puede revisar en PR #2863
Me pregunto si existe algún material que ordene la línea de tiempo o la historia de jemalloc
Como es un proyecto open source, llama la atención por qué Meta tiene tanto control sobre él
Ver el blog Jemalloc Postmortem
Las otras 2 también podrían pertenecer a Meta de forma no pública