n8n ஏன் அடிக்கடி offline ஆகிறது? காரணங்களும் தீர்வுகளும்

n8n ஏன் offline ஆகிறது: நான்கு தோல்விகள், ஒரு அறிகுறி

"n8n தொடர்ந்து offline ஆகிறது" என்பது நான்கு வெவ்வேறு தோல்விகளைக் குறிக்கும் ஒரு வாக்கியமாகும், ஒவ்வொன்றிற்கும் வெவ்வேறு தீர்வுகள் தேவை. container சாதாரணமாக இயங்கிக்கொண்டிருக்கும்போது, editor ஒரு connection lost banner-ஐக் காட்டுகிறது. container தானாகவே restart ஆகிறது. அதிகப்படியான memory-ஐப் பயன்படுத்துவதால், kernel ஆனது Node.js process-ஐக் கொல்கிறது (kill). அல்லது process-ல் எந்தப் பிரச்சினையும் இல்லை, ஆனால் ஒரு active workflow ஒருபோதும் இயங்கவில்லை. தவறான அமைப்பை மாற்றினால், உங்களுக்கு இல்லாத ஒரு சிக்கலுக்காக நீங்கள் வார இறுதி முழுவதையும் செலவிட நேரிடும்.

எனவே, எந்தவொரு configuration-ஐயும் மாற்றும் முன், உங்களுக்கு என்ன தோல்வி ஏற்பட்டுள்ளது என்பதைக் கண்டறியவும். n8n ஒரு ஒற்றை Node.js process-ஆக, வழக்கமாக ஒரு Docker container-க்குள், TLS (transport layer security)-ஐ முடிக்கும் reverse proxy-க்கு பின்னால் இயங்குகிறது. அந்த அடுக்குகளில் ஒவ்வொன்றும் அதன் சொந்த வழியில் செயலிழக்கின்றன, ஆனால் browser அவை அனைத்தையும் ஒரே செய்தியைக் கொண்டு காட்டுகிறது.

இந்த வரிசையில் கண்டறியவும்

VPS (virtual private server)-ல் இந்த commands-ஐ இயக்கி, உங்கள் machine காட்டும் மதிப்புகளைப் படிக்கவும். அவற்றை forum thread-ல் உள்ள எண்களுடன் ஒப்பிட வேண்டாம். இங்கே முக்கியமான மதிப்புகள் உங்கள் server-ஐப் பற்றியவை, மற்றவர்களுடையவை அல்ல.

docker ps -a --filter name=n8n
docker logs --tail 200 --timestamps n8n
docker inspect n8n | grep -iE 'Status|Running|RestartCount|OOMKilled|ExitCode'
docker stats --no-stream

docker ps -a-ன் STATUS column, container அதன் தற்போதைய நிலையில் எவ்வளவு காலம் உள்ளது என்பதைக் காட்டுகிறது. உங்கள் சிக்கல் தொடங்கிய நேரத்துடன் இதை ஒப்பிட்டுப் பார்க்கவும். banner தோன்றுவதற்கு நீண்ட காலத்திற்கு முன்பே container இயங்கிக்கொண்டிருந்தால், n8n offline-க்குச் செல்லவில்லை என்று அர்த்தம். உங்கள் browser-க்கும் backend-க்கும் இடையிலான இணைப்பில் தான் சிக்கல் உள்ளது; இது அடுத்த பகுதியில் விவரிக்கப்பட்டுள்ள websocket path ஆகும்.

RestartCount என்பது Docker இந்த container-ஐ எத்தனை முறை restart செய்துள்ளது என்பதைக் குறிக்கிறது. அந்த எண்ணைக் குறித்துக் கொண்டு, ஒரு நிமிடம் காத்திருந்து மீண்டும் சரிபார்க்கவும். நீங்கள் கவனிக்கும்போது அந்த எண் அதிகரித்துக் கொண்டே இருந்தால், அது restart loop-ல் உள்ளது என்று அர்த்தம். ஒவ்வொரு restart-க்கு முன்பும் உள்ள log வரிகள் அதற்கான காரணத்தைக் கொண்டிருக்கும்.

OOMKilled என்பது true அல்லது false என்ற flag ஆகும். True என்றால், memory limit-ஐத் தாண்டியதால் Linux kernel அந்த process-ஐக் கொன்றுவிட்டது என்று பொருள். இது container-ன் சொந்த limit-ஆகவோ அல்லது முழு machine-ன் limit-ஆகவோ இருக்கலாம். இந்த ஒரு field, memory kill-ஐ மற்ற அனைத்து exit வகைகளிலிருந்தும் பிரித்துக் காட்டுகிறது; எனவேதான் எதையும் ஊகிக்கும் முன் இதை முதலில் பார்க்க வேண்டும்.

