508 Resource Limit Reached Hatası Nasıl Çözülür?

508 Resource Limit Reached, CloudLinux kullanan cPanel sunucularında hesabınızın eşzamanlı giriş işlemi (entry process, EP) sınırına dayandığını ve web sunucusunun yeni dinamik isteği geri çevirdiğini gösterir. Nedeni iki kayıtla bulursunuz: önce cPanel'deki CPU and Concurrent Connection Usage ekranında hangi limitin hangi saatte arıza (fault) verdiğini okuyun, sonra aynı dakikaları ham erişim günlüğünde açıp o sırada siteye neyin geldiğini sayın. Çoğu vakada karşınıza bot taraması, wp-login.php ya da xmlrpc.php denemeleri, önbelleğe girmeyen arama sayfaları veya yanıt vermeyen bir dış servis çıkar. Paket yükseltmesi ancak gerçek ziyaretçi trafiği limiti dolduruyorsa doğru çözümdür.

508 size neyi söylüyor, neyi söylemiyor?

Hata sayfası kaynak sınırına ulaşıldığını yazar ama hangi kaynağın bittiğini yazmaz. CloudLinux belgesine göre 508'i doğrudan üreten EP limitidir: hesabın aynı anda yürüttüğü PHP/CGI isteği sayısı tavana geldiğinde web sunucusu yeni isteği hesabın LVE ortamına alamaz ve 508 döndürür. Diğer limitler kendini başka türlü gösterir. NPROC dolduğunda yeni işlem başlatılamaz ve belgeye göre ziyaretçi genellikle 500 ya da 503 görür. Fiziksel bellek (PMEM) aşılınca LVE içindeki bazı işlemler sonlandırılır, sonuç yine çoğunlukla 500 veya 503 olur. CPU (SPEED) ve IO limitleri hata vermez, işleri yavaşlatır.

Her limitin neyi ölçtüğünü hosting kaynak limitlerinin tek tek ne anlama geldiğini anlattığımız rehberde bulabilirsiniz, tanımları burada tekrarlamayacağız. Teşhis için bilmeniz gereken asıl nokta şu: EP saniyedeki istek sayısını saymaz, aynı anda süren istek sayısını sayar. Bir istek ne kadar uzun sürerse yuvası o kadar uzun dolu kalır.

Varsayımsal senaryo: Bir mağazaya saniyede 4 dinamik istek geliyor ve her biri yarım saniyede tamamlanıyor. Ortalamada aynı anda yalnız 2 istek açıktır. Bir gün eklentilerden birinin bağlandığı kur servisi yanıt vermemeye başlıyor, her istek 8 saniyelik zaman aşımını bekliyor. Trafik aynı kaldığı hâlde eşzamanlı istek sayısı 32'ye çıkar ve EP limiti 20 olan bir hesapta 508 başlar. Ziyaretçi sayısı artmadan bu hatayı görebilmenizin nedeni budur. 508 ile aynı saatte CPU ya da IO arızası da görüyorsanız istekler büyük olasılıkla uzamıştır.

Bu kod CloudLinux'un hesap başına kaynak sınırlama katmanından gelir, kontrol panelinden bağımsızdır. Arka planda LVE'nin her hesabı ayrı bir kaynak kutusunda çalıştırma mantığı yatıyor. Plesk panelli bir hostingde 508 görüyorsanız aşağıdaki cPanel ekranları sizde olmayacaktır. Hatanın göründüğü adresi ve saati not edip doğrudan destek talebi açmak daha hızlı sonuç verir.

Hangi limit, hangi saatte doldu?

Bakacağınız yer cPanel'in Metrics bölümündeki CPU and Concurrent Connection Usage arayüzüdür. Bazı sağlayıcılar ve eski temalar aynı ekranı Resource Usage adıyla gösterir. cPanel belgesine göre arayüz yalnız CloudLinux çalışan sunucularda bulunur ve sağlayıcı onu WHM'deki Feature Manager'dan kapatabilir. Menüde yoksa açılmasını isteyin ya da kullanım verilerini destek ekibinden talep edin.

