Chọn RAM và CPU cho n8n theo số workflow thực tế

Bạn vừa cài xong n8n trên VPS, workflow đầu tiên chạy ngon lành. Nhưng khi lên tới 5, 10 workflow, VPS bắt đầu thở dốc, RAM cạn dần, CPU load cao, webhook timeout. Câu hỏi quen thuộc: VPS bao nhiêu RAM và CPU là đủ để chạy n8n theo số workflow thực tế? Bài viết này sẽ cho bạn công thức chứ không phải phán đoán. Dựa vào số lượng workflow, tần suất chạy, chế độ queue và loại node, bạn sẽ biết chính xác mình cần cấu hình nào.

Yêu cầu trước khi bắt đầu

• VPS chạy Ubuntu 24.04 hoặc Debian 12 (khuyến nghị dùng thuê VPS Linux có full root).
• Đã cài Docker và Docker Compose v2.
• Hiểu cơ bản về workflow n8n: node, trigger, execution.
• Biết dùng docker stats và htop để theo dõi tài nguyên.

Vì sao RAM là yếu tố quyết định hơn CPU?

n8n chạy trên nền Node.js, một runtime đơn luồng. Điều này có nghĩa là một execution (quá trình chạy workflow) chỉ dùng một luồng CPU tại một thời điểm. CPU cao cấp (nhiều core) chỉ phát huy tác dụng khi nhiều execution chạy đồng thời, nhất là khi bật chế độ queue (Queue Mode) với nhiều worker. Còn RAM là thứ workflow ngốn trực tiếp: mỗi node trong workflow tải code, giữ biến, xử lý dữ liệu tạm, tất cả đều nằm trên RAM. Một workflow đơn giản (webhook → ghi file) có thể chỉ tốn 50-80 MB RAM, nhưng workflow phức tạp (gọi AI, xử lý file ảnh, query database nhiều bảng) có thể ngốn tới 300-500 MB cho một lần chạy.

Một thực tế mình từng gặp: chạy 3 workflow cron (mỗi giờ chạy một lần) trên VPS 1 GB RAM, ban đầu ổn. Nhưng khi cả 3 chạy đồng thời (cùng giờ), RAM đầy, n8n bắt đầu dùng swap, và workflow timeout hàng loạt. Vậy nên, nguyên tắc đầu tiên: RAM là bottleneck chính.

Bước 1 - Đo lường chính xác mức tiêu thụ RAM của workflow

Đừng phán đoán mù quáng. Hãy dùng docker stats để đo thực tế dung lượng RAM từng workflow đang chạy. Lệnh đơn giản:

docker stats --no-stream --format "table {{.Name}}\t{{.MemUsage}}\t{{.MemPerc}}"

Output bạn sẽ thấy kiểu:

NAME                                    MEM USAGE / LIMIT    MEM %
n8n-flow-webhook-db-1                   45.62MiB / 1.944GiB  2.29%
n8n-flow-ai-summary-1                   312.8MiB / 1.944GiB 16.11%
n8n-flow-cron-backup-1                  89.21MiB / 1.944GiB  4.58%

Ở đây, workflow "ai-summary" ngốn gấp 7 lần workflow đơn giản. Đây là dữ liệu sống để bạn quyết định nâng cấp hay tối ưu. Bạn nên ghi lại con số này vào lúc cao điểm (khi workflow chạy execution), vì lúc idle thì mức tiêu thụ rất thấp (chỉ 20-40 MB cho container n8n gốc).

Bước 2 - Công thức chọn RAM và CPU

Sau nhiều lần test với các loại workflow, mình đúc kết công thức thực tế như sau. Hãy xem nó như một điểm khởi đầu, sau đó tinh chỉnh dựa trên dữ liệu bạn đo được ở bước 1.

Công thức RAM tối thiểu

RAM cho 1 workflow ở đây đã tính cả phần overhead của container và service chạy nền. Ví dụ, bạn có 3 workflow đơn giản chạy webhook và 1 workflow AI phức tạp chạy cron mỗi giờ. Công thức: (3 x 150 MB) + (1 x 800 MB) = 1.25 GB RAM cho riêng workflow + 512 MB cho container n8n gốc và dependencies → tổng ~1.8 GB. Vậy VPS 2 GB RAM là đủ, nhưng gần sát ngưỡng. An toàn hơn: 4 GB RAM.

Công thức CPU

Một lưu ý: n8n không hỗ trợ đa luồng cho một execution riêng biệt. Vậy nên 1 vCPU là đủ cho mọi workflow nếu chúng chạy tuần tự. Nhưng thực tế, các webhook hay cron có thể kích hoạt đồng thời, lúc này nhiều vCPU hơn giúp giảm nghẽn cổ chai.

Bước 3 - Khi nào cần Queue Mode với Redis?

Queue Mode là tính năng tách riêng phần nhận request (web server) và phần chạy workflow (worker). Nó dùng Redis làm hàng đợi. Bạn nên bật Queue Mode khi:

• Có hơn 5 execution đồng thời thường xuyên.
• Workflow có thời gian chạy lâu (>30 giây) mà vẫn cần webhook phản hồi nhanh.
• Bạn muốn mở rộng worker theo chiều ngang (thêm VPS worker).

Nếu dùng Queue Mode, bạn cần thêm RAM cho Redis (tối thiểu 256 MB cho Redis riêng, hoặc chạy chung container với n8n nếu ít workflow). VPS 4 GB RAM là điểm bắt đầu hợp lý cho Queue Mode với 2-3 worker cùng lúc.

Bước 4 - Bảng cấu hình VPS khuyến nghị theo số workflow

Dựa trên kinh nghiệm thực tế và benchmark với các loại workflow phổ biến, đây là bảng tham khảo nhanh cho bạn.

Lưu ý: Nếu bạn dùng thêm các dịch vụ khác trên cùng VPS (PostgreSQL, Redis, Nginx reverse proxy), hãy cộng thêm ít nhất 1-2 GB RAM vào con số khuyến nghị. Thực tế, một VPS Linux 4 GB RAM với 2 vCPU là "điểm ngọt" cho hầu hết cá nhân và team nhỏ: chạy được 10-15 workflow loại trung bình, có thể bật Queue Mode nhẹ, còn dư chỗ cho một database nhỏ.

Xử lý lỗi thường gặp khi chọn sai cấu hình

Lỗi 1: Workflow timeout liên tục, hoặc execution báo "OOM killed".
Nguyên nhân: RAM không đủ cho một execution phức tạp. Kiểm tra: docker logs <container_n8n> | grep -i "killed". Giải pháp: tăng RAM VPS, hoặc tối ưu workflow (giảm kích thước payload, dùng pagination).

Lỗi 2: CPU rất cao trong thời gian dài, webhook phản hồi chậm.
Nguyên nhân: Nhiều webhook đến cùng lúc, vCPU quá ít. Kiểm tra: htop xem load average. Giải pháp: bật Queue Mode để đệm request, hoặc nâng cấp lên 4 vCPU.

Lỗi 3: n8n mở nhưng không thực thi workflow cron, log không có lỗi.
Nguyên nhân: Thiếu tài nguyên dẫn đến scheduler bị delay. Kiểm tra: journalctl -u docker. Giải pháp: cấu hình swap (tạm thời) và nâng RAM VPS trong kỳ thanh toán tiếp theo.

Câu hỏi thường gặp

Bài viết liên quan

• Cài n8n trên VPS Ubuntu 24.04 bằng Docker Compose từ A-Z
• N8n Queue Mode với Redis: khi nào cần tách worker
• Tối ưu n8n trên VPS 2GB RAM với Prune và giới hạn Worker