n8n xử lý dữ liệu hàng loạt mà không nghẽn máy chủ

Workflow chạy mượt lúc test với 20 dòng dữ liệu mẫu. Cắm vào file thật 20.000 dòng, máy chủ đứng hình hoặc workflow báo lỗi timeout giữa chừng. Đây là tình huống lặp lại nhiều lần khi doanh nghiệp mới bắt đầu dùng n8n xử lý dữ liệu hàng loạt: logic đúng nhưng cách nạp dữ liệu sai, và máy chủ trả giá.

Vì sao 20 dòng chạy êm còn 20.000 dòng làm đứng máy

Mặc định, n8n nạp toàn bộ tập dữ liệu vào bộ nhớ trước khi xử lý node tiếp theo. Với 20 dòng, phần dữ liệu này chỉ vài KB. RAM không hề hấn gì, kể cả trên gói VPS n8n nhỏ nhất. Với 20.000 dòng kèm nhiều trường dữ liệu, cùng một cơ chế đó đẩy bộ nhớ tiến trình lên vài trăm MB chỉ để giữ dữ liệu trung gian.

Vấn đề không nằm ở logic workflow. Nó nằm ở cách dữ liệu di chuyển giữa các node. Mỗi node nhận toàn bộ mảng item từ node trước, xử lý xong rồi đẩy toàn bộ mảng kết quả sang node sau. Không có bước chia nhỏ. Item càng nhiều, đỉnh RAM càng cao, và một tiến trình n8n trên VPS cấu hình thấp dễ chạm giới hạn bộ nhớ rồi bị hệ điều hành kill ngang.

Node Loop Over Items chia lô đúng cách

Node Loop Over Items, trước đây gọi là Split In Batches, cắt một mảng lớn thành các lô nhỏ. Xử lý xong lô này mới nạp lô kế tiếp, thay vì giữ toàn bộ trong bộ nhớ cùng lúc. Đây là công cụ chính để n8n xử lý dữ liệu hàng loạt mà không đẩy RAM lên đỉnh ngay từ bước đầu.

Chọn kích thước batch theo dữ liệu

Batch quá nhỏ, ví dụ 5 item mỗi lô cho tập 20.000 dòng, sinh ra 4.000 vòng lặp. Workflow chạy chậm vì overhead giữa các lần lặp cộng dồn. Batch quá lớn thì quay lại đúng vấn đề ban đầu: RAM tăng vọt trong từng lô. Với dữ liệu văn bản đơn giản, batch 100 tới 200 item mỗi lô thường an toàn trên VPS 4 GB RAM. Dữ liệu kèm file đính kèm hoặc phản hồi API dài thì nên hạ xuống 20 tới 50 item.

Theo dõi độ trễ giữa các lô

Nếu một lô mất hơn 30 giây để xử lý, đó là dấu hiệu batch đang quá lớn hoặc node xử lý bên trong đang gọi một dịch vụ chậm. Giảm kích thước lô trước, đo lại thời gian, rồi mới nghĩ tới việc nâng cấu hình máy chủ.

Node Wait tránh giới hạn tốc độ API

Nhiều API bên thứ ba giới hạn số request trong một khoảng thời gian, thường gọi là rate limit. Đẩy 20.000 request liên tiếp không nghỉ, phía API trả về lỗi 429. Workflow dừng lại ở lô đang chạy dở, để lại một phần dữ liệu chưa xử lý mà không rõ đã dừng ở đâu.

Node Wait chèn một khoảng nghỉ cố định giữa các lô hoặc giữa các request, giữ tốc độ gọi API dưới ngưỡng cho phép. API giới hạn 60 request mỗi phút thì đặt Wait 1 giây sau mỗi request. Tốc độ giữ ở khoảng 60 request mỗi phút, đủ an toàn để không chạm ngưỡng. Cách làm này chậm hơn gọi dồn dập, nhưng chạy hết được toàn bộ tập dữ liệu thay vì đứt giữa chừng.

Dấu hiệu workflow sắp tràn bộ nhớ

