Büyük İkili Veriler: 100 PDF Sunucuyu Neden Çökertir

Bir workflow'un aniden 100 PDF'i aynı anda işlemesi gerektiğinde, bu kağıt üzerinde basit bir görev gibi görünür: dosyaları okumak, metni çıkarmak, aktarmak. Uygulamada ise tam olarak bu workflow genellikle çalışma sırasında çöker, n8n konteyneri yeniden başlatılır ve günlükte sadece kuru bir "Out of memory" ifadesi yer alır. Bunun nedeni neredeyse her zaman aynı noktadadır: n8n, ikili verileri varsayılan olarak sabit diskte değil, bellekte tutar.

Tek tek dosyalarda veya küçük görsellerde bu neredeyse fark edilmez. Ancak tek bir çalıştırmada onlarca veya yüzlerce PDF, tarama ya da ek işlediğinde, her bir dosya sürecin RAM tüketimine eklenir ve bu, sunucu veya konteyner sınırına ulaşana kadar sürer. Hangi ayarı değiştirmen gerektiğini bilirsen, workflow'un kendisini yeniden yapılandırmadan bunu tekrarlanabilir şekilde önleyebilirsin. Bu makale, bellek patlamasının neden gerçekleştiğini ve doğru ikili veri modu ile bunu nasıl kontrol altına alabileceğini gösteriyor.

100 PDF Belleği Neden Taşırır

n8n, teknik olarak asıl workflow veri akışı ile bir workflow'dan geçen PDF, görsel veya Excel eki gibi dosyalardan oluşan sözde ikili veriler arasında ayrım yapar. resmi ikili veri dokümantasyonuna göre n8n bu verileri varsayılan olarak bellekte tutar; bu, küçük veri miktarlarında sorun yaratmaz ancak büyük dosyalarda veya aynı anda çok sayıda dosyada hızla performans sorunlarına yol açar. Bu konuda yerleşik bir fren yoktur: n8n ne bir workflow'un aynı anda kaç dosya tuttuğunu sınırlar, ne de yazılım bir node için otomatik olarak bellek ayırır. Bir posta kutusundan veya klasörden 100 PDF okuyup Extract-from-File node'u ile işleyen bir workflow, bu yüzden dosya dosya daha fazla bellek kullanabilir ve sonunda konteyner limitine ulaşıp çökebilir.

Tam olarak bu örüntüyü bir kullanıcı da n8n topluluk forumunda şöyle anlatıyor: Her biri 150 ila 200 ek içeren yaklaşık 2.000 kaydın taşınması sırasında, 8 GB'lık bir VPS üzerinde workflow yaklaşık 50 dosya işlendikten sonra düzenli olarak çöküyordu, çünkü varsayılan mod tüm ikili verileri RAM'de tutuyordu. Etki 100 PDF'te de 2.000 ekte olduğu gibi aynıdır, yalnızca sunucun zaten sınırlı kapasiteliyse daha hızlı fark edilir.

İkili Veri Modlarına Genel Bakış

n8n, ikili veriler için `N8N_DEFAULT_BINARY_DATA_MODE` ortam değişkeni ile kontrol edilen birden fazla depolama modu sunar:

• memory (varsayılan): Tüm dosyalar n8n sürecinin belleğinde kalır. Basittir, ancak üst sınırı yoktur.
• filesystem: n8n, ikili verileri RAM yerine sabit diske yazar. Dokümantasyona göre bu, büyük dosyalarda çökmeleri önler çünkü çalıştırma başına bellek ihtiyacı belirgin şekilde azalır.
• s3: İkili veriler, yerel sabit disk veya RAM yerine harici, S3 uyumlu bir bucket'a taşınır.
• database: Filesystem modu kullanılamadığında, örneğin queue modunda, kullanılır.

Birden fazla worker içeren kurulumlar için önemli: Dokümantasyona göre n8n, queue modunda Filesystem modunu desteklemez; ortak kullanılan bir depolama alanı yoksa bunun yerine database modu kullanılmalıdır.

Filesystem Moduna Geçiş: En Hızlı Çözüm

Çoğu tek örnekli (single-instance) kurulum için modu Filesystem olarak değiştirmek yeterlidir:

• `N8N_DEFAULT_BINARY_DATA_MODE` ortam değişkenini `filesystem` olarak ayarla.
• Değişkenin etkili olması için n8n örneğini yeniden başlat.
• Alttaki volume'ün yeterli disk alanına sahip olduğundan emin ol, çünkü artık PDF'ler RAM yerine sabit diske kaydedilecek.
• Düzenli temizlik planla, çünkü n8n ikili veri klasörünü otomatik olarak boşaltmaz; bunun yerine bunu çalıştırma verisi temizliği (execution data pruning) üzerinden yönetir.

Yukarıda bahsedilen thread'deki topluluk kullanıcısı, geçişten sonra bellek eğrisinin kalıcı olarak düşük kaldığını ve önceki ani yükselişin tamamen ortadan kalktığını belirtiyor. Art arda 100 PDF işleyen bir workflow için bu, genellikle workflow'un kendisinde herhangi bir kod değişikliği yapmadan tam çözümdür.

Filesystem Yetmediğinde S3 Modu

