Khi chạy Docker Compose cho một dev stack gồm PostgreSQL, Redis, API và Frontend trên laptop 16GB RAM, bạn sẽ nhanh chóng nhận ra giới hạn hiệu năng so với cấu hình 32GB RAM. Đặc biệt, nếu muốn tận dụng máy để chạy thêm các mô hình ngôn ngữ lớn (LLM) phục vụ coding offline, việc tối ưu là bắt buộc. Theo bài viết từ TechnologySpot, mô hình 7B Q4 cần khoảng 4-6GB RAM cho weight, trong khi 13B Q4 ngốn từ 8-10GB RAM. Trên cấu hình 16GB, chạy đồng thời cả dev stack lẫn LLM chắc chắn sẽ gây tràn RAM sang ổ cứng (swap), khiến tốc độ xử lý và phản hồi của hệ thống giảm mạnh.
Để hỗ trợ chạy LLM offline qua GPU tích hợp đời mới như Intel Arc 140V (đạt 4047 điểm Time Spy theo benchmark từ NotebookCheck), hệ thống sẽ sử dụng shared memory lấy trực tiếp từ RAM chính của laptop. Khi dev stack của bạn chiếm dụng khoảng 3-4GB RAM (bao gồm overhead của Docker), hệ điều hành và các tab trình duyệt ngốn thêm 5-6GB, lượng RAM trống còn lại cực kỳ ít ỏi. Do đó, việc giới hạn tài nguyên nghiêm ngặt cho từng service trong Docker Compose là điều kiện bắt buộc để ngăn chặn tình trạng tràn RAM và crash máy đột ngột.
Tối ưu tài nguyên với Docker Compose
Dưới đây là cấu hình docker-compose.yml tối giản có giới hạn tài nguyên (limits) và cơ chế healthcheck để tối ưu hóa bộ nhớ trên máy 16GB RAM:
version: '3.8'
services:
db:
image: postgres:15-alpine
environment:
POSTGRES_PASSWORD: local_password
deploy:
resources:
limits:
cpus: '1.0'
memory: 512M
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres"]
interval: 5s
timeout: 5s
retries: 5
redis:
image: redis:alpine
deploy:
resources:
limits:
cpus: '0.5'
memory: 256M
api:
image: node:18-alpine
command: npm run dev
volumes:
- .:/app
- node_modules:/app/node_modules
ports:
- "3000:3000"
depends_on:
db:
condition: service_healthy
deploy:
resources:
limits:
cpus: '1.5'
memory: 1G
volumes:
node_modules:
Khắc phục lỗi file watcher chậm trên WSL2
Một vấn đề thực tế vô cùng phổ biến khi lập trình bằng Docker trên môi trường Windows là file watcher (như Webpack, Vite hot-reload) hoạt động cực kỳ chậm hoặc hoàn toàn không nhận diện được sự thay đổi của mã nguồn khi sử dụng cơ chế bind mount trực tiếp từ host Windows vào container thông qua WSL2. Nguyên nhân cốt lõi là do độ trễ đồng bộ file rất lớn giữa định dạng NTFS của Windows và ext4 của hệ điều hành Linux trong WSL2 qua mount point /mnt/c.
Cách khắc phục tối ưu nhất là sử dụng named volume cho các thư mục chứa dữ liệu tĩnh hoặc file thư viện phụ thuộc nặng như node_modules (như cách khai báo node_modules:/app/node_modules trong compose file ở trên). Kỹ thuật này giúp Docker ghi đè đường dẫn mount bằng một volume độc lập lưu trữ trực tiếp bên trong hệ điều hành ảo của WSL2, giải phóng I/O và khôi phục tốc độ phản hồi tức thì cho file watcher.
Bài viết là bản tóm tắt kỹ thuật. Xem chi tiết bài phân tích hiệu năng RAM tại TechnologySpot.
Top comments (0)