ExitCode என்பது உங்கள் container கடைசியாக எந்தக் குறியீட்டுடன் (exit code) வெளியேறியது என்பதைக் காட்டுகிறது. ஒவ்வொரு குறியீடும் எதைக் குறிக்கிறது என்பதை நீங்கள் மனப்பாடம் செய்ய வேண்டியதில்லை. உங்கள் குறியீட்டைப் படித்துவிட்டு, அதே timestamp-ல் உள்ள docker logs-ன் முடிவைப் படிக்கவும். log tail மற்றும் out of memory flag ஆகிய இரண்டும் சேர்ந்துதான் என்ன நடந்தது என்பதைத் தெளிவுபடுத்தும்; தனித்தனியாகப் பார்த்தால் தவறான முடிவுக்கு வரக்கூடும்.

docker stats, நடைமுறையில் உள்ள limit-க்கு அருகில் தற்போதைய memory பயன்பாட்டைக் காட்டுகிறது. இதை ஒரு இரண்டாவது terminal-ல் இயங்கவிட்டு, சிக்கலை ஏற்படுத்தும் workflow-ஐத் தூண்டி, தோல்வி ஏற்படும்போது அந்த எண் எவ்வாறு மாறுகிறது என்பதைக் கவனிக்கவும்.

இணைப்பு துண்டிக்கப்பட்டதற்கான அறிவிப்பு பொதுவாக உங்கள் reverse proxy-ஆல் ஏற்படுகிறது

n8n editor, backend-உடன் ஒரு நீண்ட கால push இணைப்பைத் திறந்து வைத்திருக்கும். அப்போதுதான் execution progress-ஐ canvas-ல் stream செய்ய முடியும். முன்னிருப்பாக அந்த இணைப்பு ஒரு WebSocket ஆகும். இதைத்தான் N8N_PUSH_BACKEND தேர்ந்தெடுக்கிறது, இதன் முன்னிருப்பு மதிப்பு websocket ஆகும். ஒரு WebSocket, Connection: Upgrade மற்றும் Upgrade: websocket ஆகிய headers-ஐக் கொண்ட சாதாரண HTTP கோரிக்கையாகத் தொடங்குகிறது. சர்வர் 101 Switching Protocols என்று பதிலளிக்கிறது, அதன் பிறகு இரு தரப்பும் ஒரே TCP socket-ஐ இரு திசைகளிலும் பயன்படுத்துகின்றன.

இரண்டு காரணங்களால் இது தடைபடலாம், இவை இரண்டுமே n8n-ல் அல்லாமல் proxy-ல் நிகழ்கின்றன. ஒன்று, proxy ஆனது upstream-க்கு HTTP/1.0-ஐப் பயன்படுத்துகிறது அல்லது upgrade headers-ஐ நீக்கிவிடுகிறது; இதனால் upgrade நிகழாமல் editor மீண்டும் மீண்டும் இணைக்க முயல்கிறது. அல்லது, upgrade வெற்றிகரமாக நடந்தும், proxy அந்த socket-ஐ மூடிவிடுகிறது. ஏனெனில், எந்தத் தகவலும் பரிமாறப்படாத WebSocket, செயலற்ற இணைப்பாகத் (idle connection) தோன்றும். இரண்டு சூழல்களிலும் container ஆரோக்கியமாகவே இருக்கும். உங்கள் browser-ன் இணைப்புத் தடம் துண்டிக்கப்பட்டதைத்தான் அந்த அறிவிப்பு காட்டுகிறது.

எதையும் மாற்றும் முன் browser-ல் இதை உறுதிப்படுத்தவும். Developer tools-ஐத் திறந்து, Network tab-க்குச் சென்று, WS என்று filter செய்து, editor-ஐ reload செய்யவும். அந்த push கோரிக்கை 101 Switching Protocols-ஐ அடைந்து திறந்த நிலையிலேயே இருக்க வேண்டும். ஒரு push கோரிக்கை சாதாரண status code-ஐத் திரும்பத் தந்தாலோ அல்லது சில வினாடிகளுக்கு ஒருமுறை மீண்டும் தோன்றினாலோ, அது proxy-ல் சிக்கல் இருப்பதைக் குறிக்கிறது.

எடிட்டரை இணைப்பில் வைத்திருக்கும் nginx அமைப்புகள்

நீங்கள் கோரினால் ஒழிய, nginx ஒரு upgrade கோரிக்கையை முன்னோக்கி அனுப்பாது. proxy_pass இயல்பாகவே backend-உடன் HTTP/1.0 முறையில் பேசும், மேலும் Connection மற்றும் Upgrade ஆகியவை hop-by-hop headers ஆகும்; இவற்றை nginx வழியில் நீக்கிவிடும். நீங்கள் இவை இரண்டையும் மீண்டும் சேர்க்க வேண்டும். map தொகுதி http சூழலில் இருக்க வேண்டும், server உள்ளே இருக்கக்கூடாது.

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    listen 443 ssl;
    http2 on;
    server_name n8n.example.com;

    location / {
        proxy_pass http://127.0.0.1:5678;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
        proxy_buffering off;
    }
}

