n8n Thai
by n8n Thai

n8n ช้า? วิธีเพิ่มประสิทธิภาพ n8n Server

วิเคราะห์สาเหตุที่ n8n ช้าและวิธีแก้ไข ตั้งแต่ตั้งค่า database, execution pruning, ไปจนถึงปรับ resource ของ server

n8n ช้า? วิธีเพิ่มประสิทธิภาพ n8n Server

n8n ที่เริ่มช้าลงเรื่อยๆ มักไม่ใช่ปัญหาของ n8n เอง แต่เป็นเพราะ execution history สะสมจนฐานข้อมูลใหญ่มาก หรือ server มี resource ไม่พอกับ workflow ที่ซับซ้อน บทความนี้จะช่วยให้คุณวิเคราะห์และแก้ปัญหาได้ตรงจุด

ก่อนปรับแต่งอะไร ควรวัดก่อนว่าช้าตรงไหน ใช้คำสั่งนี้ดู resource ที่ n8n ใช้:

docker stats n8n

จะเห็น CPU%, Memory usage, และ Network I/O แบบ real-time ข้อมูลนี้จะบอกได้ว่าปัญหาอยู่ที่ resource ไม่พอ หรือ database

ตั้งค่า Execution Pruning (สำคัญที่สุด)

Execution history คือสาเหตุอันดับหนึ่งที่ทำให้ n8n ช้า ทุก workflow ที่รันจะบันทึก log ไว้ใน database และถ้าไม่ลบ database จะโตขึ้นเรื่อยๆ

เปิดใช้ execution pruning โดยเพิ่มใน environment:

# เปิด pruning อัตโนมัติ
EXECUTIONS_DATA_PRUNE=true

# เก็บ execution data ไว้กี่ชั่วโมง (168 = 7 วัน)
EXECUTIONS_DATA_MAX_AGE=168

# จำนวน execution สูงสุดที่เก็บ (ต่อ workflow)
EXECUTIONS_DATA_SAVE_ON_ERROR=all
EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS=true

การตั้ง EXECUTIONS_DATA_SAVE_ON_SUCCESS=none หมายความว่าจะไม่บันทึก execution ที่สำเร็จ เก็บเฉพาะที่ error ทำให้ database เล็กลงมาก แต่คุณจะไม่เห็น history ของ execution ที่สำเร็จ

เปลี่ยนจาก SQLite เป็น PostgreSQL

SQLite ไม่เหมาะสำหรับ concurrent requests จำนวนมาก ถ้า n8n รับ webhook หลายตัวพร้อมกันหรือรัน workflow ซ้อนกันบ่อย ควรเปลี่ยนเป็น PostgreSQL

เกณฑ์SQLitePostgreSQL
Concurrent workflowsต่ำสูง
Database sizeจำกัด (RAM)ไม่จำกัด
Backupง่ายต้องใช้ pg_dump
Setupไม่ต้องตั้งค่าต้องติดตั้งเพิ่ม
เหมาะกับ< 10 workflow/วัน> 10 workflow/วัน

วิธีย้ายไป PostgreSQL ด้วย Docker Compose ดูได้ที่ ติดตั้ง n8n ด้วย Docker

ปรับ Resource ของ Container

n8n ต้องการ RAM อย่างน้อย 512MB สำหรับการใช้งานทั่วไป และ 1GB+ สำหรับ workflow ที่ใช้ AI หรือ process ข้อมูลมาก

ตั้งค่า memory limit และ CPU ใน docker-compose.yml:

services:
  n8n:
    image: n8nio/n8n:latest
    deploy:
      resources:
        limits:
          memory: 2G
          cpus: "2.0"
        reservations:
          memory: 512M
          cpus: "0.5"

ถ้า n8n กิน memory มากเกินไป ลอง enable Node.js garbage collection ที่ aggressive ขึ้น:

NODE_OPTIONS=--max-old-space-size=1024

ใช้ Queue Mode สำหรับ High-Volume

สำหรับ setup ที่ต้องรัน workflow จำนวนมากพร้อมกัน n8n มี Queue Mode ที่ใช้ Redis เป็น message broker:

services:
  n8n:
    environment:
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=redis
      - QUEUE_BULL_REDIS_PORT=6379

  n8n-worker:
    image: n8nio/n8n:latest
    command: worker
    environment:
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=redis
      - QUEUE_BULL_REDIS_PORT=6379
    depends_on:
      - redis

  redis:
    image: redis:7-alpine
    volumes:
      - redis_data:/data

Queue Mode แยก main n8n process กับ worker ออกจากกัน ทำให้ UI ยังตอบสนองได้ดีแม้มี workflow รันอยู่เยอะ

ปรับแต่ง Workflow ให้มีประสิทธิภาพ

บางครั้งปัญหาไม่ได้อยู่ที่ server แต่อยู่ที่ workflow design:

หลีกเลี่ยง Loop ที่ไม่จำเป็น

แทนที่จะ loop ผ่านรายการทีละรายการ ใช้ node ที่ process batch ได้เลย เช่น HTTP Request node รองรับ batching โดย native

ใช้ Wait Node แทน Delay Loop

ถ้าต้องรอ API ให้พร้อม ใช้ Wait node แทนการ loop poll เพื่อไม่ให้ CPU ทำงานฟรี

แยก Workflow ใหญ่เป็น Sub-Workflows

Workflow ที่ยาวเกิน 50 node ควรแยกเป็น sub-workflow และเรียกผ่าน Execute Workflow node ทำให้ debug ง่ายขึ้นและ memory ถูกใช้อย่างมีประสิทธิภาพ

ตรวจสอบ Database Size

ดูขนาด database ปัจจุบัน:

# SQLite
ls -lh ~/.n8n/database.sqlite

# PostgreSQL
docker exec postgres psql -U n8n -d n8n -c "
SELECT pg_size_pretty(pg_database_size('n8n')) AS db_size;
"

# ดูตารางที่ใหญ่ที่สุด
docker exec postgres psql -U n8n -d n8n -c "
SELECT tablename, pg_size_pretty(pg_total_relation_size(tablename::text)) AS size
FROM pg_tables WHERE schemaname = 'public'
ORDER BY pg_total_relation_size(tablename::text) DESC
LIMIT 10;
"

ถ้าตาราง execution_entity หรือ workflow_statistics ใหญ่มาก แสดงว่า pruning ยังไม่ได้เปิดหรือยังไม่ทำงาน

ตรวจสอบ Slow Workflows

ใช้ n8n’s built-in execution timing เพื่อหา node ที่ช้า:

  1. เปิด workflow
  2. คลิก Execute Workflow แบบ manual
  3. คลิกที่แต่ละ node แล้วดูเวลาที่ใช้ใน panel ขวา
  4. Node ไหนใช้เวลานาน ลองดูว่าสามารถ optimize ได้ไหม เช่น ลด payload size หรือใช้ filter ก่อน process

อยากเรียน n8n แบบเป็นระบบ ตั้งแต่เริ่มต้นจนสร้าง Workflow ใช้งานจริงได้ ลองดู คอร์สสอน n8n ที่ aiunlock.co

Related posts