Çoğu kullanıcı bu durumda workflow’larını bölmeye veya bekleme (Wait) nodları eklemeye çalışır. Oysa arka planda yaşanan sorun tamamen fizikseldir: Node.js tabanlı n8n, veriyi işlerken RAM’e açtır.

n8n Neden Çöker? (Teknik Analiz)

n8n, arka planda Node.js üzerinde çalışır. Standart hosting firmalarında veya 1-2 GB RAM’e sahip ucuz sanal sunucularda (VPS) n8n barındırdığınızda şu zincirleme felaketleri yaşarsınız:

1. Bellek (RAM) Sınırının Aşılması: Büyük bir webhook tetiklendiğinde veya “Merge” node’u iki büyük veriyi birleştirmeye çalıştığında, Node.js’in bellek sınırı (genellikle varsayılan 1.5 GB civarındadır) aşılır. Loglarda meşhur FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory hatasını görürsünüz. Süreç (Process) anında ölür.

2. I/O Darboğazı (Disk Beklemesi): n8n, geçmiş iş akışlarını (Execution logs) SQLite veya PostgreSQL veritabanına yazar. Eğer sunucunuz standart SSD kullanıyorsa, yoğun işlemlerde disk yazma hızı yetişemez (I/O Wait) ve arayüzünüz yanıt vermez hale gelir (502 Bad Gateway).

3. Yetersiz İşlemci Çekirdeği: Standart hostinglerde CPU limitlerine takıldığınız için, aynı anda gelen birden fazla Webhook isteği sıraya alınır, zaman aşımına uğrar ve verileriniz kaybolur.

Çözüm: n8n İçin Doğru Ortam Nasıl Olmalı?

Bu sorunları aşmak için işletim sistemi (Linux) seviyesinde “Swap” (Takas) alanı eklemek geçici bir çözümdür, çünkü Swap alanı diski kullanır ve diskler RAM’den binlerce kat daha yavaştır. Kesintisiz bir n8n deneyimi için “Yönetilen” ve güçlü bir donanıma ihtiyacınız vardır.

SaviorHost olarak, standart cPanel hosting sınırlarını yıkıp, sadece otomasyon ve Node.js süreçleri için özel olarak izole edilmiş bir mimari kurduk. n8n projelerinizin neden SaviorHost’ta asla çökmeyeceğini teknik verilerle anlatalım:

• Sınırları Zorlayan RAM Kapasitesi: En giriş paketimiz olan Node Starter bile 4 GB DDR5 RAM ile başlar. Bu, en karmaşık veri manipülasyonlarınızın ve döngülerinizin (Loop) bellek sınırına takılmadan akıcı bir şekilde çalışması demektir.

• Gen4 NVMe ile 7 GB/s I/O Hızı: n8n veritabanı okuma/yazma işlemleriniz standart SSD’lere göre 15 kat daha hızlı gerçekleşir. “Execution” loglarınız arayüzde saniyeler içinde, bekleme yapmadan yüklenir.

• İzole Jailshell SSH ve Yönetilen Ortam: n8n kurmak, PM2 yapılandırmak veya reverse proxy ayarlamakla uğraşmazsınız. İzole Jailshell SSH erişimi ile tam kontrole sahip olurken, altyapının kararlılığı tarafımızca yönetilir.

Otomasyonlarınızın sunucu yetersizliği yüzünden yarıda kesilmesi, müşterilerinize veri kaybı veya gecikme olarak yansır. İş süreçlerinizi şansa bırakmayın.

Aylık sadece $4.99’dan başlayan fiyatlarla, 4 GB DDR5 RAM ve Gen4 NVMe gücüne sahip n8n Hosting Paketlerimizi hemen inceleyin. Otomasyonlarınızı Ryzen 9 donanımının özgürlüğüne kavuşturun.

Çoğu hosting firmasının destek ekibi bu durumda size standart bir cevap verir: “Kaynak limitlerinizi aşıyorsunuz, lütfen üst pakete geçin veya eklentilerinizi kapatın.” Oysa gerçek bir sunucu mimarisi uzmanı gibi yaklaştığınızda, sorunun çoğu zaman eklentilerde değil, arka plandaki hantal işlemci kuyruklarında (PHP Worker) olduğunu görürsünüz. SaviorHost mühendislik ekibi olarak, 508 hatasının arkasındaki gerçekleri ve kesin çözüm yollarını masaya yatırıyoruz.

1. 508 Hatası Gerçekte Ne Anlama Gelir? (CloudLinux LVE Limitleri)

Standart hosting sunucularında, bir müşterinin tüm sunucuyu çökertmesini engellemek için CloudLinux işletim sistemi ve LVE (Lightweight Virtual Environment) Manager kullanılır. Siteniz 508 hatası veriyorsa, cPanel veya KeyHelp üzerinden “Kaynak Kullanımı” (Resource Usage) grafiğine baktığınızda şu metriklerden birinin kırmızıya döndüğünü görürsünüz:

• CPU Limit (İşlemci): WordPress temanızın veya PHP kodlarınızın çok ağır döngülere girmesidir.

• PMEM / pRAM (Fiziksel Bellek): Ağır sayfa yapılandırıcılar (Elementor vb.) veya şişmiş wp_options tabloları nedeniyle RAM limitinin dolmasıdır.

• EP (Entry Processes): En tehlikelisi budur. Sitenize aynı anda bağlanan ve o milisaniye içinde PHP/MySQL işlemi yapan kişi sayısıdır. E-ticaret sitelerinde bu limit çok hızlı dolar.

