Ổ cứng nghẽn 4K random khiến Docker build chậm dù trúng cache

Tại sao tiến trình Docker build vẫn ì ạch dù mọi layer đều trả về trạng thái CACHED?

Nhiều lập trình viên vội vã đổ lỗi cho xung nhịp CPU hoặc Docker daemon, nhưng nút thắt cổ chai thực tế thường nằm ở hiệu năng đọc ghi ngẫu nhiên (random I/O) của ổ SSD.

Cơ chế Layer Cache và độ trễ giải nén trên SSD

Khi thực thi docker pull hoặc build image, Docker xử lý khối lượng lớn file nhỏ phân tán. Với mỗi layer cần tạo mới hoặc kiểm tra tính toàn vẹn, storage driver (như Overlay2) phải quét metadata, uncompress các tệp tarball và ghi hàng chục nghìn file vào disk. Quá trình này tạo áp lực cực lớn lên chỉ số 4K random write.

Nếu ổ SSD có IOPS thấp hoặc cạn bộ đệm SLC, thời gian trích xuất layer sẽ kéo dài, triệt tiêu toàn bộ lợi thế về tốc độ tải mạng. Theo đánh giá kỹ thuật từ reviewlaptop.vn, những lỗi ngoại quan như màn hình tì đè hay loang màu hoàn toàn không làm suy giảm điểm Cinebench, Geekbench hay tốc độ xử lý của phần cứng; thế nhưng một ổ cứng suy giảm chất lượng hoặc phân vùng I/O quá tải sẽ trực tiếp bóp nghẹt toàn bộ môi trường container.

Đo lường Bind Mount và Named Volume bằng fio

Độ trễ I/O bộc lộ rõ nhất khi so sánh giữa Bind Mount và Named Volume. Việc mount trực tiếp thư mục mã nguồn chứa hàng chục nghìn file tĩnh (như node_modules hoặc cache package) qua bind mount buộc hệ thống chịu chi phí đồng bộ hóa filesystem liên tục giữa host và container.

Để đo đạc thông lượng thực tế ngay trong container, developer dùng công cụ fio:

# Benchmark 4K random read trên volume container
fio --name=docker-io --rw=randread --bs=4k --size=512M --direct=1 --runtime=30 --ioengine=libaio --iodepth=16 --filename=/test_io

Thực tế vận hành cho thấy Named Volume luôn cho độ trễ thấp hơn và IOPS vượt trội do ghi trực tiếp vào phân vùng nội bộ của Docker engine (/var/lib/docker/volumes), không phải đi qua lớp cầu nối filesystem của hệ điều hành host.

Khuyến nghị kỹ thuật

• Ưu tiên Named Volume: Chuyển các thư mục phát sinh I/O dày đặc như node_modules, log và database files vào Named Volume; chỉ dùng Bind Mount cho source code cần chỉnh sửa trực tiếp.
• Tối ưu layer trong Dockerfile: Sắp xếp các chỉ thị ít thay đổi lên đầu, gộp các lệnh RUN apt-get để giảm số lượng layer trung gian và hạn chế phân mảnh I/O.
• Dọn dẹp định kỳ: Sử dụng docker system prune --volumes nhằm thu hồi dung lượng và giảm tải chỉ mục cho storage driver.

Đừng vội nâng cấp RAM hay đổi CPU khi thấy container phản hồi chậm; hãy kiểm tra tốc độ random 4K của SSD và chuyển đổi cấu hình volume mount trước tiên.