n8n PostgreSQL Kullanırken Hangi Kaynaklar İzlenmeli?

n8n üzerinde iş akışları büyüdükçe PostgreSQL yalnızca bir veritabanı değil, otomasyon platformunun sürekliliğini doğrudan etkileyen kritik bir bileşen haline gelir. Kuyruk yönetimi, execution kayıtları, credential verileri, webhook geçmişi ve hata logları PostgreSQL üzerinde tutulduğu için kaynak tüketimini düzenli izlemek; yavaş çalışan akışları, beklenmeyen kesintileri ve veri tabanı şişmesini erkenden fark etmeyi sağlar.

İzlenmesi Gereken Temel PostgreSQL Kaynakları

n8n PostgreSQL izleme sürecinde ilk bakılması gereken alanlar CPU, bellek, disk, bağlantı sayısı ve sorgu performansıdır. Bu kaynakların her biri farklı bir problemi işaret eder; yalnızca CPU kullanımına bakmak çoğu zaman eksik değerlendirme yapılmasına neden olur.

CPU Kullanımı

CPU tüketimi, özellikle yoğun workflow çalıştıran yapılarda artar. Çok sayıda eş zamanlı execution, karmaşık node işlemleri ve sık tetiklenen webhook akışları PostgreSQL tarafında sorgu yükünü artırabilir. CPU sürekli yüksek seyrediyorsa yalnızca sunucu kaynağını artırmak yerine öncelikle ağır sorgular, gereksiz execution kayıtları ve indeks kullanımı kontrol edilmelidir.

Bellek ve Cache Kullanımı

PostgreSQL performansında bellek yönetimi kritik rol oynar. Veritabanı sık kullanılan verileri bellekte tutabildiğinde disk erişimi azalır ve n8n arayüzünde daha hızlı yanıt alınır. Ancak bellek yetersizse sorgular disk üzerinden çalışmaya başlar; bu da execution geçmişi yoğun sistemlerde belirgin yavaşlama oluşturur.

Burada yalnızca toplam RAM miktarına değil, PostgreSQL’in cache hit oranına da bakılmalıdır. Düşük cache hit oranı, veritabanının sık sık diske başvurduğunu ve performansın iyileştirilebileceğini gösterir.

Disk Alanı ve I/O Performansı

n8n kullanımında en sık gözden kaçan konulardan biri disk büyümesidir. Execution geçmişi, hata kayıtları ve büyük veri taşıyan workflow çıktıları zamanla PostgreSQL tablolarını hızla büyütebilir. Disk doluluğu yüzde 80 seviyesini geçtiğinde alarm tanımlamak güvenli bir yaklaşımdır.

Disk kapasitesi kadar I/O performansı da önemlidir. Disk okuma-yazma gecikmeleri yükseldiğinde n8n üzerinde workflow başlatma, execution listesi görüntüleme ve geçmiş kayıtları sorgulama yavaşlayabilir. SSD kullanımı, düzenli vacuum işlemleri ve execution pruning politikaları bu noktada doğrudan fayda sağlar.

Bağlantı Sayısı ve Connection Pool Yönetimi

PostgreSQL bağlantı limiti aşıldığında n8n tarafında bağlantı hataları, geciken webhook yanıtları veya başarısız workflow çalışmaları görülebilir. Özellikle birden fazla n8n instance çalışan yapılarda toplam bağlantı sayısı dikkatle planlanmalıdır.

Bağlantı sayısını değerlendirirken yalnızca mevcut bağlantılara değil, boşta bekleyen bağlantılara da bakılmalıdır. Çok sayıda idle bağlantı, bağlantı havuzu yapılandırmasının verimsiz olduğunu gösterebilir. Bu durumda n8n concurrency ayarları, worker sayısı ve PostgreSQL max connections değeri birlikte ele alınmalıdır.

Sorgu Süreleri ve Yavaş Sorgular

