Kinh nghiệm tối ưu hiệu suất n8n self-host: database, execution, queue mode

Muốn n8n self-host chạy nhanh và ổn định, hãy làm theo thứ tự: chuyển database sang PostgreSQL, bật tự dọn dữ liệu execution cũ, giới hạn số lượt chạy đồng thời, lưu file nhị phân ra ổ đĩa, rồi mới tách queue mode với Redis và worker khi một tiến trình không còn đủ. Mỗi bước đều có biến môi trường chính thức.

Bài này dành cho n8n đã cài đặt trên VPS bằng Docker. Nếu bạn đang tìm khái niệm self host và cách chọn giữa tự host với n8n Cloud, xem so sánh n8n self-host và n8n Cloud.

Vì sao n8n self-host chạy chậm?

n8n self-host thường chậm vì bốn nhóm nguyên nhân: máy chủ thiếu RAM hoặc ổ đĩa chậm, database SQLite phình to vì giữ quá nhiều dữ liệu execution, quá nhiều workflow chạy cùng lúc trong một tiến trình, và workflow xử lý dữ liệu lớn hơn mức cần. Biết nhóm nguyên nhân trước giúp bạn không nâng cấp VPS khi lỗi nằm ở workflow.

Cấu hình phần cứng máy chủ

• CPU: số lõi và tốc độ CPU ảnh hưởng trực tiếp đến tốc độ chạy workflow phức tạp hoặc xử lý nhiều dữ liệu.
• RAM: workflow nhiều bước, dữ liệu lớn hoặc nhiều lượt chạy đồng thời tiêu tốn nhiều RAM. Theo tài liệu n8n, bộ nhớ dùng phụ thuộc lượng dữ liệu, số node và số lượt chạy cùng lúc, nên n8n không công bố mức RAM tối thiểu cố định (Memory-related errors).
• Ổ cứng: tốc độ đọc ghi ảnh hưởng đến database (SQLite hoặc PostgreSQL) và file tạm. SSD hoặc NVMe nhanh hơn rõ rệt so với HDD.
• Mạng: workflow gọi API bên ngoài hoặc tải file lớn phụ thuộc băng thông và độ trễ mạng.

Cấu hình phần mềm n8n và môi trường

• Database: mặc định n8n dùng SQLite, phù hợp cài đặt nhỏ. Khi lượng execution lớn, SQLite dễ thành điểm nghẽn.
• Chế độ chạy: mặc định regular, mọi thứ chạy trong một tiến trình; queue tách phần thực thi sang các worker.
• Dữ liệu execution: n8n lưu kết quả từng lần chạy; giữ quá lâu làm database phình to và chậm.
• Phiên bản n8n: bản mới thường có cải tiến hiệu năng và bản vá; nên cập nhật định kỳ.

Thiết kế workflow

• Độ phức tạp: càng nhiều node, vòng lặp, nhánh điều kiện thì càng tốn tài nguyên và thời gian.
• Kích thước dữ liệu: xử lý file lớn hoặc danh sách dài trong một lần chạy làm tăng RAM.
• Số lượt chạy đồng thời và tần suất: trigger quá dày (mỗi giây) hoặc nhiều webhook cùng lúc dễ gây quá tải.

Giám sát và bảo trì

• Thiếu giám sát: không theo dõi CPU, RAM, ổ đĩa, số execution thì khó phát hiện vấn đề sớm.
• Không cập nhật: bỏ lỡ bản vá lỗi hiệu năng và bảo mật.
• Log và dữ liệu cũ: không dọn thì đầy ổ đĩa và làm chậm hệ thống.

Nên tối ưu n8n self-host theo thứ tự nào?

Nên tối ưu n8n self-host từ việc rẻ và ít rủi ro đến việc phức tạp: dọn dữ liệu và chuyển database trước, sau đó giới hạn lượt chạy đồng thời, cuối cùng mới tách queue mode. Bảng dưới tóm tắt từng bước, biến môi trường dùng và lúc nên làm.

Kinh nghiệm tối ưu hiệu suất n8n self-host

Chọn cấu hình máy chủ và hệ điều hành phù hợp

Cấu hình máy chủ cho n8n nên bắt đầu vừa đủ rồi nâng theo số liệu giám sát. Kinh nghiệm thực tế: 2 vCPU là mức khởi đầu, 4 vCPU cho hệ thống nhiều workflow; RAM từ 4GB cho cài đặt nhỏ và vừa, 8–16GB khi xử lý dữ liệu lớn hoặc chạy cả PostgreSQL, Redis trên cùng VPS. Luôn dùng SSD hoặc NVMe.

• Hệ điều hành: dùng Ubuntu 24.04 LTS hoặc Debian 12/13 và cập nhật bản vá thường xuyên. CentOS Linux đã hết vòng đời ngày 30/06/2024, không nên dùng cho máy mới.
• Tắt dịch vụ không cần thiết: giảm tiến trình chạy ngầm không liên quan để dành CPU, RAM cho n8n.
• Swap: một lượng swap vừa phải (khoảng 1–2 lần RAM với VPS nhỏ) giúp hệ thống không bị dừng khi tải tăng đột ngột, nhưng dùng swap thường xuyên là dấu hiệu thiếu RAM.