proxy_read_timeout என்பது மக்கள் விடுபடும் வரியாகும். இதன் இயல்புநிலை 60 வினாடிகள், இது மேம்படுத்தப்பட்ட WebSocket-க்கும் பொருந்தும். எனவே, அமைதியான instance-ல் திறந்து வைக்கப்பட்டிருக்கும் எடிட்டர் தாவல், கடைசி செய்தி பரிமாறப்பட்ட ஒரு நிமிடத்திற்குப் பிறகு இணைப்பை இழந்துவிடும். இதை அதிகரிப்பதே, நீங்கள் மீண்டும் தாவலுக்குத் திரும்பும்போது தோன்றும் பிழைச் செய்தியைச் சரிசெய்யும்.

sudo nginx -t && sudo systemctl reload nginx
sudo nginx -T | grep -iE 'proxy_http_version|upgrade|proxy_read_timeout'

nginx -T என்பது ஒரு கோப்பை மட்டும் காட்டாமல், இயங்கிக்கொண்டிருக்கும் முழு configuration-ஐயும் அச்சிடும். எனவே, உங்கள் திருத்தம் உண்மையில் ஏற்றப்பட்டுள்ளதா என்பதை இது உறுதிப்படுத்தும். எந்த include வரியாலும் எடுக்கப்படாத ஒரு கோப்பில் இருக்கும் config, சரியான திருத்தம் செய்தும் எந்த மாற்றமும் ஏற்படாததற்குக் காரணமாகும்.

பிறகு, n8n ஒரு proxy-க்கு பின்னால் இயங்குகிறது என்பதை அதற்குத் தெரிவிக்கவும், ஏனெனில் அது இந்த மதிப்புகளைக் கொண்டே URL-களை உருவாக்குகிறது.

environment:
  - N8N_HOST=n8n.example.com
  - N8N_PROTOCOL=https
  - N8N_PORT=5678
  - N8N_PROXY_HOPS=1
  - N8N_WEBHOOK_URL=https://n8n.example.com/

N8N_PROXY_HOPS இயல்பாக 0 என இருக்கும், அதாவது n8n இணைக்கும் முகவரியையே client முகவரியாகக் கருதி X-Forwarded-For-ஐப் புறக்கணிக்கும். இதை container-க்கு முன்னால் உள்ள proxy-களின் எண்ணிக்கைக்கு ஏற்ப அமைக்கவும். ஆகஸ்ட் 2026 நிலவரப்படி, N8N_WEBHOOK_URL என்பதே தற்போதைய பெயராகும்; பழைய WEBHOOK_URL இப்போதும் வேலை செய்யும், ஆனால் தொடக்கத்தின்போது அது deprecation எச்சரிக்கையை அச்சிடும்.

Traefik WebSocket-களை forward செய்கிறது, ஆனால் அவற்றை காலாவதியாக்குகிறது (timeout)

Traefik எந்த middleware-ம் மற்றும் கூடுதல் labels-ம் இல்லாமல் WebSocket upgrade-ஐ forward செய்கிறது. எனவே, இந்த பிழையை எதிர்கொள்ளும் Traefik பயனர், விடுபட்ட header-ஆல் அல்லாமல், பெரும்பாலும் timeout-ஆல் பாதிக்கப்படுகிறார். இதற்கான கட்டுப்பாடுகள் entryPoint-ல் உள்ளன. ஆகஸ்ட் 2026 நிலவரப்படி, Traefik v3-ல் idleTimeout இயல்பாக 180 வினாடிகளாகவும், readTimeout இயல்பாக 60 வினாடிகளாகவும் அமைக்கப்பட்டுள்ளன.

entryPoints:
  websecure:
    address: ":443"
    transport:
      respondingTimeouts:
        readTimeout: 0
        idleTimeout: 3600s

Caddy, reverse_proxy-ல் upgrade-ஐ தானாகவே கையாளுகிறது, இதற்கு எந்தவொரு directive-ம் தேவையில்லை. ஒருவேளை உங்களால் proxy-ஐ மாற்ற முடியாவிட்டால், அல்லது அது வேறொருவரின் கட்டுப்பாட்டில் இருந்தால், N8N_PUSH_BACKEND=sse-ஐப் பயன்படுத்தி push channel-ஐ மாற்றவும். SSE (server-sent events) என்பது திறந்த நிலையில் வைக்கப்படும் ஒரு சாதாரண HTTP response ஆகும். எனவே, upgrade-ஐ மறுக்கும் proxy-யிலும் இது செயல்படும், இருப்பினும் மிகக் கடுமையான idle timeout இதைத் துண்டிக்கக்கூடும். எந்த proxy-ஐத் தேர்ந்தெடுப்பது என்பது தனிப்பட்ட முடிவு, மேலும் Nginx, Caddy மற்றும் Traefik ஒப்பீடு ஒவ்வொன்றையும் இயக்குவதற்கான செலவுகள் மற்றும் தேவைகளை விளக்குகிறது.

