Đừng dùng musl nếu bạn quan tâm đến hiệu năng

Nhiều lập trình viên Rust thường chọn musl để tạo binary tĩnh chạy mọi nơi, nhưng một bài phân tích gần đây cho thấy cái giá phải trả về hiệu năng là rất lớn. Bộ cấp phát bộ nhớ của musl hoạt động kém đến mức bất ngờ, ngay cả khi thay thế bằng mimalloc, hệ thống vẫn chậm hơn glibc tới 26%. Đây là một cái bẫy nguy hiểm mà không phải ai cũng nhận ra khi lựa chọn thư viện chuẩn cho dự án của mình.

Tác giả bài viết, một kỹ sư từng làm việc nhiều năm với JVM và Python, đã chia sẻ trải nghiệm thực tế khi gặp lỗi tương thích libc trong container và được GPT gợi ý dùng musl. Từ đó, anh chuyển toàn bộ dự án Rust sang musl với hy vọng có được binary tự chứa hoàn hảo — nhưng nhanh chóng nhận ra sai lầm khi đồng nghiệp cảnh báo về hiệu năng của bộ cấp phát trong musl.

Bộ cấp phát của musl: Tệ hơn cả mong đợi

Sau khi đo đạc trên các máy ảo EC2 4 nhân (đúng cấu hình mà Bifrost — một dự án Rust — sử dụng), tác giả phát hiện bộ cấp phát mặc định của musl có hiệu năng rất kém. Điều đáng chú ý là vấn đề không chỉ xuất hiện ở các tình huống đa luồng cao như nhiều bài viết trước đó từng đề cập, mà ngay cả với tải bình thường.

"Đây là một cái bẫy thực sự tệ nếu để người dùng vô tình dính phải. Tôi nghĩ musl nên được phân phối mà không kèm bộ cấp phát, buộc người dùng phải tự chọn."

Tác giả cũng đề xuất rằng nếu người dùng vẫn muốn chọn bộ cấp phát kém (có lẽ vì mã nguồn nhỏ gọn), đó nên là quyết định có ý thức, thay vì mặc định gây hại mà không ai cảnh báo trước.

mimalloc không phải là phép màu

Nhiều người khuyên thay thế bộ cấp phát mặc định của musl bằng mimalloc hoặc jemalloc. Tuy nhiên, đo đạc thực tế cho thấy ngay cả khi dùng mimalloc, hiệu năng của musl vẫn chậm hơn glibc 26%. Điều này cho thấy vấn đề không chỉ nằm ở bộ cấp phát mà còn ở các hàm thư viện chuẩn khác.

Biểu đồ so sánh tổng thời gian chạy giữa glibc và musl

Phân tích chi tiết hai loại tác vụ có suy giảm nặng nhất trong Bifrost:

• scan_usages: Có nhận được lợi ích từ mimalloc, nhưng vẫn chậm hơn so với glibc.
• structural_clone_smells: Hầu như không cấp phát bộ nhớ, nhưng vẫn bị ảnh hưởng nặng bởi musl.

Điều thú vị là tác vụ structural_clone_smells hầu như không cấp phát bộ nhớ nhưng vẫn bị chậm hơn nhiều trên musl — cho thấy các hàm thư viện chuẩn khác như memcpy, memcmp hay so sánh chuỗi cũng có vấn đề về hiệu năng.

Cơ chế hoạt động của mimalloc trên musl

Sự đơn giản không bao giờ là miễn phí

Dù vậy, tác giả vẫn thừa nhận rằng việc dùng musl mang lại sự đơn giản đáng kể: binary tự chứa, không cần phụ thuộc vào libc của hệ điều hành, dễ dàng triển khai trong container nhẹ hoặc môi trường hạn chế tài nguyên.

Với các dự án nhỏ, nơi chậm 25% không quan trọng (như dự án Hel), tác giả vẫn sẽ giữ musl kèm mimalloc để đổi lấy sự tiện lợi. Nhưng với Bifrost — ứng dụng nhạy cảm về hiệu năng — quyết định đã rõ ràng: loại bỏ musl khỏi danh sách prebuilt và quay lại với glibc.

Phân tích chi tiết các primitive bộ nhớ trên musl

Lời khuyên cho lập trình viên Việt Nam

Với xu hướng phát triển microservices và serverless ngày càng tăng tại Việt Nam, việc chọn đúng thư viện chuẩn là vô cùng quan trọng. Nếu bạn đang phát triển ứng dụng Rust cho production, đặc biệt là các dịch vụ xử lý dữ liệu lớn, API trực tiếp phục vụ người dùng, hoặc hệ thống realtime — hãy kiểm tra kỹ hiệu năng của musl trước khi chọn.

Một số lưu ý nhanh:

• Nếu cần binary tĩnh cho container nhẹ, hãy cân nhắc dùng glibc với image gcr.io/distroless hoặc multi-stage build phù hợp.
• Nếu bắt buộc phải dùng musl, hãy thay bộ cấp phát bằng mimalloc hoặc jemalloc ngay từ đầu.
• Luôn benchmark trên cấu hình máy thực tế dự kiến triển khai, không nên tin vào lời khuyên chung chung trên mạng.

Cuối cùng, hãy nhớ rằng không có giải pháp nào là miễn phí. Sự đơn giản của musl đến từ việc đánh đổi hiệu năng — và nếu bạn không sẵn sàng trả cái giá đó, hãy tránh xa nó.