Yavaş sorgular, sistem kaynakları yeterli görünse bile kullanıcı deneyimini olumsuz etkileyebilir. n8n’de execution geçmişi büyüdükçe listeleme, filtreleme ve detay görüntüleme işlemleri daha fazla zaman alabilir. Bu nedenle ortalama sorgu süresi, en uzun çalışan sorgular ve lock beklemeleri düzenli izlenmelidir.

n8n PostgreSQL izleme yapılırken pg_stat_statements gibi PostgreSQL istatistiklerinden yararlanmak, hangi sorguların veritabanını zorladığını anlamayı kolaylaştırır. Bu sayede gereksiz veri birikimi, eksik indeks veya yoğun okuma yapan işlemler daha net tespit edilir.

Lock, Deadlock ve Transaction İzleme

PostgreSQL tarafında lock beklemeleri arttığında bazı n8n işlemleri görünürde takılmış gibi davranabilir. Özellikle uzun süren transaction’lar, aynı tabloya erişmeye çalışan diğer işlemleri bekletebilir. Bu durum nadir görülse de yüksek hacimli sistemlerde operasyonel risk oluşturur.

Deadlock kayıtları, uzun süre açık kalan transaction’lar ve bekleyen lock sayıları izlenmelidir. Sorun tekrar ediyorsa aynı anda çalışan workflow sayısı, veri yazma sıklığı ve execution saklama politikası gözden geçirilmelidir.

Execution Kayıtları ve Veritabanı Büyümesi

n8n’in PostgreSQL üzerinde en fazla yer kaplayan alanlarından biri execution kayıtlarıdır. Her başarılı veya hatalı çalışma saklandığında veritabanı zamanla büyür. Kurumsal yapılarda tüm geçmişi süresiz tutmak yerine operasyonel ihtiyaçlara göre saklama süresi belirlemek daha sağlıklıdır.

Örneğin hata analizleri için son 30 veya 90 gün yeterliyse daha eski kayıtların temizlenmesi performansı korur. Ancak regülasyon, denetim veya iç politika nedeniyle uzun süreli saklama gerekiyorsa arşivleme stratejisi ayrıca planlanmalıdır.

Uyarı Eşikleri Nasıl Belirlenmeli?

İzleme sistemi yalnızca grafik üretmek için değil, doğru zamanda aksiyon aldırmak için kurgulanmalıdır. CPU’nun kısa süreli yükselmesi her zaman kritik değildir; ancak disk doluluğu, bağlantı limiti ve uzun süren sorgular için daha hassas uyarılar tanımlanmalıdır.

• Disk doluluğu: yüzde 80 uyarı, yüzde 90 kritik seviye olarak değerlendirilebilir.
• Bağlantı kullanımı: maksimum bağlantı limitinin yüzde 70’i aşıldığında inceleme başlatılmalıdır.
• Yavaş sorgular: birkaç saniyeyi aşan tekrar eden sorgular ayrıca analiz edilmelidir.
• Cache hit oranı: beklenenden düşükse bellek ve sorgu yapısı birlikte kontrol edilmelidir.
• Execution tablosu büyümesi: düzenli artış trendi takip edilmeli, ani sıçramalar incelenmelidir.

Pratik İzleme Yaklaşımı

Başlangıç için kapsamlı ama yönetilebilir bir izleme seti oluşturmak en doğru yaklaşımdır. CPU, RAM, disk, I/O, bağlantı sayısı, yavaş sorgular, lock beklemeleri ve tablo büyüklükleri temel metrikler olarak ele alınmalıdır. Ardından n8n kullanım şekline göre workflow başarı oranı, hata yoğunluğu ve execution süresi gibi uygulama metrikleriyle ilişki kurulmalıdır.

En sağlıklı değerlendirme, PostgreSQL metriklerini n8n davranışlarıyla birlikte okumaktır. Veritabanı tarafında artan bağlantı sayısı aynı anda webhook trafiğiyle örtüşüyorsa kapasite planlaması gerekir; disk büyümesi execution kayıtlarından kaynaklanıyorsa saklama politikası güncellenmelidir. Bu yaklaşım, yalnızca anlık sorunları değil, ileride oluşabilecek performans risklerini de görünür hale getirir.