Tối ưu n8n trên VPS 2GB RAM với prune và giới hạn worker

Bạn có một VPS 2GB RAM và muốn chạy n8n để tự động hóa công việc, nhưng n8n bắt đầu ngốn RAM, thậm chí bị kill vì OOM sau vài ngày chạy? Đây là vấn đề rất phổ biến. Cốt lõi là n8n lưu trữ toàn bộ lịch sử execution (dữ liệu mỗi lần workflow chạy) vào database và cho phép nhiều worker xử lý song song, tiêu tốn RAM không cần thiết. Bài viết này sẽ hướng dẫn bạn hai kỹ thuật cốt lõi: prune dữ liệu execution cũ và giới hạn số lượng worker để tối ưu n8n chạy mượt trên VPS 2GB RAM, giúp hệ thống automation của bạn hoạt động ổn định mà không cần nâng cấp VPS.

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

• Một VPS chạy Ubuntu 24.04 LTS với 2GB RAM và ít nhất 20GB ổ cứng NVMe (bạn có thể tham khảo các gói VPS Linux NVMe tại thueVPS).
• Đã cài đặt n8n bằng Docker Compose. Nếu chưa có, hãy tham khảo bài viết Cài đặt n8n trên VPS Ubuntu 24.04 bằng Docker Compose.
• Quyền sudo hoặc root trên VPS.
• Kiến thức cơ bản về Docker và biến môi trường.

Vì sao VPS 2GB RAM gặp khó với n8n mặc định?

Mặc định, n8n lưu trữ tất cả dữ liệu execution (input, output, status, logs) trong database. Sau vài trăm, vài nghìn lần chạy, database này phình to lên hàng trăm MB, thậm chí GB, khiến worker tốn thêm bộ nhớ để truy vấn và xử lý. Ngoài ra, n8n có thể spawn ra nhiều worker để xử lý các workflow chạy song song, và với RAM 2GB, mỗi worker ngốn thêm 100-200 MB, dễ dẫn đến OOM (Out of Memory) khi có 3-4 workflow chạy cùng lúc. Thực tế mình từng thấy một VPS 2GB bị treo vì OOM chỉ sau 2 ngày chạy 10 workflow với tần suất 5 phút/lần. Hai kỹ thuật dưới đây là cách giải quyết trực tiếp vào gốc vấn đề.

Bước 1 - Thiết lập prune dữ liệu execution cũ

Prune execution là cơ chế tự động xóa bỏ các bản ghi execution cũ khỏi database, giữ cho cơ sở dữ liệu gọn nhẹ. n8n hỗ trợ biến môi trường cho việc này, không cần cài thêm tool nào.

Trong file docker-compose.yml của bạn (thường đặt ở /opt/n8n/ hoặc ~/n8n/), thêm các biến sau vào environment: của service n8n:

environment:
  - N8N_EXECUTIONS_DATA_PRUNE=true
  - N8N_EXECUTIONS_DATA_MAX_AGE=168
  - N8N_EXECUTIONS_DATA_PRUNE_TIMEOUT=120000

Giải thích từng biến:

• N8N_EXECUTIONS_DATA_PRUNE=true: Bật chức năng prune. Mặc định là false.
• N8N_EXECUTIONS_DATA_MAX_AGE=168: Số giờ giữ lại dữ liệu execution. 168 giờ = 7 ngày. Với VPS 2GB RAM, mình khuyên 48-72 giờ (2-3 ngày) nếu bạn không cần debug lâu dài. Bạn có thể đặt thành 48 (2 ngày) cho tiết kiệm tối đa.
• N8N_EXECUTIONS_DATA_PRUNE_TIMEOUT=120000: Thời gian tối đa (milli giây) để prune chạy. 120 giây là an toàn, nếu database quá lớn có thể cần tăng lên 300000.

Verify: Sau khi áp dụng, restart container và theo dõi logs:

docker compose down
docker compose up -d
docker compose logs -f n8n | grep prune

Bạn sẽ thấy dòng log kiểu "Starting execution data pruning." hoặc "Pruned X executions." nếu có dữ liệu cũ. Ngoài ra, bạn có thể kiểm tra dung lượng database trước và sau bằng lệnh truy vấn docker volume:

docker system df -v | grep n8n

Sau 24-48h, nếu prune hoạt động, dung lượng volume chứa database sẽ giảm rõ rệt (thường từ vài trăm MB xuống dưới 50 MB với cấu hình 48 giờ và ít workflow).

Lưu ý: Nếu bạn đã chạy n8n được một thời gian, lần prune đầu tiên có thể rất nặng (xóa hàng nghìn bản ghi). Hãy đảm bảo server có đủ I/O và bạn không tắt container giữa chừng.

Bước 2 - Giới hạn số lượng worker