Bảng cấu hình theo quy mô: cấu hình tối thiểu để triển khai VPS n8n. Giới hạn RAM, CPU cho từng container Docker: tối ưu RAM và CPU cho n8n Docker trên VPS.

Dùng PostgreSQL thay vì SQLite

PostgreSQL là database nên dùng cho n8n chạy thật; n8n hỗ trợ PostgreSQL 16, 17 và 18 (Choose n8n’s database). MySQL và MariaDB không còn được hỗ trợ làm database của n8n từ bản 2.0 (v2.0 breaking changes); node MySQL để đọc ghi dữ liệu trong workflow vẫn dùng bình thường.

SQLite là database dạng file, đơn giản, hợp với cài đặt cá nhân ít workflow. Khi số workflow và execution tăng, SQLite xử lý đồng thời kém hơn và file database phình to. Cách chuyển dữ liệu sang PostgreSQL bằng lệnh export và import của n8n: đổi database n8n từ SQLite sang PostgreSQL.

Bật tự dọn dữ liệu execution cũ

n8n tự xóa dữ liệu execution cũ theo hai ngưỡng: tuổi (mặc định 336 giờ, tức 14 ngày) và số lượng (mặc định 10.000 execution). Biến EXECUTIONS_DATA_MAX_AGE tính bằng giờ (Executions environment variables). Hạ hai ngưỡng này là cách rẻ nhất để database nhẹ lại.

EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=168            # giữ 7 ngày (tính bằng giờ)
EXECUTIONS_DATA_PRUNE_MAX_COUNT=5000
EXECUTIONS_DATA_SAVE_ON_SUCCESS=none   # không lưu execution chạy thành công

Chỉ đặt EXECUTIONS_DATA_SAVE_ON_SUCCESS=none khi bạn không cần xem lại lần chạy thành công; execution lỗi vẫn được lưu để gỡ lỗi.

Giới hạn số lượt chạy đồng thời

Ở chế độ regular, N8N_CONCURRENCY_PRODUCTION_LIMIT giới hạn số lượt chạy production cùng lúc; mặc định -1 là không giới hạn (Executions environment variables). Lượt chạy vượt giới hạn được xếp hàng chờ thay vì chạy cùng lúc làm tràn RAM.

N8N_CONCURRENCY_PRODUCTION_LIMIT=10

Ở queue mode, mỗi worker tự giới hạn bằng cờ --concurrency (xem phần queue mode bên dưới).

Lưu binary data ra ổ đĩa

Binary data là file đính kèm, ảnh, PDF đi qua workflow. Từ n8n 2.0, chế độ giữ binary data trong RAM đã bị gỡ; ở chế độ regular, mặc định là filesystem, ở queue mode mặc định là database, ngoài ra có s3 (v2.0 breaking changes).

N8N_DEFAULT_BINARY_DATA_MODE=filesystem

Đảm bảo thư mục dữ liệu (mặc định nằm trong .n8n) còn đủ dung lượng. Tài liệu queue mode ghi n8n không hỗ trợ lưu binary data dạng filesystem khi chạy queue mode; khi đó dùng database hoặc S3.

Chạy n8n ở queue mode khi một tiến trình không còn đủ

Queue mode tách n8n thành một tiến trình main nhận trigger và webhook, Redis giữ hàng đợi, và nhiều worker thực thi workflow song song. Worker lấy việc từ Redis, đọc workflow trong database, chạy xong thì ghi kết quả lại (Enable queue mode).

Các điều kiện bắt buộc theo tài liệu n8n:

• Đặt EXECUTIONS_MODE=queue trên main và trên mọi worker.
• Dùng PostgreSQL; n8n không khuyến nghị chạy queue mode với SQLite.
• Main, worker và webhook processor phải dùng chung N8N_ENCRYPTION_KEY, nếu không worker không giải mã được credentials.
• Worker mặc định chạy 10 việc song song; n8n khuyên đặt --concurrency từ 5 trở lên.

Ví dụ phần khai báo trong Docker Compose (rút gọn, cần thêm service PostgreSQL và các biến DB_*):

services:
  redis:
    image: redis:7-alpine
    restart: unless-stopped

  n8n:
    image: n8nio/n8n:2.44.6
    environment:
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=redis
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - DB_TYPE=postgresdb

  n8n-worker:
    image: n8nio/n8n:2.44.6
    command: worker --concurrency=5
    environment:
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=redis
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - DB_TYPE=postgresdb

Main và worker phải chạy cùng một phiên bản n8n. Muốn thêm sức xử lý, tăng số worker (docker compose up -d --scale n8n-worker=2) thay vì chỉ tăng concurrency.