Ekranda üç sekme var. Dashboard son 24 saatte hesabın sınırlanıp sınırlanmadığını özetler. Current Usage kullanım tablosunu, geçmişi ve grafikleri verir. Snapshot ise arıza anında kaydedilmiş işlem ve istek listelerini gösterir.

Current Usage geçmişini okumak

Üstteki tabloda her limit için Description, Usage, Limit ve Fault sütunları bulunur. Asıl iş aşağıdaki geçmiş tablosunda: From-To aralığı, A (ortalama kullanım), L (limit) ve F (arıza sayısı). Şu sırayla ilerleyin:

1. Zaman aralığını 508'i gördüğünüz günü kapsayacak şekilde seçin, birimi saat yapın.
2. F değeri sıfırdan büyük olan satırları ve hangi limitte olduklarını not edin.
3. Aynı satırda EP'nin yanında başka hangi limitlerin arıza verdiğine bakın. Bu birliktelik nedeni daraltır.
4. En yoğun saati dakika birimine indirip arızaların başladığı ve bittiği dakikayı yazın. Erişim günlüğünde tam olarak bu aralığı arayacaksınız.

Yaygın bir yanılgı, A sütununa bakıp "kullanım limitin yarısında, sorun bende değil" demektir. Ortalama birkaç saniyelik tepeleri yutar. EP satırında saatlik ortalama 6 görünürken aynı saat içinde onlarca arıza olabilir, çünkü sınıra yalnız kısa anlarda dayanılmıştır.

Snapshot sekmesi neyi yakalar?

Limit aşıldığında CloudLinux'un istatistik bileşeni (lve-stats) o anın bir görüntüsünü kaydeder. Snapshot sekmesinde tarih ve görüntü seçtiğinizde çalışan işlemleri PID, CMD, CPU ve MEM sütunlarıyla görürsünüz. cPanel sunucularında o sırada süren veritabanı sorguları ve HTTP istekleri de süre ve adresleriyle listelenir. 508 avında en değerli veri genellikle bu HTTP listesidir. Aynı adres birkaç görüntüde tekrar ediyorsa, örneğin /?s= ile başlayan aramalar, /wp-admin/admin-ajax.php ya da /wp-cron.php, ipucu güçlüdür.

Her arıza için görüntü tutulmayabilir. CloudLinux belgesine göre dakikada kaydedilen görüntü sayısı sunucu ayarıyla sınırlanır ve birbirine yakın arızalar tek olay sayılır. Görüntünün olmaması bir şey kanıtlamaz, o zaman doğrudan erişim günlüğüne geçin. Bulduğunuz görüntüleri ekran görüntüsü olarak saklayın.

O dakikalarda siteye ne geldi?

Diyelim ki geçmiş tablosu 14:10 ile 14:40 arasında yoğun EP arızası gösteriyor. Şimdi aynı yarım saati erişim günlüğünde açıp kimin, hangi adrese, ne sıklıkla geldiğini çıkaracağız.

Ham günlüğü nereden alırsınız?

cPanel'de Metrics altındaki Raw Access arayüzü, her alan adının ham erişim günlüğünü .gz dosyası olarak indirmenize izin verir. Aynı ekrandaki "Archive log files in your home directory after the system processes statistics" seçeneği kapalıysa eski günler, istatistikler işlendikten sonra elinizden çıkabilir. cPanel istatistikleri varsayılan olarak 24 saatte bir işler. Sorun tekrarlıyorsa bu seçeneği şimdi açın ki bir sonraki olayda geriye bakabilesiniz.