Container மீண்டும் மீண்டும் restart ஆகும்போது

RestartCount அதிகரித்தால், container தோல்வியடைகிறது மற்றும் Docker அதை மீண்டும் தொடங்குகிறது. Log-ல் உள்ள நேர முத்திரைகளை (timestamps) ஒவ்வொரு restart நேரத்துடனும் ஒப்பிட்டு, அதற்கு முன்னால் என்ன பிழை பதிவாகியுள்ளது என்பதைப் பார்க்கவும். பெரும்பாலும் நான்கு காரணங்களே இதற்குப் பொறுப்பாகும்: startup-ஐத் தடுக்கும் configuration பிழை, n8n அணுக முடியாத database, இயங்கிக்கொண்டிருக்கும்போது ஏற்படும் crash, மற்றும் memory பற்றாக்குறையினால் ஏற்படும் kill.

முதலில் volume-ஐச் சரிபார்க்கவும், ஏனெனில் அனுமதி (permissions) தொடர்பான சிக்கல்கள் பெரும்பாலும் கவனிக்கப்படாமல் போகும். அதிகாரப்பூர்வ image, privileged அல்லாத node பயனர் மூலம் இயங்குகிறது மற்றும் அதன் தரவுகளை /home/node/.n8n-ல் சேமிக்கிறது. Root மூலம் உருவாக்கப்பட்ட bind mount-க்கு அந்தப் பயனரால் எழுத முடியாது, எனவே ஒவ்வொரு முறையும் startup-ல் process நின்றுவிடும்; restart policy இந்தச் சுழற்சியை மறைத்துவிடும்.

docker compose config
docker run --rm -it --entrypoint sh docker.n8n.io/n8nio/n8n -c 'id'
docker exec n8n ls -ld /home/node/.n8n

Named volume-ஐப் பயன்படுத்துவது இந்தச் சிக்கலை முழுமையாகத் தவிர்க்கும், ஏனெனில் Docker அதைச் சரியான உரிமையுடன் (ownership) உருவாக்குகிறது. நீங்கள் bind mount-ஐப் பயன்படுத்த வேண்டியிருந்தால், முதல் கட்டளை வெளியிட்ட numeric user id-க்கு host directory-ஐ chown செய்யவும். Host மற்றும் container-க்கு இடையிலான ownership mapping-ஐப் புரிந்துகொள்வது அவசியம், மேலும் PUID மற்றும் PGID விளக்கம் இந்த images கோப்புகளை யார் எழுதுவது என்பதை எவ்வாறு தீர்மானிக்கின்றன என்பதை விளக்குகிறது.

நினைவகப் பற்றாக்குறையினால் ஏற்படும் 'OOM kill' மற்றும் அதன் விளைவுகள்

n8n process-க்கு மேலே இரண்டு வெவ்வேறு நினைவக உச்சவரம்புகள் (memory ceilings) உள்ளன, இவை வெவ்வேறு விதமாகச் செயல்படுகின்றன. Container control group வரம்பு kernel-ஆல் அமல்படுத்தப்படுகிறது: இதைத் தாண்டினால் process உடனடியாகக் கொல்லப்படும், எதையும் எழுதுவதற்கு வாய்ப்பு இருக்காது, மேலும் OOMKilled என்பது true என்று காட்டும். V8 heap வரம்பு Node.js-க்குள் அமல்படுத்தப்படுகிறது: இதைத் தாண்டினால் Node ஒரு heap error-ஐ stack trace-உடன் உருவாக்கி தானாகவே வெளியேறும், எனவே OOMKilled என்பது false என்று காட்டும். Browser-ல் இருந்து பார்க்கும்போது இவை இரண்டும் ஒரே மாதிரியாகத் தெரியும். docker inspect-ல் இருந்து பார்க்கும்போது, இவை ஒரு field இடைவெளியில் இருக்கும்.

Node heap வரம்பை container வரம்பை விடக் குறைவாக அமைக்கவும். Heap வரம்பு இரண்டிலும் அதிகமாக இருந்தால், kernel தலையிடும் புள்ளிக்கு அப்பாலும் V8 நினைவகத்தை ஒதுக்கிக்கொண்டே இருக்கும். இதனால் அதன் garbage collector தனது சொந்த வரம்பை அடையாது, மேலும் உங்களுக்கு எந்த log-உம் கிடைக்காமல் கடுமையான தோல்வி மட்டுமே ஏற்படும்.

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: unless-stopped
    environment:
      - NODE_OPTIONS=--max-old-space-size=<MiB, below the container limit>
    deploy:
      resources:
        limits:
          memory: <your container limit>