Khi lượng webhook rất lớn, có thể chạy thêm tiến trình n8n webhook riêng và đặt N8N_DISABLE_PRODUCTION_MAIN_PROCESS=true trên main để main không nhận webhook production nữa (Enable queue mode). Cần một reverse proxy chia đường dẫn /webhook/ sang các tiến trình này; cách cấu hình Nginx xem ở cấu hình Nginx reverse proxy và SSL cho n8n.

Redis trong queue mode đóng vai trò hàng đợi việc (thư viện Bull), không phải bộ nhớ đệm cho workflow. Nếu cần nhiều n8n độc lập trên cùng máy thay vì một n8n nhiều worker, xem chạy nhiều instance n8n trên cùng 1 VPS.

Một số biến môi trường khác nên biết

• N8N_PUSH_BACKEND: chọn websocket (mặc định) hoặc sse để gửi cập nhật lên giao diện; đổi sang sse khi proxy không hỗ trợ WebSocket (Deployment environment variables).
• EXECUTIONS_TIMEOUT: thời gian tối đa (giây) cho mỗi workflow, mặc định -1 là không giới hạn; đặt giá trị để workflow treo không giữ tài nguyên mãi.
• N8N_METRICS=true: bật endpoint /metrics cho Prometheus (xem phần giám sát).

Tối ưu workflow

Tối ưu workflow thường mang lại hiệu quả lớn hơn nâng cấp máy chủ, vì phần lớn tài nguyên bị tiêu vào dữ liệu thừa và lượt chạy không cần thiết.

• Dùng Schedule Trigger hợp lý: với tác vụ định kỳ, chọn khoảng thời gian thật sự cần (mỗi giờ, mỗi ngày) thay vì chạy mỗi phút để kiểm tra.
• Tách phần dùng chung thành sub-workflow: gọi bằng node Execute Workflow để dễ bảo trì; sub-workflow chạy xong sẽ giải phóng dữ liệu của nó, giúp workflow cha nhẹ hơn khi xử lý danh sách dài.
• Gọi API hiệu quả: với node HTTP Request, chỉ lấy trường cần thiết, đặt Timeout để không treo khi API chậm, bật Retry On Fail cho lỗi tạm thời.
• Tôn trọng giới hạn tốc độ API: chia dữ liệu thành lô bằng Loop Over Items, thêm node Wait giữa các lô hoặc dùng tùy chọn Batching của HTTP Request để không bị chặn vì gửi quá nhanh.
• Có error workflow: đặt một workflow dùng Error Trigger để ghi lại và báo lỗi, giúp khoanh vùng sự cố nhanh.
• Chỉ truyền dữ liệu cần thiết: dùng Edit Fields (Set) để bỏ bớt trường trước các bước nặng; JSON lớn không cần thiết làm tăng CPU, RAM.

Giám sát và theo dõi hiệu suất

Giám sát giúp bạn biết nên tối ưu ở đâu thay vì đoán. n8n xuất số liệu cho Prometheus khi đặt N8N_METRICS=true; endpoint /metrics chỉ nên mở cho dịch vụ nội bộ, không công khai ra Internet (Enable Prometheus metrics). Kết nối Prometheus với Grafana để xem số liệu theo thời gian.

• CPU, RAM: dùng nhiều liên tục hoặc phải dùng swap là dấu hiệu cần tối ưu workflow hoặc tăng tài nguyên.
• Ổ đĩa: I/O cao thường do database quá tải hoặc xử lý nhiều file lớn; theo dõi cả dung lượng trống.
• Số execution và thời gian chạy: số lượt chờ trong hàng đợi tăng hoặc thời gian chạy trung bình tăng là lúc cân nhắc thêm worker.
• Công cụ nhanh trên máy chủ: htop, docker stats để xem tài nguyên từng container.

Bảo mật và cập nhật

• Cập nhật n8n định kỳ: bản mới có cải tiến hiệu năng và bản vá bảo mật; sao lưu trước khi nâng. Xem cách cập nhật n8n.
• Cập nhật hệ điều hành, Docker, PostgreSQL, Redis để có bản vá ở cấp hệ thống.
• Không mở cổng 5678 ra Internet: dùng reverse proxy (Nginx, Caddy) có HTTPS, hoặc Cloudflare Tunnel khi không muốn mở cổng trên tường lửa. Nhớ đặt N8N_WEBHOOK_URL (n8n từ 2.30.0) bằng địa chỉ công khai.

Kết luận

Tối ưu n8n self-host hiệu quả nhất khi làm theo thứ tự: PostgreSQL, dọn dữ liệu execution, giới hạn lượt chạy đồng thời, binary data ra ổ đĩa, rồi mới queue mode. Song song đó, rút gọn dữ liệu trong workflow và bật giám sát để có số liệu trước khi nâng cấp VPS.

Muốn chạy n8n 24/7 mà không tự cài? VPS n8n của Tino cài sẵn n8n trên VPS NVMe đặt tại Việt Nam; bạn vẫn có quyền root để cấu hình. Xem cấu hình và giá trên trang sản phẩm.

Những câu hỏi thường gặp