Kabuk erişiminiz varsa (SSH ya da cPanel Terminal, her pakette açık olmayabilir) güncel günlükler ana dizindeki ~/access-logs/ klasöründe durur. HTTPS trafiği alan adının sonuna -ssl_log eklenmiş dosyaya, HTTP trafiği yalnız alan adını taşıyan dosyaya yazılır. Terminaliniz yoksa indirdiğiniz .gz dosyasını kendi bilgisayarınızda (Linux, macOS ya da Windows'ta WSL) aynı komutlarla inceleyebilirsiniz, grep yerine zgrep yazmanız yeterli.

İki tuzak var. Satırlardaki saat, köşeli parantez içindeki tarihin sonunda yazan dilimle (+0000, +0300 gibi) kaydedilir. Kaynak kullanım ekranındaki saatle eşleştirmeden önce ikisini aynı dilime çevirin. Site Cloudflare gibi bir vekil sunucunun arkasındaysa ve sunucu gerçek ziyaretçi adresini geri yazmıyorsa ilk sütunda ziyaretçiler yerine vekilin IP'leri görünür. O durumda IP sayımı yanıltır, adres ve user agent sayımına ağırlık verin.

Beş komutla o saatin dökümü

Örneklerde günlük dosyası ~/access-logs/ornek.com.tr-ssl_log, aranan zaman 29 Ekim 2026 saat 14 olarak geçiyor. Komutların hepsi yalnız okuma yapar. Önce o saatte kaç istek geldiğine bakın:

grep '29/Oct/2026:14:' ~/access-logs/ornek.com.tr-ssl_log | wc -l

Tek başına toplam az şey söyler. Dakikalara dağıtınca patlamanın biçimi ortaya çıkar:

grep '29/Oct/2026:14:' ~/access-logs/ornek.com.tr-ssl_log \
  | awk '{print substr($4, 14, 5)}' | sort | uniq -c

Çıktının her satırı bir istek sayısı ve bir dakikadır. Sakin dakikalarda birkaç düzine istek görürken arıza dakikalarında bunun on katı görüyorsanız bir patlama var demektir. Sayılar olağan seyrediyor ama arızalar sürüyorsa istekler uzamıştır, tablodaki CPU ve IO satırlarına dönün.

En çok istek gönderen adresler:

grep '29/Oct/2026:14:' ~/access-logs/ornek.com.tr-ssl_log \
  | awk '{print $1}' | sort | uniq -c | sort -rn | head -n 15

En çok istenen yollar, sorgu dizesi atılmış hâliyle:

grep '29/Oct/2026:14:' ~/access-logs/ornek.com.tr-ssl_log \
  | awk '{print $7}' | cut -d'?' -f1 | sort | uniq -c | sort -rn | head -n 15

Son olarak en sık görünen user agent değerleri:

grep '29/Oct/2026:14:' ~/access-logs/ornek.com.tr-ssl_log \
  | awk -F'"' '{print $6}' | sort | uniq -c | sort -rn | head -n 10

Bu komutlar günlüğün yaygın birleşik (combined) biçimde tutulduğunu varsayar: birinci alan IP, dördüncü alan tarih, yedinci alan istenen yol, satır çift tırnaktan bölündüğünde altıncı parça user agent'tır. Sunucunuz başka bir biçim kullanıyorsa birkaç satırı head ile açıp alan sırasını kontrol edin. Günlükte 508 yanıtları da kayıtlıysa hangi adreslere döndüğünü awk '$9 == 508 {print $7}' ile ayrıca süzebilirsiniz.

Günlükte sık çıkan dört desen

Sık görülen tablo, user agent listesinin tepesine bir SEO tarayıcısının, fiyat karşılaştırma botunun ya da kendini hiç tanıtmayan bir betiğin oturmasıdır. Bu botlar genellikle önbelleği olmayan adresleri tarar: filtre, sıralama ve sayfalama kombinasyonları. WooCommerce mağazalarında ?add-to-cart= içeren bağlantıları izleyen botlar da sık görülür. Her biri sepete ürün ekleyen ve önbelleğe girmeyen ayrı bir istektir.

Yol listesinde /wp-login.php ya da /xmlrpc.php öne çıkıyor ve bunlar POST isteğiyse parola denemeleriyle karşı karşıyasınız. Kaç tane olduklarını şöyle sayarsınız:

grep -cE '"POST /(wp-login|xmlrpc)\.php' ~/access-logs/ornek.com.tr-ssl_log

Üçüncü desen aramadır. /?s= ile gelen her arama veritabanında sorgu çalıştırır ve sayfa önbelleğine girmez. Botlar arama kutusuna rastgele kelimeler, kimi zaman spam metinler doldurur. Dakikada yüzlerce farklı arama, EP'yi birkaç dakikada doldurmaya yeter.

Dördüncüsü sitenin kendi ürettiği trafiktir. Sunucunun kendi IP'sinden gelen sık POST /wp-cron.php?doing_wp_cron= satırları, WordPress zamanlayıcısının ziyaretlerle tetiklendiğini gösterir ve her biri ayrı bir PHP isteğidir. Oturum açmış kullanıcılardan gelen yoğun /wp-admin/admin-ajax.php istekleri ise çoğunlukla açık bırakılmış yönetim sekmelerinin Heartbeat çağrılarıdır.

Limit türüne göre çözüm

Önlemleri birer birer uygulayın ve her birinden sonra bir yoğun dönem bekleyin. Hepsini aynı akşam açarsanız hangisinin işe yaradığını bilemezsiniz. Geri almanız gerektiğinde neyi geri alacağınızı da bilemezsiniz.

EP arızası: aynı anda açık istek sayısını düşürün

İlk kaldıraç sayfa önbelleğidir. Önbellekten sunulan sayfa PHP'ye hiç uğramaz, dolayısıyla EP yuvası da tüketmez. LiteSpeed çalışan sunucularda bunu LSCache eklentisiyle kurarsınız, LiteSpeed Cache'in kurulum ve önbellek ayarlarını ayrı bir rehberde adım adım verdik. Kurmak yetmez, sayfanın gerçekten önbellekten gelip gelmediğini yanıt başlıklarındaki HIT ve MISS değerlerinden kontrol edin. Eklenti açık görünürken her yanıtta MISS dönen siteler sandığınızdan sık.

Botlarda robots.txt yalnız kurallara uyan tarayıcıları durdurur, kendini tanıtmayan betikler onu okumaz bile. Uyanlar için de bir ayrıntı var: Googlebot crawl-delay satırını dikkate almaz. Arama sonuçları ve filtre adresleri gibi değersiz kombinasyonları robots.txt'te Disallow ile kapatmak düzgün botların yükünü azaltır. Kuralsız olanları ise güvenlik eklentisinin ya da web uygulaması güvenlik duvarının (WAF) user agent ve IP kurallarıyla engellemeniz gerekir.

Giriş denemelerinde engellemenin hangi katmanda yapıldığı önemli. WordPress'in xmlrpc_enabled süzgeci, belgesine göre yalnız kimlik doğrulama gerektiren XML-RPC yöntemlerini kapatır, pingback'leri kapsamaz ve her istek WordPress'i yine baştan yükler. Yani EP tüketimi sürer. XML-RPC kullanmıyorsanız (Jetpack ve bazı mobil uygulamalar kullanır) isteği PHP'ye ulaşmadan web sunucusu düzeyinde kesmek çok daha az kaynak harcar. Apache 2.4 sözdizimiyle bir .htaccess örneği:

<Files "xmlrpc.php">
    Require all denied
</Files>

Değiştirmeden önce .htaccess dosyasının bir kopyasını .htaccess.yedek adıyla alın. Kuralı ekledikten sonra sonucu dışarıdan doğrulayın, aşağıdaki komut 403 yazmalı. Başka bir kod (çoğunlukla 200) görüyorsanız kural uygulanmıyordur, sunucunuz bu sözdizimini işlemiyor olabilir ve engellemeyi güvenlik eklentisiyle yapmanız gerekir:

curl -s -o /dev/null -w "%{http_code}\n" \
  -X POST https://ornek.com.tr/xmlrpc.php

wp-login.php'yi kapatamazsınız ama deneme sayısını sınırlayabilir, mümkünse IP kısıtı koyabilirsiniz. Seçenekleri WordPress yönetim girişini koruma önlemleri arasında topladık.

Senaryodaki gibi istekler bir dış servisi bekleyerek uzuyorsa önbellek ve bot önlemi tek başına yetmez. Hangi eklentinin hangi adrese bağlanıp ne kadar beklediğini Query Monitor'ün HTTP API çağrıları panelinde görürsünüz. Çözüm o eklentinin zaman aşımını kısaltmak, yanıtını önbelleğe almak ya da eklentiyi değiştirmektir.

CPU (SPEED) arızası: istek başına işi azaltın

İşlemci limitine takılan hesapta istekler reddedilmez, sıraya girer. Sıra uzadıkça EP de dolar. Burada sorulacak soru, her isteğin ne kadar iş yaptığıdır. Önbelleğe girmeyen sayfalar (sepet, ödeme, hesabım, arama) ve yönetim paneli işlemciyi en çok yoran yerlerdir. Ağır sayfa oluşturucular, her sayfada çalışan ilgili ürün ya da istatistik eklentileri ve eski PHP sürümü de payını alır. Bir eklentiyi suçlamadan önce ölçün. Hazırlık kopyasında eklentileri tek tek kapatıp sayfa üretim süresini karşılaştırmak, tahminden çok daha hızlı sonuç verir.

IO ve IOPS: diski kim meşgul ediyor?

Disk limitleri işlemleri uyutur, yani yavaşlatır. 508 ile aynı saate denk gelen IO arızalarında ilk şüpheli zamanlanmış işlerdir: yedek eklentisinin gündüz çalışan arşivlemesi, ürün içe aktarma, görsel yeniden boyutlandırma. Önbelleğin tamamını temizledikten hemen sonra da kısa bir IO tepesi görülebilir, çünkü boş önbelleğe gelen her istek sayfayı yeniden üretip diske yazar. Snapshot'taki veritabanı sorgularında aynı sorgu uzun sürelerle tekrar ediyorsa indeks eksikliği ya da şişmiş bir tablo akla gelir. Ağır işleri gece saatlerine almak ve yedek arşivini hesapta bekletmeden dışarı göndermek çoğu zaman yeterli olur.

NPROC ve PMEM: ekranda 500 ya da 503 varsa

Bu iki limit ziyaretçiye 508 olarak değil, çoğunlukla 500 veya 503 olarak yansır. Uygulama kaynaklı hatalardan ayırmak için önce hata günlüğüne bakın. Eklenti, tema ve .htaccess kaynaklı olanların teşhisini WordPress 500 hatası ve beyaz ekran adımlarında topladık.

Kaynak kaynaklı olanlarda sık görülen nedenlerden biri üst üste binen cron işleridir. Beş dakikada bir başlayan bir görev bazen yedi dakika sürerse bir sonraki kopya öncekinin üstüne biner ve işlem sayısı katlanır. wp-cron'u sunucu cron'una bağladıysanız komutun başına flock -n eklemek, önceki çalıştırma bitmeden yenisinin başlamasını engeller. Kilit alınamazsa yeni kopya hiç çalışmadan çıkar. cPanel Cron Jobs ekranındaki komutunuz örneğin şöyleyse:

/usr/local/bin/php ~/public_html/wp-cron.php

kilitli hâli şu olur (PHP'nin yolu sunucudan sunucuya değişir, mevcut komutunuzda ne yazıyorsa onu koruyun):

flock -n ~/.wpcron.lock /usr/local/bin/php ~/public_html/wp-cron.php

Düzeldiğini nasıl anlarsınız?

Tek bir sakin öğleden sonra kanıt sayılmaz. Botlar dalga dalga gelir, kampanya trafiği haftanın belli günlerine yığılır. Bizim kullandığımız ölçüt basit: önlemden önceki en kötü saat aralığını, bir hafta sonra aynı gün ve saatte yeniden karşılaştırırız.

1. Current Usage geçmişinde aynı aralıkta EP satırının F değeri sıfıra ya da birkaç tekil arızaya indi mi?
2. Snapshot sekmesinde yeni olay kaydı oluşmuyor mu?
3. Aynı komutlarla sayılan wp-login.php ve xmlrpc.php POST'ları ile bot istekleri düştü mü?
4. Önbelleğe alınabilir sayfalar ardışık iki istekte HIT dönüyor mu?
5. Günlükte 508 yanıt kodu kaldı mı?

Geri alma da aynı disiplinle yapılır. Bir önlem bir şeyi bozduysa, örneğin XML-RPC kapatıldıktan sonra mobil uygulama bağlanamıyorsa, yalnız o kuralı kaldırın, diğerlerine dokunmayın. Aldığınız .htaccess.yedek kopyası bu işi saniyelere indirir.

Paket yükseltmesi ne zaman gerçekten gerekir?

Şunu baştan söyleyelim: bot trafiğini süzmeden paketi büyütmek eşiği biraz yukarı taşır, sorunu bitirmez. Botlar yeni limiti de doldurur. Yükseltmeyi, şu işaretler birlikte göründüğünde gerçek bir ihtiyaç olarak görüyoruz. Arıza saatleri gerçek ziyaretçi tepeleriyle (kampanya, bülten gönderimi, reklam yayını) örtüşüyordur. Günlükte o dakikalarda çok sayıda farklı IP ve olağan tarayıcı kimlikleri vardır. Yüklenen sayfalar da büyük ölçüde önbelleğe alınamayan sepet, ödeme ve hesap sayfalarıdır, önbelleklenebilir sayfalar ise zaten HIT dönmektedir.

Böyle bir durumda önce aynı panel ailesinde daha yüksek limitli bir pakete bakmak mantıklıdır. cPanel web hosting paketlerinin kaynak değerlerini paket ayrıntısında karşılaştırın. Aynı hesapta birden çok site barındırıyorsanız hepsinin aynı EP havuzunu paylaştığını hesaba katın, tek bir sitenin bot trafiği diğerlerine de 508 verdirir. Yoğunluk kalıcı hâle geldiyse ya da paylaşımlı ortamda kuramayacağınız ayarlara (kendi PHP-FPM havuzunuz, veritabanı yapılandırması) ihtiyaç duyuyorsanız hesap başı LVE sınırının olmadığı bir VPS sanal sunucu daha doğru adımdır. Orada kaynakların nasıl paylaştırılacağına siz karar verirsiniz, izlemek de size düşer.

Destek talebine hangi bilgileri ekleyin?

Netx müşterisiyseniz müşteri panelinden destek talebi açabilirsiniz. "Sitem 508 veriyor" cümlesi tek başına bizi sizin az önce baktığınız ekranlara geri götürür. Şunları eklerseniz inceleme bir sonraki adımdan başlar:

• Alan adı ve 508'in görüldüğü tam adresler
• Tarih, saat aralığı ve saatleri hangi dilime göre yazdığınız
• Current Usage geçmişinin F sütunu görünen ekran görüntüsü, varsa Snapshot görüntüleri
• Günlükten çıkardığınız ilk 10 IP, yol ve user agent listesi
• Sorun başlamadan önce yapılan değişiklikler: yeni eklenti, tema güncellemesi, kampanya
• Şimdiye kadar uyguladığınız önlemler ve uygulandıkları saat

Plesk panelli hostingde 508 görüyorsanız aynı listeyi kullanın. Kaynak kullanım ekranınız olmayacağı için hatanın ekran görüntüsü, adres ve saat bilgisi yeterlidir, sunucu tarafındaki kayıtların incelenmesini destek ekibinden isteyin.