2. Sorunu Kod Seviyesinde Çözmek: SysAdmin Taktikleri

A. admin-ajax.php Sömürüsünü Durdurun

WooCommerce, sepete ürün eklendiğinde sayfanın yenilenmemesi için (AJAX) arka planda sürekli wp-admin/admin-ajax.php dosyasına istek atar. Bazı temalar ve sepet eklentileri bunu saniyede 3-4 kez yapacak kadar kötü kodlanmıştır. Bu durum Entry Processes (EP) limitinizi anında doldurur. Çözüm: Heartbeat Control eklentisini kurun ve WordPress Heartbeat API’sinin çalışma sıklığını “15 saniyede bir” ila “60 saniyede bir” olacak şekilde sınırlandırın. Front-end (Ön yüz) için tamamen kapatmayı da düşünebilirsiniz.

B. WP-Cron’u Kapatıp Sunucu Cron’una Geçin

WordPress’in zamanlanmış görevleri (taslak kaydetme, stok güncelleme, yedekleme) wp-cron.php üzerinden çalışır. Standart ayarda, sitenize bir ziyaretçi her girdiğinde bu dosya tetiklenir! Günde 10.000 kişi giriyorsa, gereksiz yere 10.000 kez görev tetiklenir ve CPU limitiniz dolar. Çözüm: wp-config.php dosyanıza define('DISABLE_WP_CRON', true); satırını ekleyin. Ardından sunucu kontrol panelinize (KeyHelp vb.) girerek, “Cron Jobs” bölümünden bu işlemi her 15 dakikada bir sunucu seviyesinde çalışacak şekilde manuel ayarlayın: wget -q -O - https://siteniz.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

C. Dinamik Sayfalar İçin Redis Object Cache

Sepet ve ödeme sayfaları dinamiktir, HTML önbelleğine (LiteSpeed Cache vb.) alınamaz. Her müşteri sepete tıkladığında sunucu veritabanına gidip yanıt bekler. Çözüm: Veritabanı sorgularını sunucunun ultra hızlı belleğinde (RAM) tutan Redis Object Cache mimarisini aktif edin. Bu sayede MySQL (MariaDB) rahatlar ve CPU limitlerine takılmazsınız.

3. Acı Gerçek: Donanımınız Yetersizse Kod Optimizasyonu İşe Yaramaz!

Tüm bu ayarları yaptınız, temanız hafif, eklentileriniz lisanslı ancak anlık 50 ziyaretçi geldiğinde hala 508 hatası mı alıyorsunuz? Bunun sebebi, arka plandaki işlemcinin PHP kuyruklarını zamanında eritememesidir.

Eski nesil Intel Xeon işlemciler kullanan standart hosting firmalarında (veya ağır cPanel türevi kontrol panellerinde), bir müşterinin sepete ekleme işlemi işlemci kuyruğunda bekler. İşlem uzun sürdüğü için Entry Process limiti açık kalır, arkadan gelen diğer müşteriler sıraya girer ve sistem kilitlenip 508 hatası patlar.

SaviorHost ile Darboğazı Ham Donanım Gücüyle Aşın

Biz SaviorHost olarak, e-ticaret sitelerinin CPU ve EP limitlerine takılmaması için sistemi temelden, yani donanımdan değiştiriyoruz:

• AMD Ryzen™ 9 7900 Mimarisi: İnanılmaz tek çekirdek performansı (IPC) sayesinde, en ağır WooCommerce sorguları bile kuyrukta beklemeden milisaniyeler içinde işlenip kapatılır. EP limitleriniz asla şişmez.

• Gen4 NVMe Diskler (7GB/s): Standart SSD’lere göre 15 kat daha hızlı olan Gen4 mimarisiyle, I/O Wait (Disk bekleme) kaynaklı işlemci tıkanıklıklarını sıfıra indiriyoruz.

• 50 PHP Worker ile Özgürlük: Rakiplerin 10-20 ile sınırladığı eşzamanlı PHP işlemci gücünü, yoğun e-ticaret siteleriniz için devasa bir havuza dönüştürüyoruz.

Müşterileriniz tam ödeme yapacakken 508 hatasıyla karşılaşmasın. Sitenizi sınırların ve hantal donanımların ötesine taşımak için güçlü Linux Web Hosting paketlerimizi 15 Gün İade Garantisi ile hemen inceleyin. Zombi botların veya yetersiz donanımların ticaretinizi yavaşlatmasına izin vermeyin.

Cpanel, KeyHelp veya Plesk gibi paneller RAM limitlerini yönetmekte başarılı olsa da, doğrudan terminal (SSH) üzerinden başlatılan işlemlere (Örn: PM2 ile başlatılan Node.js) müdahale edemezler. İşte tam bu noktada imdadımıza Linux’un kalbinde yatan systemd ve cgroups yetişiyor.

CPUQuota Mantığı Nasıl Çalışır?

Linux çekirdeğinde işlemci gücü yüzdelik dilimlerle hesaplanır. Formül oldukça basittir: 1 Tam Çekirdek (1 vCPU) = %100 CPUQuota

Yani sunucunuzda 16 çekirdek varsa ve siz bir kullanıcıya %200 limit verirseniz, o kullanıcı sistemin sadece 2 çekirdek gücü kadarını kullanabilir. Kalan 14 çekirdek diğer müşterileriniz için güvende kalır.

Adım Adım CPU Limiti Ayarlama (Ubuntu, Debian, CentOS 7/8, AlmaLinux)