உங்கள் VPS-ல் உண்மையில் எவ்வளவு நினைவகம் உள்ளதோ அதற்கேற்ப இரண்டு எண்களையும் தேர்வு செய்யவும்; database, proxy மற்றும் operating system ஆகியவற்றுக்குத் தேவையான நினைவகத்தை ஒதுக்கி வைக்கவும். docker stats --no-stream தற்போதைய பயன்பாட்டையும் நடைமுறையில் உள்ள வரம்பையும் பக்கவாட்டில் அச்சிடும், எனவே நீங்கள் குறிப்பிட்ட வரம்பு Docker-ஆல் சரியாகப் பயன்படுத்தப்பட்டுள்ளதா என்பதைச் சரிபார்க்கலாம். Compose memory வரம்புகள் எவ்வாறு அமல்படுத்தப்படுகின்றன என்பதில், பல வரம்புகள் அமைக்கப்படும்போது எந்த key முன்னுரிமை பெறும் என்பது விளக்கப்பட்டுள்ளது.

செயல்பாட்டுத் தரவு (Execution data) என்பது உங்கள் கட்டுப்பாட்டிற்கு அடியில் வளர்ந்து கொண்டே இருக்கும் ஒன்று

ஒரு workflow இயங்கிக்கொண்டிருக்கும்போது, ஒவ்வொரு node-ன் வெளியீட்டையும் அந்த ஒற்றை execution வைத்திருக்கும்; பின்னர் n8n அந்தத் தரவைச் சேமிக்கும். இதனால் இரண்டு விளைவுகள் ஏற்படுகின்றன. ஒரு run-ன் உச்சகட்ட நினைவகப் பயன்பாடு (peak memory), நீங்கள் அதன் வழியாகச் செலுத்தும் மிகப்பெரிய தரவுத் தொகுப்பால் தீர்மானிக்கப்படுகிறது. எனவே, பத்தாயிரம் வரிசைகளை ஒரே நேரத்தில் கையாளும் workflow-ம், இருநூறு வரிசைகளை மட்டும் கையாளும் அதே workflow-ம் வெவ்வேறு நிரல்களாகவே கருதப்படும். மேலும், சேமிக்கப்பட்ட நகல் ஏதேனும் ஒன்றால் நீக்கப்படும் வரை வளர்ந்துகொண்டே இருக்கும்.

Pruning என்பது இரண்டாவது சிக்கலைத் தீர்க்கிறது. ஆகஸ்ட் 2026 நிலவரப்படி, இயல்புநிலை அமைப்புகள் pruning-ஐச் செயல்படுத்தியுள்ளன. EXECUTIONS_DATA_MAX_AGE 336 மணிநேரமாகவும் (14 நாட்கள்), EXECUTIONS_DATA_PRUNE_MAX_COUNT 10000 ஆகவும் உள்ளன. SQLite-ஐ இயக்கும் ஒரு சிறிய VPS-க்கு இவை தாராளமானவை; ஏனெனில், அங்கு ஒரே கோப்பு அனைத்தையும் வைத்திருக்கிறது மற்றும் editor-ஐ வழங்கும் அதே process-தான் அதைப் படிக்கவும் எழுதவும் வேண்டும்.

environment:
  - EXECUTIONS_DATA_PRUNE=true
  - EXECUTIONS_DATA_MAX_AGE=72
  - EXECUTIONS_DATA_PRUNE_MAX_COUNT=1000
  - EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
  - EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS=false

EXECUTIONS_DATA_SAVE_ON_SUCCESS=none என்பது ஒரு தீவிரமான அமைப்பாகும். இது தோல்வியடைந்த execution-களை பிழைத்திருத்தத்திற்காக (debugging) வைத்துக்கொண்டு, வெற்றிகரமானவற்றை நீக்கிவிடும். இதைத் திட்டமிட்டு முடிவு செய்யுங்கள்; ஏனெனில், பிழையை எழுப்பாமல் தவறான வெளியீட்டைத் தரும் ஒரு workflow-ஐ ஆய்வு செய்ய உங்களிடம் தரவுகள் ஏதும் இருக்காது. Pruning முதலில் வரிசைகளை நீக்கப்பட்டதாகக் குறிக்கும், பின்னர் ஒரு கட்டத்தில் அவற்றை அகற்றும். SQLite விடுவிக்கப்பட்ட பக்கங்களை (freed pages) மீண்டும் பயன்படுத்தும், அவற்றை உடனே திருப்பித் தராது. எனவே, நீங்கள் அமைப்பை மாற்றிய உடனேயே வட்டில் உள்ள கோப்பின் அளவு குறையாது.

