n8n "JavaScript heap out of memory" hatası mı veriyor? İşte NODE_OPTIONS, dosya sistemi modu ve execution pruning ile çözümü.
n8n'de "JavaScript heap out of memory" hatası, bir workflow çalıştırmasının n8n'in Node.js sürecinin sahip olduğundan daha fazla belleğe ihtiyaç duyması durumunda ortaya çıkar. En yaygın nedenler büyük ikili (binary) dosyalar, kapsamlı JSON veri miktarları, Code node'u ve n8n'in arayüz için ek olarak verilerin bir kopyasını tuttuğu manuel çalıştırmalardır. Sorun, NODE_OPTIONS ortam değişkeni üzerinden --max-old-space-size parametresiyle n8n sürecine daha fazla bellek tanımlanarak, ikili veri işlemenin dosya sistemi moduna geçirilmesiyle ve eski çalıştırma verilerini otomatik olarak silen düzenli execution pruning ile çözülebilir. Güncelleme tarihi: Temmuz 2026.
Hata, n8n'in bir Node.js uygulaması olarak varsayılan olarak V8 motorunun sözde heap boyutu için yalnızca sınırlı miktarda bellek kullanmasından ve bu sınırın bellek yoğun workflow'larda aşılmasından kaynaklanır.
n8n'in resmi dokümantasyonuna göre bellek sorunlarının giderilmesi konusunda, bir çalıştırmanın bellek ihtiyacı özellikle JSON veri miktarına, ikili veri boyutuna, eş zamanlı çalıştırma sayısına ve Code node kullanımına bağlıdır. Editör üzerinden yapılan manuel çalıştırmalar da tüketimi artırır, çünkü n8n bu sırada frontend'deki canlı görünüm için ek olarak verilerin bir kopyasını tutar.
Node.js sürecine NODE_OPTIONS ortam değişkeni üzerinden megabayt cinsinden daha yüksek bir bellek sınırıyla --max-old-space-size parametresini vererek kullanılabilir belleği artırırsınız.
Dokümantasyona göre, bir "JavaScript heap out of memory" hatasında V8 motorunun sözde eski bellek (old memory) alanını, ister komut satırı üzerinden ister NODE_OPTIONS üzerinden büyütmek faydalıdır. Kendi barındırdığınız (self-hosted) örnekler için bu pratikte şu anlama gelir: örneğin sürece yaklaşık dört gigabayt eski heap belleği tanımlamak için NODE_OPTIONS'ı --max-old-space-size=4096 değeriyle ayarlarsınız ve ardından n8n'i yeniden başlatırsınız. Önemli olan şudur: bu ayar yalnızca sunucuda veya container'da gerçekten yeterli fiziksel bellek mevcutsa etkili olur. Bu yeterli değilse dokümantasyon, örneği genel olarak daha fazla kaynakla donatmanızı veya n8n Cloud'da daha büyük bir plan seçmenizi önerir.
n8n, dosyalar, resimler veya PDF'ler gibi ikili verileri varsayılan olarak doğrudan bellekte tutar, bu nedenle bellek modunu dosya sistemine geçirmezseniz büyük dosyalar hızla çökmelere yol açar.
Dokümantasyona göre ikili veri işleme konusunda, n8n ikili verileri varsayılan olarak bellekte saklar, bu da büyük dosyalarda çökmelere yol açabilir. N8N_DEFAULT_BINARY_DATA_MODE ortam değişkeni ile mod filesystem olarak değiştirilebilir, böylece n8n verileri bunun yerine diske yazar. Dokümantasyona göre queue modunda dosya sistemi modu desteklenmez, bunun yerine orada veritabanı modu kullanılır. Bilinmesi gereken önemli bir nokta: ikili verilerin temizlenmesi de her seferinde etkin olan depolama modeline bağlıdır. Modu değiştirdiğinizde, eski veriler manuel olarak kaldırılana kadar önceki depolama konumunda kalır.
Execution pruning, veritabanı ve belleğin kontrolsüz bir şekilde büyümemesi için tamamlanan çalıştırmaları ve ilgili çalıştırma ile ikili verileri yaşa veya sayıya göre otomatik olarak siler.
Dokümantasyona göre çalıştırma verilerinin yönetimi konusunda, pruning varsayılan olarak etkindir ve bir çalıştırma EXECUTIONS_DATA_MAX_AGE değerinden (varsayılan: 336 saat, yani 14 gün) daha eski olduğunda veya toplam çalıştırma sayısı EXECUTIONS_DATA_PRUNE_MAX_COUNT değerini (varsayılan: 10.000) aştığında devreye girer. Çalışmakta olan, bekleyen veya yeni çalıştırmalar ile etiketli veya değerlendirilmiş çalıştırmalar bu sırada asla silinmez. Ayrıca EXECUTIONS_DATA_HARD_DELETE_BUFFER değişkeni (varsayılan: bir saat) üzerinden bir güvenlik tamponu, arka planda bellek boşaltılırken yakın zamanda tamamlanmış çalıştırmaları hâlâ görüntüleyebilmenizi sağlar.
Sunucu tarafındaki ayarların yanı sıra, verileri tek seferde yüklemek yerine daha küçük parçalar hâlinde işleyerek bellek ihtiyacını en etkili şekilde doğrudan workflow tasarımında azaltırsınız.
n8n dokümantasyonu somut olarak, verileri daha küçük bloklara ayırmanızı, örneğin çalıştırma başına 10.000 yerine 200 kayıt işlemenizi, mümkün olduğunca Code node'undan kaçınmanızı ve büyük veri miktarlarında manuel yerine bir tetikleyici (trigger) üzerinden çalıştırmanızı önerir. Çok büyük veri miktarları için dokümantasyon, yalnızca mevcut grubun verilerinin bellekte tutulup ardından tekrar serbest bırakılması için workflow'u Loop Over Items node'u ve Execute Workflow node'u ile alt workflow'lara ayırmayı önerir. n8n'i daha karmaşık otomasyonlar için üretimde kullanıyorsanız ve bu ayarları kendiniz yeniden oluşturmak istemiyorsanız, NordFlux size uygun sunucu yapılandırması dahil n8n workflow'larının kurulumu ve güvence altına alınması konusunda destek olur.
Dokümantasyon sabit bir minimum değer belirtmez, bunun yerine ihtiyacın veri miktarına ve paralel çalıştırma sayısına bağlı olduğunu belirtir. Pratikte, NODE_OPTIONS üzerinden ayarlanan max-old-space-size'ın fiziksel olarak da karşılanması için yeterli bellek sağlamalısınız, aksi takdirde sorun yalnızca ötelenir.
Hayır, daha yüksek bir heap sınırı yalnızca daha fazla tampon sağlar, ancak verimsiz workflow'lar veya kontrolsüz büyüyen ikili veriler gibi asıl nedeni ortadan kaldırmaz. Dokümantasyona göre, bellek ihtiyacının kalıcı olarak kontrol altında kalması için çalıştırma başına veri miktarını da azaltmalı ve execution pruning'i etkin tutmalısınız.
Pruning olmadan, tamamlanan çalıştırmalar ile çalıştırma ve ikili veriler veritabanında sınırsız şekilde birikir. Dokümantasyona göre bu, uzun vadede artan bellek tüketimine yol açar, bu nedenle n8n temizlemeyi varsayılan olarak etkinleştirir.
Çünkü editör üzerinden yapılan manuel bir çalıştırmada n8n, frontend'deki canlı görünüm için ek olarak çalıştırma verilerinin bir kopyasını tutar. Büyük veri miktarlarında bu, bellek ihtiyacını belirgin şekilde artırır, bu nedenle dokümantasyon kapsamlı işlemlerin manuel yerine bir tetikleyici üzerinden başlatılmasını önerir.
NordFlux, kuruluşlar için dijital çalışanlar kurar: tekrar eden işleri üstlenen otomasyonlar ve KI ajanları. Kontrol sizde kalır.
Bir n8n ajanının sohbet geçmişini neden unuttuğu, oturum anahtarlarının nasıl çalıştığı ve Simple Memory ya da Postgres Memory'nin ne zaman doğru seçim olduğu.
n8n'de bir yapay zeka (YZ) ajanını dört yapı taşından oluşturursunuz: tetikleyici, sohbet modeli, hafıza ve araçlar. Pratik ipuçları ve tipik hatalarla rehber.
n8n AI Agent node'unda en sık görülen hataların toplandığı sayfa: prompt, rate limit, memory ve Output Parser hataları tek bakışta, n8n dokümantasyonuna bağlantılarla birlikte.
NODE_OPTIONS, ikili verilerin ele alınışı ve düzgün execution pruning, n8n'in yük altında kararlı kalıp kalmayacağını ya da tekrar tekrar "JavaScript heap out of memory" ile çökmeye devam edip etmeyeceğini belirler. NordFlux, kaynak boyutlandırma, bellek izleme ve execution pruning dahil olmak üzere n8n için yönetilen işletim hizmeti sunar; böylece büyüyen workflow'lar kesinti riskine dönüşmez. İlk görüşmede sunucu kaynaklarınızı analiz eder ve belleği en çok tüketen workflow'larınızı belirleriz.
