508 Resource Limit Is Reached Hatası Nedir, Ne Yapmalı?

Sitenizi açtığınızda beyaz bir sayfada sadece "508 Resource Limit Is Reached" yazısını görüyorsanız, sunucu size şunu söylüyor: hesabınıza tanımlı kaynak limitlerinden en az biri o an tavana vurdu ve yeni istekler kabul edilmiyor. Bu bir yazılım hatası değil, bir kota uyarısıdır. Birkaç dakika sonra sayfayı yenilediğinizde site normal açılıyorsa, bu tanı doğrudur: kaynak limiti aşıldı hatası genellikle kalıcı değil, dalgalıdır. Ama dalgalı olması sorunun küçük olduğu anlamına gelmez — ziyaretçilerinizin ve Googlebot'un o dalgalara denk gelen kısmı siteyi kapalı görür.

Bu yazının varlık sebebi şu: Türkçe kaynakların neredeyse tamamı bu hatayı "paketinizi yükseltin" cümlesiyle geçiştiriyor. Oysa cPanel kaynak limiti ekranı size hangi limitin dolduğunu tek tek söyler ve her limitin çözümü bambaşkadır. CPU'su dolan bir siteye RAM eklemek hiçbir işe yaramaz; Entry Processes limiti dolan bir sitede ise sorun çoğu zaman paket küçüklüğü bile değildir, tek bir bot sürüsüdür. Aşağıda önce ekranı okumayı, sonra her limit için ne yapılacağını, en sonda da paket yükseltmenin gerçekten doğru karar olduğu durumu anlatıyorum.

508 Resource Limit Is Reached Hatası Ne Anlama Geliyor#

508 hatası, hesabınızın işletim sistemi seviyesindeki kaynak kabına sığmadığı anda üretilir. Türkiye'deki paylaşımlı hosting sunucularının ezici çoğunluğu CloudLinux üzerinde çalışır ve CloudLinux her cPanel hesabını LVE (Lightweight Virtual Environment) adı verilen ayrı bir kaba koyar. Bu kap sayesinde bir hesabın çıldırması diğer 200 hesabı yavaşlatamaz. Kabın duvarına çarpan istek ise reddedilir ve tarayıcıya 508 döner. CloudLinux'un ne yaptığını daha ayrıntılı merak ediyorsanız cloudlinux nedir yazısı bu mimariyi baştan anlatıyor.

Burada kritik ayrım şudur: 508, PHP'nin ürettiği bir hata değildir. PHP kendi belleği bittiğinde size allowed memory size exhausted hatası verir ve bu hata error_log dosyasına düşer. 508 ise PHP çalışmaya başlayamadan, kabın kapısında verilir. Bu yüzden wp-content/debug.log dosyanızda hiçbir iz bulamazsınız — aramanız gereken yer uygulama değil, cPanel'in kaynak grafikleridir.

Diğer bir yaygın karışıklık 429 ile olur. Kullanıcı başına istek sınırı aşıldığında dönen 429 too many requests hatası tek bir IP'yi hedefler; 508 ise tüm hesabı kapsar, ziyaretçi kim olursa olsun herkes aynı ekranı görür. Ekrandaki metnin hangisi olduğunu not almak, teşhisin ilk adımıdır.

Hangi Limit Doldu: cPanel Resource Usage Ekranını Okumak#

Sorunun cevabı cPanel'de Metrics → Resource Usage ekranındadır ve buraya bakmadan atılacak her adım tahmindir. Ekranı açtığınızda üç sekme görürsünüz:

1. Current Usage — o anki anlık kullanım. Site şu an ayaktaysa buradaki değerler düşük görünür, panik yapmayın.
2. Snapshots — asıl bakmanız gereken yer. Sistem, limitin dolduğu anlarda anlık görüntü alır ve o saniyede hangi süreçlerin çalıştığını listeler.
3. Details / Faults — son 24 saat ve son 30 gün için her limit türünün kaç kez ihlal edildiğini (fault sayısı) gösterir.