சேமிக்கப்பட்ட மொத்தத் தரவைக் குறைப்பதற்குப் பதிலாக, உச்சகட்ட அளவைக் குறைக்க, ஒவ்வொரு run-லும் குறைவான தரவைச் செலுத்துங்கள். பெரிய பணிகளைச் சிறிய sub-workflow-களாகப் பிரித்து, அவை சிறிய முடிவுகளை parent-க்குத் தருமாறு செய்யுங்கள். Loop Over Items node மூலம் batch செய்யுங்கள், மேலும் முழுமையான தரவுத் தொகுப்புகளை Code node-க்குள் வைக்காதீர்கள்.

Binary கோப்புகள் நினைவகத்தின் (memory) வழியாகச் செல்லக்கூடாது

N8N_DEFAULT_BINARY_DATA_MODE இயல்பாக default என அமையும், இது இயங்கும் execution-ன் நினைவகத்தில் binary தரவுகளை வைத்திருக்கும். ஒரு node பதிவிறக்கும் ஒவ்வொரு கோப்பும், அடுத்த node-க்கு அனுப்பப்படும் ஒவ்வொரு நகலும், run முடியும் வரை அங்கேயே இருக்கும். சில பெரிய இணைப்புகளைப் (attachments) பெறும் ஒரு workflow, சாதாரண JSON வேலைகள் நெருங்க முடியாத அளவுக்கு நினைவக வரம்பைத் தாண்டிச் செல்லச் செய்யும். இதனால்தான், குறிப்பிட்ட நேரத்தை விட, ஒரு குறிப்பிட்ட workflow-க்கு பிறகு crash ஏற்படுகிறது.

environment:
  - N8N_DEFAULT_BINARY_DATA_MODE=filesystem

filesystem மூலம், binary தரவுகள் N8N_BINARY_DATA_STORAGE_PATH-ன் கீழ் எழுதப்படுகின்றன. இது இயல்பாக n8n பயனர் கோப்புறையில் (user folder) இருப்பதால், மற்ற அனைத்தையும் போலவே அதே volume-ல் அமையும். நீங்கள் மாறுவதற்கு முன்பு அந்த volume-ல் போதுமான இடம் உள்ளதா என்று சரிபார்க்கவும். N8N_PAYLOAD_SIZE_MAX என்பது உள்வரும் webhook payload-ன் அதிகபட்ச அளவை MiB-ல் (mebibytes) நிர்ணயிக்கும், இதன் இயல்பு மதிப்பு 16 ஆகும். இதை அதிகரிப்பது பெரிய கோரிக்கைகளை அனுமதிக்கிறது, ஆனால் இது நினைவகச் செலவை (memory cost) நீங்கள் ஏற்றுக்கொள்வதாக அமையும்.

அந்த server-ல் இயங்கும் மற்ற அனைத்தும் அதே RAM-க்காகப் போட்டியிடும். நீங்கள் ஒரு database container-ஐச் சேர்த்தபோது OOM kills தொடங்கினால், database-ஐ Docker-ல் அல்லது host-ல் இயக்குவது நீங்கள் இப்போது மேற்கொள்ள வேண்டிய சமரசமாகும்.

Restart policy மற்றும் reboot-க்கு பிறகு மீண்டும் தொடங்குதல்

Restart policy இல்லாத ஒரு container, அது வெளியேறிய பிறகோ அல்லது host reboot செய்யப்பட்ட பிறகோ மீண்டும் இயங்காது. restart: unless-stopped, இந்த இரண்டு சூழல்களிலும் container-ஐ மீண்டும் இயக்கும், அதே சமயம் நீங்கள் கைமுறையாக நிறுத்திய container-ஐ இது பாதிக்காது. restart: always, நீங்கள் வேண்டுமென்றே நிறுத்திய container-ஐயும் Docker அடுத்த முறை தொடங்கும் போது மீண்டும் இயக்கும்.

n8n ஒரு health endpoint-ஐ வழங்குகிறது, இது N8N_ENDPOINT_HEALTH என்று அழைக்கப்படுகிறது, இதன் default மதிப்பு healthz ஆகும். உங்கள் instance-ல் இந்த path சரியாக உள்ளதா என்பதை உறுதிப்படுத்த, முதலில் host-லிருந்து அதைச் சரிபார்க்கவும்.

curl -fsS http://127.0.0.1:5678/healthz
docker exec n8n which wget curl
sudo systemctl is-enabled docker

Healthcheck மட்டும் எதையும் தானாக restart செய்யாது. Compose அந்த container-ஐ unhealthy என்று குறிக்கும், அதோடு நின்றுவிடும். எனவே, ஒரு healthcheck பயனுள்ளதாக இருக்க, அதற்கு ஒரு restart policy அல்லது வெளிப்புற கண்காணிப்பு கருவி (external watcher) தேவை. செயல்படக்கூடிய healthcheck-ஐ எழுதுதல் மற்றும் reboot-க்கு பிறகு stack-ஐ மீண்டும் தொடங்குதல் ஆகிய பகுதிகள் இவை இரண்டையும் விளக்குகின்றன.