n8n instance'ın ayrı makinelerde birden fazla worker ile queue modunda çalışıyorsa, yerel sabit disk depolaması yalnızca sınırlı ölçüde yardımcı olur, çünkü her worker otomatik olarak aynı dosyalara erişemez. Bu durum için harici depolama dokümantasyonu S3 bağlantısını açıklar. Bu bağlantı birden fazla ortam değişkeni ile yapılandırılır:

• Hedef altyapı için `N8N_EXTERNAL_STORAGE_S3_HOST`, `N8N_EXTERNAL_STORAGE_S3_BUCKET_NAME` ve `N8N_EXTERNAL_STORAGE_S3_BUCKET_REGION`.
• Erişim bilgileri için `N8N_EXTERNAL_STORAGE_S3_ACCESS_KEY` ve `N8N_EXTERNAL_STORAGE_S3_ACCESS_SECRET`.
• Modu gerçekten etkinleştirmek için `N8N_AVAILABLE_BINARY_DATA_MODES=filesystem,s3` ve `N8N_DEFAULT_BINARY_DATA_MODE=s3`.

Bilinmesi gereken önemli bir nokta: Dokümantasyona göre S3 bağlantısı geçerli bir Enterprise lisansı gerektirir; bu lisans olmadan n8n bu modda başlamaz. Ayrıca bucket içinde eski ikili verileri otomatik olarak silen bir lifecycle policy oluşturmalısın, çünkü n8n orada kendisi temizlik yapmaz.

Temizlemeyi Unutma: Çalıştırma Verisi Temizliği

Filesystem veya S3 modu ile bile, eski çalıştırmalar hiç silinmezse depolama ihtiyacın artmaya devam eder. Çalıştırma verilerinin yönetimine ilişkin dokümantasyon bunun için aşağıdaki değişkenleri açıklar:

• `EXECUTIONS_DATA_PRUNE` otomatik temizliği etkinleştirir.
• `EXECUTIONS_DATA_MAX_AGE`, tamamlanmış bir çalıştırmanın kaç saat sonra silinebilir sayılacağını belirler; varsayılan değer 336 saat, yani 14 gündür.
• `EXECUTIONS_DATA_PRUNE_MAX_COUNT`, ayrıca depolanan çalıştırmaların maksimum sayısını sınırlar; varsayılan değer 10.000'dir.
• `EXECUTIONS_DATA_HARD_DELETE_BUFFER`, veriler kalıcı olarak kaldırılmadan önce varsayılan olarak bir saatlik bir ek bekleme süresi (koruma süresi) sağlar.

Kolayca gözden kaçan bir ayrıntı: Dokümantasyona göre temizlik her zaman yalnızca o anda aktif olan ikili veri modu üzerinde etkilidir. Yani Filesystem'den S3'e geçersen, eski dosyalar yerel sabit diskte kalabilir ve manuel olarak kaldırılmaları gerekir.

Hangi modun kurulumuna uygun olduğundan emin değilsen veya mevcut bir n8n workflow'u büyük PDF miktarlarında düzenli olarak çöküyorsa, bunu n8n otomasyonu hizmetimiz kapsamında seninle birlikte memnuniyetle inceleriz. Dijital çalışanlar olarak yapılandırmayı bir kez düzgünce kurar, belgeleriz ve sunucu kaynakların üzerindeki kontrolü elinde tutabilmen için sana teslim ederiz.

Sık Sorulan Sorular

n8n Neden Hemen Değil de Belirli Bir PDF Sayısından Sonra Çöküyor?

Çünkü varsayılan modda her bir dosya ek bellek kullanır. Az sayıda küçük dosyada yeterli tampon kalır, ancak aynı çalıştırmada eklenen her yeni PDF ile RAM tüketimi artmaya devam eder, ta ki konteynerin veya sunucunun kullanılabilir belleği tükenene ve süreç çökene kadar.

Çalıştırma Başına 100 PDF İçin Filesystem Moduna Geçiş Yeterli mi?

Çoğu tek örnekli kurulumda evet, çünkü dosyalar artık bellekte değil sabit diskte tutulur ve çalıştırma başına RAM tüketimi belirgin şekilde azalır. Birden fazla ayrı worker ile queue modunda çalışıyorsan, ayrıca ortak kullanılan bir depolama alanına veya S3 moduna ihtiyacın olur, çünkü n8n orada Filesystem modunu desteklemez.

S3 Depolaması İçin Belirli Bir n8n Lisansına İhtiyacım Var mı?

Evet. Resmi dokümantasyona göre ikili veriler için S3 bağlantısı geçerli bir Enterprise lisansına bağlıdır; bu lisans olmadan instance S3 modunda başlamaz. Birden fazla worker makinesi olmayan küçük kurulumlar için ücretsiz Filesystem modu genellikle daha basit ve yeterli bir çözümdür.

İkili Veri Klasörünü Manuel Olarak Silmem Gerekir mi?

n8n klasörü otomatik olarak temizlemez; bunun yerine temizliği `EXECUTIONS_DATA_PRUNE` ve `EXECUTIONS_DATA_MAX_AGE` gibi çalıştırma verisi pruning ayarlarına bağlar. Pruning etkinse, eski çalıştırmalar aktif moddaki ikili verileriyle birlikte düzenli olarak kaldırılır; pruning devre dışıysa klasör sınırsız şekilde büyümeye devam eder.