Modern Linux dağıtımlarının neredeyse tamamı servis yöneticisi olarak systemd kullanır. Bu nedenle anlatacağımız yöntem hem Ubuntu/Debian ailesinde hem de CentOS/RHEL/AlmaLinux ailesinde kusursuz çalışır.

1. Kullanıcının UID (User ID) Değerini Bulun

Limitlendirme işlemini kullanıcı adı (username) üzerinden değil, kullanıcının Linux ID’si (UID) üzerinden yapacağız. Örneğin, ornekuser isimli müşterinin UID’sini bulmak için SSH üzerinden şu komutu yazın:

id -u ornekuser

Bu komut size 1005 gibi bir sayı döndürecektir.

2. Limiti Uygulayın

Bulduğunuz UID değerini kullanarak kullanıcıya limit atayın. Aşağıdaki komut, ornekuser isimli müşterinin sunucuda çalıştıracağı tüm işlemleri (Web sitesi, Cron görevleri, PM2 vb.) toplamda 1 Çekirdek (1 vCPU) ile sınırlandırır:

systemctl set-property user-1005.slice CPUQuota=100%

Eğer başlangıç seviyesi bir paket sunuyorsanız ve yarım çekirdek (0.5 vCPU) vermek isterseniz:

systemctl set-property user-1005.slice CPUQuota=50%

3. Mevcut Sınırı Kontrol Etmek

Bir müşteriye daha önce ne kadar limit verdiğinizi görmek isterseniz şu komutu kullanabilirsiniz:

systemctl show user-1005.slice -p CPUQuota

Çıktı CPUQuota=100% şeklindeyse işlem başarılıdır. Eğer [not set] yazıyorsa o kullanıcının bir sınırı yoktur ve tüm işlemciyi kullanabilir.

4. Limiti Tamamen Kaldırmak (Sınırsız Yapmak)

Kullanıcı daha üst bir pakete geçtiğinde veya sınırı kaldırmak istediğinizde, eşittir (=) işaretinden sonrasını boş bırakarak komutu tekrar çalıştırın:

systemctl set-property user-1005.slice CPUQuota=

Bonus: Tüm KeyHelp Kullanıcılarına Tek Seferde Limit Koymak (Otomasyon)

Eğer halihazırda KeyHelp, cPanel veya benzeri bir sistem kullanıyorsanız ve sunucunuzdaki mevcut tüm müşterilere tek seferde 1 vCPU (1 Çekirdek) sınırı koymak istiyorsanız, SSH üzerinden root yetkisiyle aşağıdaki basit bash döngüsünü çalıştırabilirsiniz.

(Not: Aşağıdaki script, kullanıcı dizinlerinin /home/users/ altında olduğu KeyHelp mimarisine göre yazılmıştır. cPanel için dizini /home/ olarak değiştirebilirsiniz).