n8n சரியாக இயங்கினாலும் workflow இயங்காத சூழல்

இந்தச் சூழலில் எந்த அறிவிப்பும் வராது, restart-ம் நடக்காது. Container இயங்கிக்கொண்டிருக்கும், editor வேலை செய்யும், ஆனால் executions பட்டியலில் நீங்கள் எதிர்பார்த்த run இருக்காது. இதற்கு நான்கு முக்கிய காரணங்கள் உள்ளன.

• Workflow active நிலையில் இல்லை. Schedule Trigger production பாதையில் மட்டுமே இயங்கும், எனவே canvas-ல் அதைச் சோதிக்கும்போது எதுவும் schedule ஆகாது.
• Timezone உங்களுடையது அல்ல. GENERIC_TIMEZONE இயல்பாக America/New_York-ஐக் கொண்டிருக்கும். எனவே, நீங்கள் GENERIC_TIMEZONE மற்றும் TZ ஆகியவற்றை உங்கள் timezone-க்கு மாற்றும் வரை, 09:00-க்கு அமைக்கப்படும் schedule அந்த timezone-ன் படி 09:00-க்குத்தான் இயங்கும்.
• Downtime-க்கு பிறகு விடுபட்டவை மீண்டும் இயங்காது. n8n தொடங்கும்போதே triggers பதிவு செய்யப்படும். எனவே, container restart ஆகும்போது வர வேண்டிய schedule, தாமதமாக இயங்காது. அடுத்த run, startup-க்கு பிறகு வரும் சரியான நேரத்தில்தான் நடக்கும்.
• Workflow உங்களுக்காக deactivate செய்யப்பட்டிருக்கலாம். N8N_WORKFLOW_AUTODEACTIVATION_ENABLED இயல்பாகவே off நிலையில் இருக்கும். இது on-ல் இருக்கும்போது, அடிக்கடி crash ஆகும் workflow தானாகவே unpublished நிலைக்குச் சென்றுவிடும். அதன் பிறகு, அது யாரும் activate செய்யாத workflow போலவே தோன்றும்.

Executions பட்டியலைத் திறந்து, அந்த workflow-ஐ மட்டும் filter செய்யவும். ஒரு entry தோல்வியடைந்திருந்தால், அது workflow சார்ந்த சிக்கல். எந்த entry-யும் இல்லை என்றால், அது trigger சார்ந்த சிக்கல். மேலே உள்ள நான்கு காரணங்களை முதலில் சரிபார்க்கவும்.

முதலில் எதை மாற்ற வேண்டும்

1. எந்தவொரு கோப்பையும் திருத்துவதற்கு முன், உங்கள் சொந்த container-ல் STATUS, RestartCount மற்றும் OOMKilled ஆகியவற்றை வாசிக்கவும்.
2. container ஒருபோதும் செயலிழக்கவில்லை என்றால், proxy upgrade headers மற்றும் idle timeout ஆகியவற்றைச் சரிசெய்யவும்.
3. OOMKilled என்பது true எனில், நீங்கள் கவனமாகத் தேர்ந்தெடுத்த container limit-ஐ அமைக்கவும், Node heap ceiling-ஐ அதற்கு கீழே வைக்கவும், மேலும் binary data-வை filesystem-க்கு மாற்றவும்.
4. எதுவும் செயல்படவில்லை என்றால், workflow active நிலையில் உள்ளதா என்பதையும், instance timezone உங்களுடையதாக உள்ளதா என்பதையும் சரிபார்க்கவும்.

இவை பெரும்பாலும் ஒருமுறை அமைத்துவிட்டு மறக்கக்கூடிய configuration-கள் ஆகும், இவை ஏற்கனவே இயங்கும் install-ன் மேல் செய்யப்படுபவை. நீங்கள் இன்னும் அந்த install-ஐ உருவாக்கிக்கொண்டிருக்கிறீர்கள் என்றால், HTTPS உடன் Docker-ல் n8n-ஐ நிறுவுவதற்கான வழிமுறை என்பது இந்த அமைப்புகள் சேர வேண்டிய அடிப்படை ஆகும்.

FAQ

n8n container இயங்கிக்கொண்டிருக்கும்போது, editor ஏன் connection lost என்று காட்டுகிறது?