Ba dấu hiệu hay gặp trước khi n8n bị kill vì hết RAM. Workflow chạy chậm dần theo thời gian dù batch không đổi. Log xuất hiện cảnh báo về heap hoặc allocation. Tiến trình node đứng im vài phút rồi tự tắt, không rõ lý do trong giao diện. Gặp một trong ba dấu hiệu này thì hạ kích thước batch trước, rồi mới tìm nguyên nhân khác.

Xử lý xong một phần rồi workflow dừng thì làm sao

Xử lý dữ liệu hàng loạt gặp lỗi giữa chừng là chuyện bình thường, không phải dấu hiệu workflow sai. Vấn đề là biết được nó đã dừng ở đâu. Cần vậy để không phải chạy lại từ đầu và không bị trùng dữ liệu ở phần đã xử lý xong.

Cách xử lý gọn nhất là ghi lại vị trí đã xử lý ngay trong node. Ví dụ lưu ID của item cuối cùng chạy thành công vào một node lưu trạng thái, thay vì chỉ trông vào lịch sử thực thi để đoán. Workflow chạy lại thì đọc vị trí đã lưu, bỏ qua phần đã xử lý. Theo tài liệu n8n, node Loop Over Items hỗ trợ theo dõi item đang xử lý qua từng vòng lặp. Đây là điểm cần khai thác thêm, thay vì chỉ dùng nó như một vòng lặp đơn thuần.

Khi nào nên nâng cấu hình máy chủ thay vì chỉnh batch

Chỉnh batch xử lý được phần lớn trường hợp workflow chạy chậm hoặc nghẽn RAM. Nhưng có ngưỡng mà chỉnh batch không giải quyết nổi. Khối lượng dữ liệu tăng đều đặn theo thời gian thì mỗi lần chỉnh batch chỉ mua thêm vài tuần, trước khi lại chạm giới hạn.

VPS 4 GB RAM đủ cho phần lớn workflow xử lý vài nghìn bản ghi mỗi lần chạy. Khối lượng lên tới hàng chục nghìn bản ghi kèm nhiều workflow chạy song song thì 8 GB RAM là mức hợp lý, tránh phải chỉnh batch liên tục. BizMaC có VPS cài sẵn n8n cùng PostgreSQL và Redis ở ba mức cấu hình. Gói n8n Pro 690.000đ/tháng với 4 vCPU và 8 GB RAM là mức nhiều doanh nghiệp xử lý dữ liệu hàng loạt chọn khi vượt ngưỡng gói cơ bản. Xem thêm ở các gói VPS cài sẵn n8n để so cấu hình trước khi nâng cấp.

Gói đắt hơn không tự nhiên xử lý batch nhanh hơn nếu bản thân workflow vẫn nạp dữ liệu sai cách. Nâng RAM chỉ có ích khi batch đã được chia hợp lý mà vẫn chạm giới hạn tài nguyên hiện có, không phải bước làm đầu tiên. Đội không có người theo dõi RAM và log mỗi ngày thì quản trị máy chủ theo gói tháng giúp phát hiện workflow sắp chạm ngưỡng trước khi nó tự tắt giữa chừng.

Câu hỏi thường gặp về n8n xử lý dữ liệu hàng loạt

Ghi nhanh

• RAM tăng theo kích thước batch, không phải theo tổng số dòng dữ liệu; chia lô nhỏ để giữ đỉnh RAM ổn định.
• Node Loop Over Items xử lý từng lô thay vì nạp toàn bộ mảng cùng lúc, batch 100 tới 200 item là điểm khởi đầu hợp lý cho dữ liệu văn bản.
• Node Wait giữa các lô giữ tốc độ gọi API dưới ngưỡng rate limit, tránh lỗi 429 làm dừng workflow giữa chừng.
• Lưu vị trí item đã xử lý xong để chạy lại không bị trùng dữ liệu khi workflow dừng giữa chừng.
• Nâng cấu hình máy chủ chỉ nên làm sau khi đã chia batch hợp lý mà vẫn chạm giới hạn tài nguyên hiện có.