for d in /home/users/*; do
    kullanici=$(basename "$d")
    uid=$(id -u "$kullanici" 2>/dev/null)
    
    if [ -n "$uid" ]; then
        echo "$kullanici (UID: $uid) için 1 vCPU sınırı ayarlanıyor..."
        systemctl set-property user-$uid.slice CPUQuota=100%
    fi
done
echo "İşlem Tamamlandı! Tüm mevcut müşteriler sınırlandırıldı."

Sonuç

Bu basit ama güçlü yöntem sayesinde paylaşımlı sunucularınızı modern bir bulut altyapısına (PaaS) dönüştürebilir, “kaynak sattıkça kazanç sağlayan” bir iş modeli kurabilirsiniz. İşlemci sömüren hesapları engellemek, diğer müşterilerinizin hız ve performans kalitesini anında artıracaktır.

Bu kapsamlı rehberde; Keyhel Panel’de Jailed SSH ortamında güvenlikten ödün vermeden, gerekli izinleri ayarlamayı, NVM (Node Version Manager) kullanarak Node.js kurmayı ve uygulamalarınızı PM2 ile 7/24 kesintisiz nasıl çalıştıracağınızı adım adım anlatıyoruz.

1. Adım: Ön Hazırlık – “Ek İkili Dosyalar” ve Kütüphane İzinleri

Jailed SSH (Hapishane) ortamı, kullanıcıyı sadece belli başlı komutlarla sınırlandırır. NPM’in paketleri indirebilmesi, zipli dosyaları açabilmesi ve özellikle Vite/Rollup gibi modern araçların Linux çekirdek kütüphanelerine ulaşıp derleme (build) yapabilmesi için sunucu panelinizden bazı komutlara izin vermeniz gerekir.

Hosting panelinizden (Örn: KeyHelp’te Yapılandırma > Sınırlandırılmış SSH > Ek İkili Dosyalar bölümüne) aşağıdaki listeyi eksiksiz olarak ekleyin ve kaydedin:

/usr/bin/node
/usr/bin/npm
/usr/local/bin/pm2
/usr/bin/sed
/usr/bin/awk
/usr/bin/tr
/usr/bin/uname
/usr/bin/tar
/usr/bin/gzip
/usr/bin/xz
/usr/bin/sort
/usr/bin/grep
/usr/bin/tail
/usr/bin/head
/usr/bin/cut
/usr/bin/wc
/usr/bin/dirname
/usr/bin/find
/usr/bin/tee
/usr/bin/sha256sum
/usr/bin/rm
/usr/bin/cp
/usr/bin/mv
/lib/x86_64-linux-gnu/librt.so.1
/usr/lib/x86_64-linux-gnu/librt.so.1
/lib64/librt.so.1

Not: Listenin sonundaki librt.so.1 yolları, Vite ve Rollup kullanan projelerde derleme sırasında alınan Error: librt.so.1: cannot open shared object file (ERR_DLOPEN_FAILED) hatasının kesin çözümüdür.

2. Neden Jailed SSH’ta Standart Node.js Kurulumu Çöker?

İzinleri verdikten sonra bile, sistem sizi genellikle /www veya /home/kullaniciadi gibi bir dizine hapseder. Ancak Node.js ve NPM, kurulum ve önbellek (cache) işlemleri için ana sunucu dizinlerine (/.npm) erişmeye çalışır.

Bu durum karşılaştığımız en meşhur hatayı doğurur: Error: EACCES: permission denied, mkdir '/.npm'

Çözüm: Uygulamaları “Root” düzeyinde değil, tamamen kullanıcının kendi izole alanında (Kapsayıcı mantığıyla) kurmaktır.

3. Adım Adım NVM ile Özel Node.js Motoru Kurmak

Her müşteriye veya projeye kendi bağımsız Node.js motorunu atamak için NVM kullanıyoruz. Bu sayede aynı sunucuda bir proje Node 18 ile çalışırken diğeri Node 20 ile çakışmadan çalışabilir.

Terminalinize giriş yapın ve ortamı uyandırmak için şu komutları sırasıyla girin (NVM kurulu değilse standart cURL komutuyla kurabilirsiniz):

# NVM'in yolunu belirleyin
export NVM_DIR="/www/.nvm"

# NVM'i aktif edin
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"

# İstediğiniz Node sürümünü kurun ve kullanın (Örn: v20)
nvm install 20
nvm use 20

4. NPM EACCES (Yetki) Hatalarını Tamamen Aşmak

NPM’in sunucu kök dizinlerine dosya yazmaya çalışmasını engellemek için ona “Ev” dizininin neresi olduğunu söylemeliyiz. Aşağıdaki komut, NPM’in tüm önbellek dosyalarını kısıtlı alanımız olan /www içerisine yazmasını sağlar:

export HOME="/www"

Sürüm Çakışmalarını (ERESOLVE) Gidermek

Projelerinizde paket sürümleri uyuşmazlığı (npm error ERESOLVE) yaşıyorsanız, NPM’e eski tip bağımlılık çözümlemeyi kullanmasını söyleyerek kurulumu zorlayabilirsiniz:

npm install --legacy-peer-deps

5. Jailed Ortamda PM2 Kurulumu ve “module_conf.json” Hatası Çözümü

Uygulamanızı arka planda sürekli çalıştıracak olan PM2’yi kurmak, yetki sorunlarının en çok yaşandığı yerdir. PM2 logları ve PID dosyalarını ana dizindeki /.pm2 içine yazmaya çalışır. Bunu önlemek için PM2’nin çalışma alanını yeniden yönlendiriyoruz:

# PM2'ye yeni bir ev gösteriyoruz
export PM2_HOME="/www/.pm2"

# PM2'yi global olarak kuruyoruz
npm install -g pm2

Kurulumun başarılı olup olmadığını test etmek için:

pm2 status

Bu komut size boş da olsa o meşhur PM2 tablosunu vermelidir.

6. Uygulamayı Başlatmak ve PM2’yi Kalıcı Hale Getirmek

Tüm altyapımız hazır. Şimdi Node.js veya derlenmiş (build edilmiş) projemizi canlıya alalım.

1. Uygulamanızın klasörüne girin:

cd /www/

2. PM2 ile uygulamayı başlatın: Birden fazla uygulama barındırıyorsanız --name parametresi ile isimleri birbirinden ayırmayı unutmayın.

pm2 start index.js --name "proje-adi" --cwd /www/

3. İşlemi Kaydedin: Sunucu herhangi bir sebeple yeniden başlatıldığında uygulamanızın otomatik olarak tekrar açılması için listeyi kaydedin:

pm2 save

Bonus: SSH Her Açıldığında Ayarları Korumak (.bashrc Otomasyonu)

Jailed SSH ortamları çok “unutkandır”. Terminali kapatıp açtığınızda pm2 status veya npm komutları tekrar hata verebilir. Çünkü girdiğimiz export komutları hafızadan silinir.

Her girişinizde tek bir kelimeyle ortamı hazırlamak için kendinize bir kısayol (alias) oluşturun:

echo 'alias start="export HOME=/www && export PM2_HOME=/www/.pm2 && export NVM_DIR=/www/.nvm && [ -s \"\$NVM_DIR/nvm.sh\" ] && . \"\$NVM_DIR/nvm.sh\" && nvm use 20"' >> /www/.bashrc
source /www/.bashrc

Artık SSH’a her bağlandığınızda sadece start yazıp Enter’a basmanız yeterlidir. Tüm NVM ve PM2 yollarınız saniyeler içinde arka planda hazır hale gelecektir.

Özet

Kısıtlı SSH izinleri, modern web uygulamaları geliştirmek için bir engel değildir. Doğru yapılandırılmış NVM ortamları, çekirdek librt izinleri ve export yönlendirmeleri ile ana sunucuya hiçbir zarar vermeden (Root yetkisi kullanmadan) tamamen izole, güvenli ve yüksek performanslı Node.js barındırma altyapıları kurabilirsiniz. Başarılar dileriz!

Bir WooCommerce mağazası kurdunuz, en iyi temayı aldınız, resimleri optimize ettiniz ve en popüler önbellek (Cache) eklentisini kurdunuz. Sitenizin anasayfası saniyeler içinde açılıyor. Ancak bir müşteri ürünü sepete eklediğinde veya ödeme sayfasına (Checkout) geçtiğinde sistem adeta kilitleniyor, saniyelerce yükleniyor ikonu dönüyor. Neden?

Çünkü statik sayfa önbellekleme (Page Caching), e-ticaret sitelerinde işe yaramaz.

Sepet, ödeme ve hesabım sayfaları her müşteri için benzersizdir (dinamiktir) ve önbelleğe alınamaz. Müşteri sepete tıkladığı an, sunucunuz veritabanına (MariaDB/MySQL) canlı bir sorgu atar. Eğer veritabanınız şişmişse ve sunucunuzun I/O (Okuma/Yazma) hızı yetersizse, o müşteri ödeme yapmaktan vazgeçip sitenizi terk eder.

SaviorHost mühendislik ekibi olarak, WooCommerce altyapısını yavaşlatan veritabanı krizlerini ve bu darboğazları sunucu seviyesinde nasıl aşacağınızı teknik detaylarıyla inceliyoruz.

1. Sessiz Katil: wp_options Tablosu ve Autoload Krizleri

WordPress mimarisinde temanızın, eklentilerinizin ve WordPress çekirdeğinin tüm ayarları wp_options tablosunda tutulur. Bu tablodaki en tehlikeli sütun ise autoload (otomatik yükle) sütunudur.

Eğer bir ayarın autoload değeri ‘yes’ ise, sitenizin herhangi bir sayfası yüklendiğinde WordPress bu veriyi veritabanından çeker. Kötü kodlanmış eklentiler (özellikle eski sayfa yapıcılar ve istatistik eklentileri) sildikten sonra bile verilerini burada bırakır. Zamanla bu tablo megabaytlarca şişer. Her sayfa açılışında sunucunuz boş yere 5-10 MB veriyi RAM’e kopyalamaya çalışır ve işlemciyi boğar.

Autoload Boyutunuzu Nasıl Ölçersiniz?

İdeal bir WordPress sitesinde autoload edilen veri boyutu 800 KB ile 1.5 MB arasında olmalıdır. Bunu kontrol etmek için phpMyAdmin’e girin, veritabanınızı seçin ve şu SQL sorgusunu çalıştırın:

SELECT SUM(LENGTH(option_value)) / 1024 / 1024 AS autoload_size_mb 
FROM wp_options 
WHERE autoload = 'yes';

Eğer sonuç 2 MB’ın üzerindeyse (bazı e-ticaret sitelerinde 15-20 MB’a kadar çıkar), siteniz her tıklamada veritabanı altında eziliyor demektir.

Suçluyu Bulmak ve Temizlemek

Hangi eklentinin veya temanın bu tabloyu şişirdiğini bulmak için şu sorguyu çalıştırın:

SELECT option_name, length(option_value) AS option_value_length 
FROM wp_options 
WHERE autoload='yes' 
ORDER BY option_value_length DESC LIMIT 20;

Karşınıza çıkan listede, yıllar önce sildiğiniz bir eklentiye ait (_transient_ içermeyen) devasa satırlar görüyorsanız, bunları silerek (veya autoload değerini ‘no’ yaparak) TTFB (İlk Bayt Süresi) değerinizi anında yarı yarıya düşürebilirsiniz.

2. WooCommerce Transients (Geçici Veriler) Çöplüğü

WooCommerce, müşterilerin sepet verilerini, kargo hesaplamalarını ve API yanıtlarını hızlandırmak için veritabanında “Transients” (Geçici Veriler) oluşturur. Ancak yoğun trafiği olan sitelerde zamanı dolan (Expired) bu veriler veritabanından otomatik olarak silinmeyebilir. wp_options tablosunun içinde on binlerce _transient_wc_ satırı birikir.

Kesin Çözüm: Eğer sunucunuzda SSH (Terminal) erişiminiz ve WP-CLI kuruluysa, tek bir komutla tüm bu geçici çöpü silebilirsiniz: wp transient delete --all

Eğer terminal erişiminiz yoksa, WooCommerce > Durum > Araçlar sekmesine giderek “WooCommerce geçici verilerini (transient) temizle” butonunu kullanabilirsiniz. Bu işlemi haftada bir kez yapmak, veritabanı şişmesini önleyecektir.

3. Gerçek Performans Mimarı: Redis Object Cache

Sayfa önbelleklemenin (HTML Caching) dinamik sayfalarda (Sepet/Ödeme) işe yaramadığını söylemiştik. İşte burada devreye Nesne Önbellekleme (Object Caching) girer.

Redis, veritabanına yapılan karmaşık MySQL sorgularını alır ve bunları sunucunun ultra hızlı belleğinde (RAM) tutar. Müşteri sepete tıkladığında, sunucu hantal sabit diske gidip MySQL tablolarını aramak yerine, sonucu saniyenin binde biri hızında RAM’den (Redis üzerinden) çeker.

WooCommerce’de Redis Nasıl Aktif Edilir?

1. Öncelikle hosting firmanızın sunucuda Redis servisini desteklediğinden ve PHP-Redis eklentisinin açık olduğundan emin olun (SaviorHost altyapısında bu standart olarak aktiftir).

2. WordPress panelinizden “Redis Object Cache” eklentisini (Till Krüss tarafından geliştirilen) kurun.

3. Eklentiyi etkinleştirmeden önce wp-config.php dosyanıza şu güvenlik ve performans satırlarını ekleyin:

   PHP

   define('WP_CACHE', true);
   define('WP_REDIS_PREFIX', 'siteadi_'); 
   define('WP_REDIS_MAXTTL', 86400);
   

4. Eklenti paneline gidip “Enable Object Cache” butonuna tıklayın.

Eğer Redis doğru yapılandırıldıysa, WooCommerce wp-admin panelinizdeki hızlanmayı ve ödeme sayfasındaki gecikmenin tamamen ortadan kalktığını saniyeler içinde hissedeceksiniz.

4. Donanımın Sınırları: Neden Sadece Optimizasyon Yetmez?

Yukarıdaki tüm veritabanı temizliğini yaptınız, Redis’i kurdunuz, eklentilerinizi optimize ettiniz. Ancak kampanya dönemlerinde veya anlık ziyaretçi sayınız 100’ü geçtiğinde siteniz hala kasılıyor veya 508 Resource Limit hatası mı veriyor?

Çünkü yazılım, donanımın izin verdiği yere kadar koşabilir.

Sektördeki standart hosting firmaları, maliyetleri düşürmek için hala yavaş dönüşlü SATA SSD’ler ve eski nesil Intel işlemciler kullanır. Redis ne kadar hızlı olursa olsun, RAM’in işlemciyle (CPU) iletişim kurma hızı yetersizse veritabanınız yine de tıkanır.

SaviorHost ile Darboğazı Donanımla Aşın

Biz SaviorHost olarak, WooCommerce sitelerinin ne kadar fazla I/O (Giriş/Çıkış) operasyonuna ihtiyaç duyduğunu biliyoruz. Bu yüzden altyapımızı e-ticaret siteleri için özel bir mühendislikle tasarladık:

• Gen4 NVMe Diskler (7GB/s Okuma/Yazma): Standart SSD’lerin 15 katı hıza sahip Gen4 NVMe disklerimiz sayesinde, veritabanı okuma ve yazma işlemlerindeki gecikmeleri (I/O Wait) tamamen ortadan kaldırıyoruz.

• AMD Ryzen™ 9 7900 DDR5 Altyapısı: İşlemcinin tek çekirdek performansının (IPC) yüksek olması, dinamik PHP sorgularının anında işlenmesini sağlar.

• Arka Planda Yük Yaratmayan KeyHelp: Ağır kontrol panellerinin RAM sömürmesini engelliyor, tüm belleği Redis’e ve sitenizin veritabanı sorgularına ayırıyoruz.

Sitenizin yavaşlığı nedeniyle sepeti terk eden müşterilerinize veda edin. E-ticaret operasyonunuzu Premium Linux Web Hosting paketlerimize taşıyın, 15 Gün İade Garantisi ile gerçek bir sunucunun WooCommerce’i nasıl uçurduğunu kendiniz deneyimleyin.

TTFB Nedir? Bir kullanıcı sitenize girmek için adresi yazdığında, tarayıcı sunucuya bir istek gönderir. Sunucunun bu isteği alıp, veritabanını tarayıp, ilk veri baytını ziyaretçinin tarayıcısına ulaştırdığı o ilk ana kadar geçen süreye TTFB denir. İdeal bir TTFB süresi 200 milisaniyenin (ms) altında olmalıdır.

TTFB Neden Yüksek Çıkar? Eğer sitenizin TTFB süresi 500ms ve üzerindeyse, resimlerinizi ne kadar küçültürseniz küçültün siteniz Google gözünde “yavaş” kabul edilir. Yüksek TTFB’nin üç ana nedeni vardır:

1. Yoğun ve optimize edilmemiş veritabanı sorguları.

2. İşletim sistemi ve arka planda çalışan hantal kontrol panellerinin işlemciyi yorması.

3. Sunucu işlemcisinin ve eski PHP sürümlerinin (bu konuda PHP 8.5’in performansa etkisini incelediğimiz yazımıza bakabilirsiniz) zayıf kalması.

TTFB Nasıl Düşürülür? Yazılımsal önbellekleme (Cache) TTFB’yi düşürmekte yardımcı olsa da kalıcı ve kesin çözüm güçlü bir altyapı mimarisinden geçer.

• Disk Okuma Hızı: Veritabanı sorgularının kuyrukta beklememesi için standart SSD’ler yerine saniyede 7GB/s’ye ulaşan Gen4 NVMe diskler kullanılmalıdır.

• İşlemci Gücü: Gelen isteklerin anında işlenip baytların saniyeler içinde yola çıkması için Ryzen 9 gibi yüksek tek çekirdek performanslı işlemciler gereklidir.

• Hafif Mimari: Sunucuyu yormayan KeyHelp paneli sayesinde arka plan servisleri minimumda tutularak kaynaklar sadece sitenize ayrılmalıdır.

Sitenizin SEO sıralamasını korumak ve organik trafiğinizi artırmak için yüksek TTFB sürelerine katlanmak zorunda değilsiniz. Yeni nesil SaviorHost sunucu altyapısıyla test edin ve aradaki performans farkını saniyeler içinde görün.

Bir web sitesi sahibinin karşılaşabileceği en sinir bozucu durumlardan biri, anlık trafik arttığında veya bir sipariş geldiğinde sitenin aniden çökmesi ve ekranda o meşhur “508 Resource Limit Is Reached” veya “CPU Quota Exceeded” hatasının belirmesidir.

Bu hata, paylaşımlı hosting ortamlarında CloudLinux (LVE Manager) veya benzeri sistemlerin, sitenizin diğer siteleri yavaşlatmasını engellemek için sizin fişinizi çekmesi anlamına gelir. Peki, WordPress neden bu kadar çok CPU tüketir ve bu darboğazı kod seviyesinde nasıl çözersiniz?

Kör uçuşu bırakıp, sorunu bir sistem yöneticisi (SysAdmin) gibi adım adım çözelim.

Adım 1: Darboğazı Teşhis Edin (Kör Uçuşuna Son)

CPU’nuzu neyin sömürdüğünü bilmeden eklenti silmek veya değiştirmek vakit kaybıdır. İlk olarak sorunun kaynağını bulmalısınız:

• Erişim Logları (Access Logs): Sunucu panelinizden (KeyHelp, cPanel vb.) erişim günlüklerini açın. Aynı saniye içinde yüzlerce kez xmlrpc.php veya wp-login.php dosyasına istek geliyorsa, sorun kodlarınızda değil, bir Brute Force (Kaba Kuvvet) saldırısındadır.

• Query Monitor Eklentisi: Sitenize geliştirici olarak giriş yapın ve Query Monitor eklentisini kurun. Hangi eklentinin veritabanına kaç saniye süren sorgular (Slow Queries) gönderdiğini milisaniyesine kadar tespit edin.

Adım 2: Heartbeat API ve admin-ajax.php Krizini Durdurun

WordPress, tarayıcı ile sunucu arasında sürekli bir iletişim kurmak için Heartbeat API’yi kullanır. Özellikle e-ticaret (WooCommerce) sitelerinde sepete ürün ekleme veya varyasyon seçme gibi işlemler admin-ajax.php üzerinden yürütülür. Anlık 50 kişinin sitede gezindiğini ve her saniye sunucuya bir AJAX isteği yolladığını düşünün. Düşük kapasiteli işlemciler bu kuyruğu eritemez ve CPU %100’e vurur.

Çözüm: Heartbeat API’nin frekansını düşürün veya gereksiz yerlerde tamamen kapatın. Temanızın functions.php dosyasına şu kodu ekleyerek Heartbeat’i sadece yazma ekranlarıyla sınırlandırabilirsiniz:

add_action( 'init', 'stop_heartbeat', 1 );
function stop_heartbeat() {
    global $pagenow;
    if ( $pagenow != 'post.php' && $pagenow != 'post-new.php' ) {
        wp_deregister_script('heartbeat');
    }
}

Adım 3: wp-cron.php‘yi Sunucu Tarafına Taşıyın

WordPress’in zamanlanmış görevleri (yazı yayımlama, yedek alma, e-posta gönderme) wp-cron.php üzerinden çalışır. Ancak WordPress, gerçek bir Cron sistemine sahip değildir; her ziyaretçi siteye girdiğinde bu dosya tetiklenir. Yüksek trafikli bir sitede her tıklamada wp-cron.php‘nin çalışması işlemcinizi felç eder.

Çözüm: WordPress’in sanal cron’unu kapatıp, gerçek sunucu cron’una geçin.

1. wp-config.php dosyanıza şu satırı ekleyerek sanal cron’u kapatın: define('DISABLE_WP_CRON', true);

2. Hosting panelinizin “Zamanlanmış Görevler” (Cron Jobs) bölümüne giderek şu komutu ekleyin (her 15 dakikada bir çalışacak şekilde): wget -q -O - https://siteniz.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Adım 4: Zombi Botları ve xmlrpc.php‘yi Engelleyin

xmlrpc.php, WordPress’in dış uygulamalarla (örneğin mobil uygulama) iletişim kurmasını sağlar. Ancak günümüzde hackerların DDoS saldırıları ve şifre denemeleri için en çok kullandığı arka kapıdır. Sunucunuz bu istekleri yanıtlamaya çalışırken CPU limitini doldurur.

Çözüm: Eğer WordPress mobil uygulamasını veya Jetpack gibi dış servisleri kullanmıyorsanız, .htaccess dosyanıza şu kodu ekleyerek bu dosyaya erişimi kökten kapatın:

# Block WordPress xmlrpc.php requests
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>

Adım 5: Acı Gerçek: Sorun Yazılımda Değil, Donanımınızda Olabilir

Yukarıdaki tüm optimizasyonları yaptınız, eklentilerinizi azalttınız, Redis Object Cache kurup veritabanı sorgularını RAM’e aldınız ama hala CPU sınırına takılıyorsanız… Artık yazılımın sınırlarına geldiniz demektir.

Sektördeki birçok standart hosting firması, sunucularında çok çekirdekli ancak tek çekirdek performansı (IPC) çok zayıf olan eski nesil Intel Xeon işlemciler kullanır. Dahası, tek bir sunucuya yüzlerce site doldurarak size sadece “kağıt üzerinde” kaynak ayırırlar. Ağır bir WooCommerce veya Elementor tabanlı siteniz varsa, bu işlemciler PHP kuyruklarını (Workers) eritemez.

SaviorHost ile “Limitlere” Veda Edin

Biz SaviorHost olarak, CPU darboğazını eklentilerle saklamaya çalışmıyoruz; saf donanım gücüyle eziyoruz.

• AMD Ryzen™ 9 7900 İşlemci Gücü: Saat döngüsü başına işlem (IPC) gücü inanılmaz yüksek olan Ryzen 9 mimarisi sayesinde, ağır PHP betikleri ve dinamik veritabanı sorguları milisaniyeler içinde işlenir. CPU şişmez, sıraya girmez.

• Ultra Hafif KeyHelp Mimarisi: Arka planda RAM ve işlemcinizi sömüren hantal kontrol panelleri (cPanel vb.) yerine, donanımın %99’unu doğrudan web sitenize tahsis eden Alman harikası KeyHelp mimarisini kullanıyoruz.

• Cömert PHP Worker Sayısı: E-ticaret sitelerinizin “admin-ajax” kuyruklarında boğulmaması için paketlerimizde rakiplerin sunmadığı düzeyde 50 PHP Worker limiti sunuyoruz.

Eğer CPU limitleriyle savaşmaktan, sitenizi sürekli optimize etmeye çalışıp yine de 508 hatası almaktan yorulduysanız; yeni nesil Yüksek Performanslı Linux Hosting veya WordPress Hosting altyapımıza geçiş yapın.

Donanım limitlerini düşünmeyi bırakın, sadece projenizi büyütmeye odaklanın. Farkı 15 Gün Koşulsuz İade Garantisi ile sıfır riskle test edebilirsiniz!

Son yıllarda PHP 8 serisi ile (özellikle JIT – Just In Time Compiler mimarisiyle) gelen devrim niteliğindeki yenilikler, PHP 8.5 ile çok daha kusursuz bir hale geldi. Peki, eski bir sürümden güncel sürümlere geçmek sitenize ne kazandırır?

1. CPU ve Bellek (RAM) Optimizasyonu Güncel PHP sürümleri, kodu makine diline çevirirken çok daha agresif optimizasyonlar yapar. Aynı işlemi yapmak için %30’a varan oranda daha az RAM kullanır ve CPU’yu çok daha az meşgul eder. Bu, anlık trafik artışlarında (hit dalgalanmalarında) sunucunuzun çökmesini engeller.

2. Daha Hızlı Kod İşleme (Execution Time) Özellikle WooCommerce ödeme adımlarında yavaşlık yaşayan sitelerde veya ağır Laravel projelerinde, güncel sürümler sorguları çok daha kısa sürede işler. Bu hız artışı, ziyaretçi deneyimini doğrudan iyileştirir.

3. Üst Düzey Güvenlik Eski PHP sürümleri yeni keşfedilen güvenlik açıklarına karşı yama almaz. Sitenizi güncel bir PHP sürümünde barındırmak, veritabanı sızıntılarına karşı en güçlü ilk savunma hattıdır.

Panel Hantallığına Takılmayın Sektördeki birçok hosting firması, kullandıkları kontrol panellerinin (CWP vb.) hantallığı ve güncelleme almaması nedeniyle müşterilerini eski PHP sürümlerine mahkum bırakabiliyor. SaviorHost altyapısındaki Linux web hosting paketlerimizde kullandığımız Alman harikası KeyHelp kontrol paneli, güncel PHP sürümlerini anında ve stabil bir şekilde destekler.

AMD Ryzen™ 9 işlemcilerimizin sağladığı devasa gücü, en güncel PHP mimarisiyle birleştirerek yazılımlarınızın sınırlarını zorlayabilirsiniz.

Peki, ana sayfada harikalar yaratan bu önbellek (cache) eklentilerine ödeme adımında ne oluyor?

Bypass Cache (Önbelleğin Devre Dışı Kalması) Önbellek eklentileri, web sitenizin statik bir kopyasını (HTML halini) oluşturup ziyaretçiye sunar. Böylece sunucu yorulmaz. Ancak bir müşteri sepete ürün eklediğinde, sisteme giriş yaptığında veya stok düşüleceği zaman sistemin “dinamik” çalışması gerekir. Eklenti burada aradan çekilir ve tüm yük doğrudan sunucunuzun çıplak donanımına biner. Bu durum doğrudan sunucu yanıt sürenizi, yani TTFB (İlk Bayt Süresi) değerinizi aniden yükseltir.

Asıl Darboğaz Nerede Başlıyor? Önbellek aradan çekildiği o kritik saniyelerde sitenizin hızı tamamen iki şeye bağlıdır:

1. PHP Yorumlama Hızı: PHP işçilerinin o anki hesaplamayı ne kadar hızlı yapabildiği.

2. Disk I/O (Okuma/Yazma): MariaDB veya MySQL veritabanının diske sipariş verisini ne kadar sürede yazabildiği.

Eğer sunucunuzda eski nesil Xeon işlemciler ve standart SSD diskler kullanılıyorsa, müşteri o sepet sayfasında bekler ve genellikle sepeti terk eder (Cart Abandonment).

Çözüm: Saf Donanım Gücü Dinamik sayfaların yavaşlığını eklentilerle çözemezsiniz. SaviorHost olarak e-ticaret altyapılarında sıfır gecikme (zero-latency) prensibiyle çalışıyoruz. Dinamik sorguların anında işlenmesi için tek çekirdek performansı tavan yapan AMD Ryzen™ 9 7900 işlemciler kullanıyoruz.

Ayrıca sunucuyu yoran hantal kontrol panelleri yerine ultra hafif KeyHelp mimarisiyle donanım gücünün %100’ünü doğrudan e-ticaret sitenize aktaran yüksek performanslı WordPress hosting paketlerimizle sepet terk edilme oranlarınızı minimuma indiriyoruz.

Sepette müşteri kaybetmek istemiyorsanız, önbelleğin arkasına saklanmayan gerçek donanım gücüyle tanışın.