Editor, execution progress-ஐ stream செய்ய ஒரு WebSocket-ஐத் தொடர்ந்து திறந்து வைத்திருக்கும். உங்கள் reverse proxy, Connection: Upgrade மற்றும் Upgrade: websocket headers-ஐ forward செய்யவில்லை என்றாலோ, அல்லது upstream-க்கு HTTP/1.1-ஐப் பயன்படுத்தவில்லை என்றாலோ, upgrade முழுமையடையாது. இதனால் n8n சரியாக இயங்கினாலும், browser தொடர்ந்து reconnect செய்துகொண்டே இருக்கும். Nginx-ல், proxy_http_version 1.1 மற்றும் இரண்டு proxy_set_header வரிகளும் அவசியம். மேலும், அமைதியான tab-ஐத் துண்டிக்காமல் இருக்க, default 60 வினாடிகளை விட அதிகமான proxy_read_timeout-ஐ அமைக்க வேண்டும். நீங்கள் திருத்திய கோப்பை மட்டும் பார்க்காமல், sudo nginx -T மூலம் தற்போது இயங்கும் configuration-ஐச் சரிபார்க்கவும்.

ஒரு சாதாரண crash-க்கும், memory பற்றாக்குறையால் ஏற்படும் kill-க்கும் உள்ள வித்தியாசத்தை எப்படி அறிவது?

docker inspect n8n | grep -iE 'OOMKilled|ExitCode|RestartCount' கட்டளையை இயக்கி, OOMKilled flag-ஐப் பார்க்கவும். இதன் மதிப்பு True எனில், memory limit-ஐத் தாண்டியதால் kernel அந்த process-ஐக் கொன்றுவிட்டது என்று பொருள். Process-க்கு எதையும் எழுத வாய்ப்பு கிடைக்காததால், container log-ல் பயனுள்ள தகவல்கள் இருக்காது. மதிப்பு False ஆக இருந்து, docker logs-ன் இறுதியில் heap error மற்றும் stack trace இருந்தால், Node.js அதன் சொந்த V8 heap வரம்பை எட்டி வெளியேறியுள்ளது என்று பொருள். NODE_OPTIONS=--max-old-space-size-ஐ உங்கள் container limit-க்குக் குறைவாக அமைப்பதன் மூலம், ஆதாரங்களை விட்டுச் செல்லும் இரண்டாவது வகை தோல்வியை நீங்கள் பெறலாம்.

Execution data-வை நீக்கினால், disk space உடனடியாகக் கிடைக்குமா?

இல்லை. EXECUTIONS_DATA_PRUNE பழைய execution-களை நீக்குவதற்காகக் குறிக்கும், ஆனால் EXECUTIONS_DATA_PRUNE_HARD_DELETE_INTERVAL-ல் நிர்ணயிக்கப்பட்ட கால அட்டவணையின்படி ஒரு குறிப்பிட்ட நேரத்தில்தான் அவை நீக்கப்படும். SQLite-ல், நீக்கப்பட்ட இடங்கள் filesystem-க்குத் திரும்பக் கிடைக்காமல், மீண்டும் பயன்படுத்தப்படும். எனவே, தரவுகள் நீக்கப்பட்ட பிறகும் disk-ல் கோப்பின் அளவு உடனடியாகக் குறையாது. EXECUTIONS_DATA_MAX_AGE மற்றும் EXECUTIONS_DATA_PRUNE_MAX_COUNT ஆகியவற்றை உங்கள் தேவைக்கேற்ப அமைத்துவிட்டு, உடனடியாகச் சரிபார்க்காமல் அடுத்த நாள் சரிபார்க்கவும்.

n8n restart ஆகும்போது, scheduled workflow ஏன் இயங்கவில்லை?

Process தொடங்கும்போதே n8n triggers-ஐப் பதிவு செய்யும். அது செயலிழந்திருந்த நேரத்தில் வர வேண்டிய schedules-ஐ மீண்டும் இயக்காது. எனவே, restart loop-ல் இருக்கும்போது விடுபட்ட வேலைகள் இயங்காது; அடுத்த execution, startup-க்கு பிறகு வரும் நேரத்தில்தான் நடக்கும். விடுபடக்கூடாத வேலைகள் உங்களுக்குத் தேவைப்பட்டால், webhook மூலம் வெளிப்புறத்திலிருந்து workflow-ஐ இயக்கவும். அப்போதுதான் retry logic n8n-க்கு வெளியே இருக்கும்.

n8n பதிலளிக்கவில்லை என்றால், healthcheck அதை restart செய்யுமா?

தானாகவே செய்யாது. Compose healthcheck, container-ன் நிலையை healthy அல்லது unhealthy என்று மட்டுமே குறிக்கும். Restart செய்வது restart policy-ன் வேலை. எனவே, restart: unless-stopped தான் process வெளியேறிய பிறகு container-ஐ மீண்டும் கொண்டுவரும். Docker service enabled நிலையில் இருந்தால், host reboot-க்கு பிறகும் இதுவே container-ஐத் தொடங்கும். இதை sudo systemctl is-enabled docker மூலம் உறுதிப்படுத்தவும். Unhealthy நிலையைச் சரிசெய்ய, Docker-க்கு வெளியே status-ஐக் கண்காணித்து service-ஐ restart செய்யும் ஒரு watcher தேவை.