Worker trong n8n là các tiến trình chịu trách nhiệm chạy workflow. Mặc định, n8n có thể spawn nhiều worker dựa trên tải, nhưng trên VPS 2GB RAM, mỗi worker thừa đều là gánh nặng. Quan trọng hơn, nếu bạn dùng queue mode (production) với Redis, worker được quản lý riêng biệt, nhưng ngay cả với built-in mode (mặc định), con số này cũng cần khống chế.

Thêm biến môi trường này vào docker-compose.yml:

environment:
  - EXECUTIONS_TIMEOUT=600
  - N8N_WORKERS_MAX=2
  - N8N_PAYLOAD_SIZE_MAX=1

Giải thích:

• EXECUTIONS_TIMEOUT=600: Thời gian tối đa (giây) cho một workflow execution. 10 phút là an toàn cho hầu hết workflow. Workflow chạy quá lâu sẽ bị hủy, giải phóng worker và RAM.
• N8N_WORKERS_MAX=2: Giới hạn số lượng worker tối đa là 2. Với VPS 2GB, 2 worker là đủ đẹp: 1 worker dự phòng, 1 worker chịu tải. Bạn có thể đặt 1 nếu chỉ chạy workflow đơn giản, nhưng khuyên dùng 2 để xử lý đồng thời vài workflow nhẹ. Không đặt quá 3.
• N8N_PAYLOAD_SIZE_MAX=1: Giới hạn kích thước payload (dữ liệu đầu vào) tối đa là 1MB. Giúp tránh các workflow với dữ liệu lớn (vd webhook với file 10MB) làm nghẽn worker.

Kiểm tra hoạt động: Sau khi restart container, bạn có thể theo dõi số lượng worker bằng cách xem logs hoặc truy cập giao diện n8n:

• Logs: docker compose logs n8n | grep worker, bạn sẽ thấy dòng "Worker started with concurrency 2".
• Giao diện n8n: vào Settings > Execution concurrency. Nếu bạn đã giới hạn worker, concurrency sẽ không vượt quá số bạn đặt (trừ khi bạn cấu hình thêm).

Bước 3 - Tối ưu thêm cho VPS 2GB RAM

Ngoài prune và worker, một số tweak nhỏ giúp n8n chạy ổn định hơn:

• Giới hạn RAM cho container Docker: Dùng deploy: trong docker-compose để set memory limit cứng:
  

  deploy:
    resources:
      limits:
        memory: 1024M
      reservations:
        memory: 512M

  Điều này đảm bảo n8n không vượt quá 1GB RAM, giữ phần còn lại cho hệ điều hành và các service khác.
• Tăng swap: Với VPS 2GB, swap 2-4GB rất hữu ích. Tham khảo bài viết Cấu hình swap và tối ưu bộ nhớ cho VPS RAM thấp.
• Dùng PostgreSQL thay SQLite: Mặc định n8n dùng SQLite. Chuyển sang PostgreSQL giúp quản lý dữ liệu execution tốt hơn, đặc biệt khi prune. Đọc thêm bài Chuyển n8n từ SQLite sang PostgreSQL không mất workflow.

Bảng thông số tối ưu cho VPS 2GB RAM

Xử lý lỗi thường gặp

Lỗi: Container bị kill liên tục (OOM)
Kiểm tra logs: docker compose logs n8n | grep -i "Killed" hoặc dmesg | grep -i oom. Nếu thấy dòng "Memory cgroup out of memory: Killed process", nghĩa là container vượt quá memory limit. Hãy tăng memory limit lên 1536M hoặc giảm N8N_WORKERS_MAX xuống 1.

Lỗi: Workflow chạy rất chậm hoặc timeout
Nguyên nhân thường do database SQLite bị phình khi chưa bật prune. Kiểm tra kích thước volume với du -sh /var/lib/docker/volumes/...n8n. Nếu trên 500MB, hãy prune thủ công tạm thời bằng lệnh docker exec -it n8n n8n clear:executions --days 1 (xóa các execution cũ hơn 1 ngày). Sau đó bật self-prune như mục 1.

Lỗi: Nhưng có workflow dài chạy hơn 10 phút

Ví dụ workflow crawl dữ liệu?

Nếu bạn có workflow chạy lâu hơn 600 giây (vd crawl 500 trang web), hãy tăng EXECUTIONS_TIMEOUT lên 1800 (30 phút) hoặc chia workflow thành nhiều phần nhỏ hơn. Nhưng hãy nhớ: worker giới hạn ở 2 đồng nghĩa với việc nếu 1 worker bận quá lâu, workflow khác phải chờ.

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
• Backup n8n đúng cách: encryption key, database và credential
• Chọn RAM cho n8n theo số workflow chạy song song
• Webhook n8n không nhận request? Checklist xử lý theo thứ tự