- jemalloc, một trình cấp phát bộ nhớ hiệu năng cao, đã là thành phần nền tảng đóng vai trò hạ tầng cốt lõi trong ngăn xếp phần mềm của Meta, cùng với Linux kernel và compiler
- Trong vài năm gần đây, dự án dần lệch khỏi các nguyên tắc kỹ thuật cốt lõi từng dẫn dắt quá trình phát triển jemalloc, khiến nợ kỹ thuật tích tụ và làm chậm tiến độ
- Sau khi tiếp nhận phản hồi từ cộng đồng và thảo luận với các thành viên, bao gồm nhà sáng lập dự án Jason Evans, kho mã nguồn mở gốc đã được kích hoạt lại (unarchived)
- Kế hoạch sắp tới sẽ tập trung vào việc xử lý nợ kỹ thuật, cải thiện Huge-Page allocator, nâng cao hiệu quả bộ nhớ và tối ưu hóa AArch64
- Meta tái khẳng định vai trò stewardship dài hạn đối với jemalloc và chuyển hướng sang phát triển dự án thông qua hợp tác với cộng đồng
Vị trí và tầm quan trọng của jemalloc
- jemalloc là một trình cấp phát bộ nhớ hiệu năng cao, là thành phần luôn mang lại đòn bẩy lớn trong ngăn xếp phần mềm của Meta
- Dự án đã liên tục thích nghi với các thay đổi của phần cứng và phần mềm ở lớp trên, đồng thời góp phần vào tính ổn định và hiệu năng của hạ tầng Meta cùng với Linux kernel và compiler
Sự lệch khỏi nguyên tắc và quá trình nhìn lại
- Các thành phần phần mềm nền tảng đòi hỏi mức độ nghiêm ngặt cao nhất giữa tính thực dụng và nguyên tắc
- Vì jemalloc mang lại đòn bẩy rất lớn, luôn tồn tại cám dỗ theo đuổi lợi ích ngắn hạn; để từ chối điều đó cần có kỷ luật tự thân mạnh mẽ ở cấp độ tổ chức
- Trong vài năm gần đây đã xuất hiện sự lệch dần khỏi các nguyên tắc kỹ thuật cốt lõi từng dẫn dắt quá trình phát triển jemalloc
- Một số quyết định mang lại lợi ích tức thời, nhưng nợ kỹ thuật phát sinh từ đó đã cản trở tiến độ
- Meta đã nghiêm túc tiếp nhận phản hồi từ cộng đồng và tổ chức gặp gỡ với các thành viên cộng đồng, bao gồm nhà sáng lập dự án Jason Evans
- Công ty đã suy ngẫm sâu sắc về tác động của stewardship đối với sức khỏe dài hạn của jemalloc và chia sẻ sự thay đổi trong cách tiếp cận
- Đồng thời bắt tay vào việc loại bỏ nợ kỹ thuật và xây dựng lại lộ trình dài hạn cho jemalloc
Chương mới: bỏ trạng thái lưu trữ kho mã và kế hoạch sắp tới
- Kết quả của đối thoại với cộng đồng là kho mã nguồn mở jemalloc ban đầu đã được kích hoạt lại (unarchived)
- Điều này cho phép Meta tiếp tục giữ vai trò steward của dự án, đồng thời tập trung vào việc giảm gánh nặng bảo trì và hiện đại hóa codebase
- Xử lý nợ kỹ thuật: duy trì trạng thái hiệu quả, đáng tin cậy và dễ sử dụng cho mọi người dùng thông qua refactor và cải tiến
- Huge-Page allocator (HPA): tận dụng Transparent Hugepages (THP) tốt hơn để nâng cao hiệu quả CPU
- Hiệu quả bộ nhớ: tối ưu hiệu quả sử dụng bộ nhớ thông qua cải thiện các cơ chế packing, caching và purging
- Tối ưu hóa AArch64: bảo đảm hiệu năng tốt theo mặc định trên nền tảng ARM64
Tăng cường hợp tác với cộng đồng
- Meta nhấn mạnh xây dựng niềm tin bằng hành động và hướng đến sự phát triển lành mạnh của jemalloc
- Công ty hoan nghênh phản hồi và sự tham gia từ cộng đồng, đồng thời kỳ vọng cùng nhau định hình tương lai của jemalloc
- Sẽ thúc đẩy hợp tác và phát triển bền vững trong hệ sinh thái mã nguồn mở
1 bình luận
Ý kiến trên Hacker News
Khi còn làm ở Facebook, có người đã duy trì một bản vá kernel để cải thiện cơ chế purging của jemalloc
Bản vá này không được cộng đồng kernel hay bảo mật ưa chuộng, nhưng trong benchmark thì cho hiệu quả cao
Vấn đề là khi cấp phát lại bộ nhớ cho một luồng khác thì xảy ra zeroing, ảnh hưởng đến tính cục bộ của cache và hiệu năng
Đây là thao tác không cần thiết khi tái sử dụng bộ nhớ trong cùng một miền bảo mật, nhưng rất khó đạt được đồng thuận về việc nên định nghĩa “miền bảo mật” đến đâu
Thảo luận liên quan có trong Linux Kernel mailing list
Họ đã chạy benchmark trên diện rộng cho HHVM trước và sau khi áp dụng bản vá đó, nhưng ở cấp độ toàn hệ thống thì không có khác biệt có ý nghĩa thống kê
Có thể một số microbenchmark có cải thiện, nhưng vì không ảnh hưởng đến hiệu năng toàn hệ thống nên nó đã bị loại khỏi kernel
Gần đây có người dùng mimalloc của Microsoft qua LD_PRELOAD để tận dụng huge page 1GB
Họ đạt được mức tăng hiệu năng khoảng 20% với các chương trình ngốn nhiều bộ nhớ
Dùng một thư viện MS mã nguồn mở trên Linux để tăng hiệu năng tạo cảm giác khá lạ
Cảm giác là lĩnh vực malloc cần thêm cạnh tranh
Các ứng dụng đều được viết bằng Rust, và phần lớn được liên kết tĩnh
Ví dụ với app1, tcmalloc giảm RSS 35% và rút ngắn thời gian xử lý 30% so với glibc
Toàn bộ kết quả được kiểm thử dựa trên kho tcmalloc
Ngay cả Turbo Pascal cũng cung cấp API để tự định nghĩa memory allocator
Rốt cuộc cách tiếp cận “one size fits all” từ lâu đã có giới hạn
Mỗi request tạo một pool, rồi khi request kết thúc thì giải phóng toàn bộ chỉ trong một lần
Có cảm giác malloc vẫn còn nhiều dư địa để tiến hóa theo hướng này
Nếu mẫu cấp phát đơn giản, kết quả thậm chí có thể tốt hơn dùng malloc bên thứ ba
Người ta hay xem malloc như một hộp đen thần kỳ, nhưng thực ra nó không xuất sắc đến vậy
Nhóm của họ đã chuyển từ glibc malloc sang jemalloc cách đây 2 năm
Mức sử dụng bộ nhớ trong các dịch vụ Python giảm 15~20%
Tuy vậy, trong môi trường container thì việc điều chỉnh oversize_threshold là rất quan trọng — đặt sai có thể gây OOM
Họ tò mò liệu có benchmark nào so sánh jemalloc và mimalloc trên các dịch vụ chạy lâu dài hay không
Có thể tham khảo thêm Jemalloc Postmortem và
Jemalloc Repositories Are Archived
Có người tự hỏi liệu thay đổi lần này có phải vì tình trạng thiếu bộ nhớ toàn cầu hay không
Kiểu tính toán như “đổi memory allocator để tiết kiệm hàng triệu USD mỗi năm” hoàn toàn có thể xuất hiện
Chỉ cần cải thiện hiệu suất 0.1% là đã có thể tiết kiệm 100.000 USD mỗi tháng
Nguồn tiết kiệm chính khi đó đến từ chi phí làm mát (HVAC) và giảm mua máy chủ
Hiện nay tiết kiệm bộ nhớ cũng là vấn đề lớn, nhưng hồi đó thì chưa phải vậy
Nếu tác động đến hàng nghìn máy chủ, thì một cải tiến nhỏ cũng sẽ thành con số rất lớn
Có hẳn một văn hóa cải thiện định lượng như vậy
Chỉ cần nhanh hơn 10% thôi cũng có thể tạo lợi thế trong cuộc cạnh tranh LLM
Động lực cho các cải tiến hiệu năng là cực kỳ lớn
Có người bị sa thải khi đang làm lập trình cấp thấp ở Australia
Họ thực sự thích giải những bài toán như thế này, nhưng thị trường địa phương phần lớn chỉ xoay quanh React CRUD nên khá tiếc nuối
Trong một dự án startup được tài trợ bằng vốn của World Bank, có người đã triển khai Ruby + jemalloc lên production
Tốc độ và hiệu quả bộ nhớ được cải thiện rõ rệt, giúp cắt giảm đáng kể chi phí AWS
Đó là chuyện từ 8 năm trước, nên họ thắc mắc vì sao đến giờ jemalloc vẫn chưa trở thành tiêu chuẩn mặc định
Việc thay đổi một hệ thống đang chạy sẵn không hề dễ, kể cả khi lợi ích rất rõ ràng
Cũng có trường hợp dùng jemalloc để lần ra nguyên nhân rò rỉ bộ nhớ
Xem bài trên blog kỹ thuật GOV.UK
Meta đã hợp nhất trên quy mô lớn những gì họ từng làm trong fork nội bộ của mình
Có thể xem trong PR #2863
Có người muốn biết liệu có tài liệu nào tổng hợp timeline hay lịch sử của jemalloc hay không
Đây là dự án mã nguồn mở, nên họ thắc mắc vì sao Meta lại nắm vai trò chủ đạo
Xem blog Jemalloc Postmortem
2 người còn lại cũng có thể thuộc Meta nhưng không công khai