JavaScript heap out of memory: n8n bellek sorunlarını giderme

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.

n8n neden "JavaScript heap out of memory" hatasını bildiriyor?

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.

• Büyük veri miktarları: Çalıştırma başına çok sayıda JSON nesnesi veya büyük ikili dosyalar.
• Code node: Özel JavaScript mantığı bellek tüketimini önemli ölçüde artırabilir.
• Manuel çalıştırma: Editördeki canlı görünüm için ek veri kopyası.
• Paralel çalıştırmalar: Aynı anda çalışan birden fazla workflow toplanır.

n8n'e NODE_OPTIONS üzerinden nasıl daha fazla bellek tanımlarsınız?

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.

İkili verilerden kaynaklanan bellek sorunlarını nasıl önlersiniz?

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 artan bellek tüketimine karşı nasıl yardımcı olur?

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.

• EXECUTIONS_DATA_PRUNE: Otomatik temizlemeyi etkinleştirir, varsayılan olarak etkindir.
• EXECUTIONS_DATA_MAX_AGE: Çalıştırmaları saat cinsinden yaşa göre siler, varsayılan 336.
• EXECUTIONS_DATA_PRUNE_MAX_COUNT: Depolanan toplam çalıştırma sayısını sınırlar, varsayılan 10.000.

Hangi workflow düzenlemeleri bellek ihtiyacını ek olarak azaltır?

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.

n8n bellek sorunlarıyla ilgili sık sorulan sorular

Bir n8n sunucusunda en az ne kadar bellek olmalıdır?

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.

Daha yüksek bir NODE_OPTIONS ayarı her bellek sorununu çözer mi?

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.

Execution pruning'i devre dışı bırakırsam ne olur?

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.

Hata neden özellikle manuel çalıştırmalarda ortaya çıkar?

Çü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.