Details sekmesinde "Faults" sütunu sıfırdan büyük olan satır, sizin suçlunuzdur. Genellikle tek bir satır kabarıktır; ikisi birden yüksekse çoğunlukla biri diğerinin sonucudur (örneğin CPU tavana vurunca istekler birikir ve Entry Processes de dolar — kök neden CPU'dur).

Aşağıdaki tablo, hangi limitin ne anlama geldiğini ve doğru müdahalenin ne olduğunu özetliyor:

Snapshots sekmesindeki süreç listesini okumayı da öğrenin: orada /usr/local/bin/php /home/kullanici/public_html/wp-cron.php gibi tam komut satırları görürsünüz. O satır size hangi dosyanın limiti yediğini doğrudan söyler.

CPU Limiti Doluyorsa Ne Yapmalı#

CPU limitinin çözümü daha fazla CPU almak değil, aynı sayfayı daha az hesaplayarak üretmektir. Paylaşımlı bir pakette CPU limiti genellikle bir çekirdeğin belirli bir yüzdesi olarak verilir; yani "%100" tek çekirdeğin tamamı demektir. Bir WordPress ana sayfası önbelleksiz çalışıyorsa her istekte onlarca veritabanı sorgusu ve yüzlerce PHP dosyası derlenir. Aynı sayfayı önbellekten sunduğunuzda CPU maliyeti neredeyse sıfıra iner.

Sırasıyla şunları yapın:

1. Sayfa önbelleğini açın. Sunucunuz LiteSpeed kullanıyorsa litespeed cache wordpress ayarları en hızlı kazancı verir; Apache tarafında ise wordpress önbellek rehberi içindeki dosya tabanlı önbellek seçenekleri iş görür.
2. OPcache'in açık olduğunu doğrulayın. cPanel → MultiPHP INI Editor içinden ya da bir phpinfo() sayfasıyla kontrol edin. Kapalıysa her istekte tüm PHP dosyaları yeniden derlenir. Ayrıntı için php opcache yazısına bakın.
3. PHP sürümünü yükseltin. cPanel → Select PHP Version ekranından güncel bir sürüme geçmek, hiçbir kod değişikliği yapmadan CPU tüketimini gözle görülür düşürür. Sürüm seçim mantığı php selector cloudlinux yazısında anlatılıyor.
4. Ağır eklentiyi bulun. Eklentileri teker teker kapatmak yerine, Snapshots ekranındaki süreç listesine ve yavaş sorgulara bakın. Çakışma avı için wordpress eklenti çakışması yöntemi birebir uygulanabilir.

Deneyimimde CPU limitini en sık patlatan üç şey şudur: gerçek zamanlı ziyaretçi sayacı eklentileri, her sayfa yüklemesinde dış API'ye giden döviz/kargo eklentileri ve ürün sayısı büyümüş bir WooCommerce kurulumunda filtrelenmemiş kategori sorguları.

Physical Memory Limiti Doluyorsa Ne Yapmalı#

Bellek limitinde yapılacak ilk iş, memory_limit değerini yükseltmeye çalışmamaktır. Bu ikisi farklı şeylerdir: memory_limit PHP'nin kendine koyduğu tavandır, Physical Memory ise CloudLinux'un hesabınıza koyduğu duvardır. PHP'ye 1024M yazsanız bile kabınız 512M ise süreç yine öldürülür — üstelik bu kez daha çirkin biçimde, yarım kalmış bir sayfayla.

Doğru sıralama şudur:

1. Snapshots ekranından bellek zirvesinin hangi süreçte oluştuğunu okuyun. php mi, mysqld mi, cpanel-backup mı?
2. Süreç php ise, komut satırındaki dosya adına bakın. wp-cron.php sık görülür; site trafiği arttığında WordPress'in kendi zamanlanmış görev sistemi her ziyaretle tetiklenir ve üst üste biner.
3. Süreç bir içe/dışa aktarma dosyasıysa (örneğin wp-admin/admin.php?import=...), tek seferlik bir iştir; işlemi parça parça yapın.
4. Bellek zirvesi görsel işleme sırasında oluşuyorsa, yüklenen görselleri yükleme öncesi küçültün. Ayrıntı: wordpress görsel optimizasyonu.

WordPress'te wp-cron'u ziyaretçiden koparmak, bellek ve CPU limitlerinin ikisini birden rahatlatan tek satırlık bir kazançtır. wp-config.php içine şunu ekleyin:

define( 'DISABLE_WP_CRON', true );

Ardından cPanel → Cron Jobs ekranından gerçek bir zamanlanmış görev tanımlayın:

/usr/local/bin/php -q /home/kullanici/public_html/wp-cron.php >/dev/null 2>&1

Bunu 15 dakikada bir çalıştırmak çoğu site için fazlasıyla yeterlidir ve zirve saatlerde onlarca eşzamanlı cron sürecinin doğmasını engeller.

Entry Processes ve Number of Processes Limitleri#

Entry Processes, "şu anda aynı anda çalışan kaç PHP isteğin var" sorusunun cevabıdır ve 508 hatasının en sık sebebidir. Paylaşımlı paketlerde bu sayı genellikle onlu rakamlarla ifade edilir. Kritik nokta şudur: bir istek ne kadar uzun sürerse, o slotu o kadar uzun işgal eder. Yani EP limitini yalnızca trafik değil, yavaşlık da patlatır. 20 slotunuz varsa ve her sayfa 0,3 saniyede üretiliyorsa saniyede ~66 isteği rahat karşılarsınız; aynı sayfa 3 saniyeye çıktığında kapasiteniz onda birine düşer.

Bu yüzden EP limitinde iki cephe vardır:

• İstek sayısını azaltmak: Sayfa önbelleği sayesinde önbellekten dönen istek PHP başlatmaz, dolayısıyla EP slotu tüketmez. Bot trafiğini kesmek de aynı işi görür (bir sonraki bölüm).
• İstek süresini kısaltmak: Yavaş sorgu, yavaş dış API çağrısı ve büyük wp_options tablosu en yaygın üçlüdür. wordpress veritabanı optimizasyon adımları burada doğrudan işe yarar.

Number of Processes (NPROC) ise PHP dışındaki her şeyi de sayar: SSH oturumunuz, wp-cli komutu, yedekleme scripti, arka planda takılı kalmış bir convert süreci. NPROC faults görüyorsanız cPanel Terminal veya SSH üzerinden şunu çalıştırın:

ps -u $(whoami) -o pid,etime,pcpu,pmem,cmd --sort=-etime | head -30

etime sütunu saatlerce açık kalmış süreçleri ele verir. Genellikle iptal edilmiş bir içe aktarma ya da bitmemiş bir yedekleme işi bulursunuz. Süreç yönetimi konusuna süreç izleme ps top htop yazısından derinlemesine bakabilirsiniz.

I/O ve IOPS Limitleri: Sessiz Katil#

I/O limitleri, sitenin trafiği düşükken bile 508 vermesinin en yaygın açıklamasıdır. I/O saniyede kaç kilobayt okuyup yazdığınızı, IOPS ise kaç ayrı disk işlemi yaptığınızı ölçer. Bu ikisi bağımsızdır: 4 KB'lık on bin dosyayı okumak, 400 MB'lık tek dosyayı okumaktan çok daha fazla IOPS harcar.

Pratikte tetikleyiciler şunlardır:

• Log dosyalarının şişmesi. error_log dosyası her istekte bir uyarı yazıyorsa, disk yazma trafiği sabit biçimde yüksek kalır. Önce hata kaynağını bulun; cpanel hata kayıtları yazısı dosyaların yerini ve okuma biçimini anlatıyor.
• Otomatik yedekleme eklentileri. Site içinden çalışan tam yedekleme, tüm public_html ağacını okur ve sıkıştırır. Bunu trafik saatlerinin dışına almak ya da sunucu tarafı yedeklemeye bırakmak gerekir.
• Oturum dosyaları. PHP oturumları dosya tabanlı ise ve siteye bot yağıyorsa /tmp altında on binlerce küçük dosya oluşur.
• Optimize edilmemiş veritabanı. Dizin (index) eksikliği yüzünden MySQL tablo taraması yapıyorsa, IOPS grafiği trafikle orantısız biçimde yükselir.

Disk alanı ile disk hızını da karıştırmayın; alan doluluğu ayrı bir konudur ve cpanel disk kullanımı ekranından takip edilir. Ama şunu ekleyelim: inode sayınız (dosya adedi) tavana yaklaştığında hem yedekleme hem tarama süreçleri ağırlaşır, dolayısıyla dolaylı olarak IOPS'u da yükseltir.

Bot Trafiği mi, Gerçek Ziyaretçi mi: Erişim Kayıtlarını Okumak#

508 hatasının arkasında çoğu zaman ziyaretçi değil, robot vardır ve bunu on dakikada kanıtlayabilirsiniz. cPanel'de ham erişim kayıtları ~/access-logs/ altında durur. Terminal veya SSH ile şu üç komutu çalıştırın:

# En çok isteği hangi IP yaptı
awk '{print $1}' ~/access-logs/alanadiniz.com | sort | uniq -c | sort -rn | head -20

# En çok hangi tarayıcı kimliği (user-agent) geldi
awk -F'"' '{print $6}' ~/access-logs/alanadiniz.com | sort | uniq -c | sort -rn | head -20

# En çok hangi adres istendi
awk '{print $7}' ~/access-logs/alanadiniz.com | sort | uniq -c | sort -rn | head -20

Üçüncü komutun çıktısında /xmlrpc.php, /wp-login.php ya da /?s= ile başlayan yüzlerce satır görüyorsanız teşhis nettir. Arama parametreli istekler önbelleklenemez, her biri tam bir PHP isteği doğurur ve EP limitini dakikalar içinde bitirir.

Müdahale seçenekleri:

# .htaccess — agresif tarayıcı botlarını reddet
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (MJ12bot|DotBot|PetalBot|SeznamBot|Bytespider) [NC]
RewriteRule .* - [F,L]

# xmlrpc.php'yi tamamen kapat
<Files "xmlrpc.php">
  Require all denied
</Files>

XML-RPC'yi kapatmanın yan etkilerini bilmeden uygulamayın; ayrıntı wordpress xml-rpc kapatma yazısında. Tek bir IP taşkın yapıyorsa cPanel'in IP Blocker aracı daha temiz bir çözümdür: cpanel ip engelleyici.

Meşru arama motoru botlarını engellemeyin; onları robots.txt ile yavaşlatın. Zararlı istekleri ise sunucuya hiç ulaşmadan filtrelemek istiyorsanız, önünüze bir güvenlik katmanı koymak (bkz. web uygulama güvenlik duvarı waf) EP limiti üzerindeki baskıyı kalıcı olarak düşürür.

Paket Yükseltmek Ne Zaman Gerçekten Doğru Karar#

Paket yükseltmek, limitleri optimize edilmiş bir site aştığında doğru karardır; optimize edilmemiş bir sitede ise sadece 508'in geleceği tarihi erteler. Ayrımı şu sorularla yapın:

• Sayfa önbelleği açık, OPcache açık, güncel PHP sürümü kullanılıyor mu?
• Erişim kayıtlarında bot taşkını yok mu, trafik gerçekten insan mı?
• Snapshots ekranındaki zirveler tek bir eklentiye/dosyaya değil, genel olarak sitenin tamamına mı dağılıyor?
• Zirveler kampanya ve haber dönemlerinde değil, her gün düzenli olarak mı oluşuyor?

Dördüne birden "evet" diyorsanız siteniz paketini gerçekten aşmıştır. Bu noktada iki yol var: daha geniş limitli bir paylaşımlı paket ya da kaynakların size ayrıldığı bir sanal sunucu. İkincisinde artık EP/LVE kavramı ortadan kalkar, yerine PHP-FPM havuz ayarları ve gerçek CPU/RAM tahsisi gelir; bu geçişin ne getirip ne götürdüğünü shared vs vps hosting yazısı karşılaştırıyor. Taşınma kararı verirseniz web sitesi taşıma adımları kesintiyi en aza indirmenize yardım eder.

Bir uyarı: e-ticaret sitelerinde sepet, ödeme ve hesabım sayfaları tanım gereği önbelleklenemez. Yani WooCommerce büyüdükçe EP baskısı yapısal olarak artar ve bir noktadan sonra optimize etmek yetmez. Bu, "paketi büyütmeye" en meşru geçiş sebebidir.

Sıkça Sorulan Sorular#

508 hatası sitemin hacklendiği anlamına gelir mi#

Hayır, 508 doğrudan bir güvenlik ihlali göstergesi değildir; kaynak limitinin dolduğunu söyler. Ancak ele geçirilmiş bir sitede spam gönderen ya da madencilik yapan bir script çalışıyorsa, bunun ilk belirtisi çoğu zaman açıklanamayan CPU ve I/O zirveleridir. Snapshots ekranında tanımadığınız bir dosya adı görüyorsanız (public_html altında rastgele isimli PHP dosyaları gibi) mutlaka bir zararlı yazılım taraması yapın. Erişim kayıtlarında hiç bilmediğiniz adreslere gelen yoğun istekler de aynı şüpheyi güçlendirir.

Kaynak limiti dolunca site tamamen mi kapanır#

Hayır, genellikle kapanmaz; sadece limitin dolu olduğu saniyelerde gelen istekler reddedilir. Kap boşaldığı anda site kendiliğinden normale döner, herhangi bir müdahale gerekmez. Bu yüzden birçok site sahibi hatayı "ara sıra oluyor" diye önemsemez. Oysa arama motorları o anlarda 508 aldığında sayfayı erişilemez sayar ve tarama sıklığını düşürür; yani görünmeyen bir SEO maliyeti vardır.

memory_limit değerini artırmak 508 hatasını çözer mi#

Hayır, çoğu durumda çözmez ve bazen durumu kötüleştirir. memory_limit PHP'nin kendi tavanıdır, 508 ise CloudLinux'un hesap kabının duvarıdır. PHP'ye kabınızdan büyük bir değer verirseniz süreç, kendi limitine ulaşamadan dışarıdan sonlandırılır ve sayfa yarım kalır. Doğru yaklaşım, tek bir isteğin neden bu kadar bellek istediğini bulmaktır.

Entry Processes limiti kaç olmalı#

Doğru sayı paketten çok sitenin hızına bağlıdır, bu yüzden tek bir ideal rakam yoktur. Kaba bir hesap için ortalama sayfa üretim sürenizi ölçün: 0,5 saniyede üretilen bir sayfada 20 slot, teorik olarak saniyede 40 isteği karşılar. Aynı slot sayısıyla 2 saniyelik bir sayfa ancak 10 istek taşır. Yani limiti büyütmeden önce sayfa üretim süresini yarıya indirmek, çoğu zaman limiti ikiye katlamakla aynı sonucu verir.

Snapshots ekranı boş görünüyorsa ne yapmalıyım#

Snapshots ekranının boş olması, o ana kadar hiçbir limit ihlali kaydedilmediği anlamına gelir. Bu durumda gördüğünüz 508 hatası büyük olasılıkla sizin hesabınızdan değil, sunucu genelindeki başka bir kısıttan ya da önünüzdeki bir güvenlik katmanından geliyordur. Ekrandaki tarih aralığını da kontrol edin; bazı kurulumlar yalnızca son 24 saati gösterir ve dünkü zirveler listelenmez. Hatanın tekrarladığı saati not alıp o saatte ekrana tekrar bakmak en sağlıklı yöntemdir.

508 hatası WordPress dışındaki sitelerde de görülür mü#

Evet, 508 uygulamadan bağımsızdır ve statik HTML dışındaki her kurulumda görülebilir. Joomla, PrestaShop, Laravel tabanlı özel yazılımlar ve hatta ağır bir Python uygulaması aynı LVE kabında çalışır ve aynı duvara çarpar. Fark yalnızca teşhis yolundadır: WordPress'te eklenti kapatarak ilerlersiniz, özel yazılımda ise yavaş sorguları ve dış servis çağrılarını ölçmeniz gerekir. Kabın kuralları her iki durumda da aynıdır.

Paylaşımlı hostingde SSH erişimim yoksa teşhisi nasıl yaparım#

SSH olmadan da teşhisin büyük bölümü yapılabilir. cPanel'in Terminal aracı varsa aynı komutları oradan çalıştırabilirsiniz; yoksa Metrics → Raw Access bölümünden erişim kayıtlarını sıkıştırılmış olarak indirip kendi bilgisayarınızda inceleyin. Resource Usage ekranının Snapshots sekmesi zaten hangi sürecin limiti yediğini gösterir ve bunun için terminale hiç ihtiyacınız yoktur. Dosya Yöneticisi üzerinden error_log dosyalarını okumak da çoğu vakada yeterli ipucu verir.

Kapanış#

508 Resource Limit Is Reached hatası, "sunucu bozuldu" değil "hesabın sınırına dayandın" demektir ve bu sınırın hangisi olduğunu size cPanel'in Resource Usage ekranı harfiyen söyler. Doğru sıra şudur: önce Faults sütunundan suçlu limiti bulun, sonra Snapshots'tan o limiti yiyen süreci görün, ardından o sürece özgü çözümü uygulayın. CPU için önbellek ve güncel PHP, bellek için tek bir ağır süreci ayıklamak, Entry Processes için önbellek artı bot filtresi, I/O için log ve yedekleme düzeni. Bu dört başlığı kapattığınızda çoğu site aynı pakette rahat rahat çalışmaya devam eder.

Bütün bunları optimize ettikten sonra hâlâ limitlere dayanıyorsanız, sorun artık site değil kaptır. Trafiği büyümüş bir WordPress veya kurumsal site için daha geniş limitli bir paylaşımlı hosting paketi çoğu zaman yeterli olur; sepet ve ödeme sayfaları önbelleklenemediği için sürekli PHP çalıştıran mağazalarda e-ticaret hosting tarafı daha rahat nefes aldırır. Kaynakların tamamen size ayrılmasını ve PHP-FPM havuzlarını kendiniz yönetmeyi istiyorsanız VDS sunucu doğru adımdır; sunucu yönetimiyle uğraşmak istemiyor, bu işi devretmek istiyorsanız sunucu yönetimi hizmeti izleme ve optimizasyonu üstlenir. Sitenizi hafifletme işini de dışarıya bırakmak isterseniz WordPress bakım paketleri tam olarak bu yazıdaki adımları düzenli aralıklarla uygular.