cPanel'de CPU ve RAM Kullanımı Nereden Görülür? Limit Aşımı Çözümü

Siteniz sabah gayet normal açılıyor, öğleden sonra bir anda kurşun gibi ağırlaşıyor, akşam üstü de birkaç dakikalığına tamamen kapanıp kendi kendine geri geliyor. Hosting firmasından "hesabınız CPU limitini aştı" başlıklı bir e-posta geldiyse ya da ziyaretçiler size "508 Resource Limit Is Reached" ekran görüntüsü gönderdiyse, doğru yerdesiniz. Bu tablonun tek bir cevabı vardır: cPanel kaynak kullanımı ekranını açıp hangi kaynağın dolduğuna bakmak. Ama asıl iş orada bitmiyor, orada başlıyor — çünkü grafik size "CPU %100'e vurdu" der, "bunu yapan şey şu eklentidir" demez.

Bu yazıda önce cPanel'in Kaynak Kullanımı (Resource Usage) ekranını sütun sütun okuyacağız: CPU, Sanal Bellek (RAM), Giriş İşlemleri (Entry Processes), I/O, IOPS ve en çok yanlış anlaşılan sütun olan Faults ne demek, hangisi dolunca ne olur. Ardından işin teşhis kısmına geçeceğiz: ham erişim kayıtlarından hangi botun sunucuyu yorduğunu, hangi WordPress eklentisinin her sayfa açılışında veritabanını dövdüğünü, hangi cron görevinin her dakika tetiklendiğini bulacağız. Son olarak da bulduğunuz şeyi düşürmenin gerçek yollarını — ve limitin gerçekten yetmediği durumda ne yapılması gerektiğini — tek tek göreceğiz.

cPanel'de Kaynak Kullanımı Ekranı Nerede#

cPanel'de kaynak kullanımı ekranı ana sayfada Metrikler (Metrics) bölümünün altında, çoğu temada Kaynak Kullanımı ya da Resource Usage adıyla durur. Sunucu CloudLinux ile yapılandırılmışsa bu ekranın adı LVE Kaynak Kullanımı olabilir; işlev aynıdır.

Ekrana girdiğinizde iki sekme görürsünüz:

1. Geçerli Kullanım (Current Usage) — son 24 saatte hangi kaynağın kaç kez limite dayandığını özetler.
2. Ayrıntılar / Snapshot — saatlik ya da dakikalık kırılımda grafik çizer.

İlk açılışta en tepede genelde şu iki cümleden biri yazar:

Your site has not been limited in the past 24 hours.

ya da limite dayanmışsanız:

Your site has been limited in the past 24 hours.

İkincisini gördüyseniz hemen aşağıdaki tabloya bakın; hangi kaynağın kaç kez sınıra vurduğunu orada listeler. Grafikte kırmızı ile taranmış alanlar limitin dolduğu dakikalardır. Grafiğin sağ üstünden zaman aralığını son 24 saat yerine son 7 gün yapmak, olayın tek seferlik mi yoksa her gün aynı saatte tekrar eden bir düzen mi olduğunu görmek için en hızlı yoldur — her gün 03:00'te vuruyorsa bu bir bot değil, bir zamanlanmış görevdir.

Sütunlar Ne Anlama Geliyor#

Türkçe içeriklerin çoğu bu ekranı gösterip geçer. Oysa hangi sütunun dolduğunu bilmeden yapılan her müdahale rastgeledir. Sütunlar şunlardır:

Bu tablodaki iki satır neredeyse hiçbir Türkçe kaynakta doğru anlatılmaz, ayrıca en çok karıştırılanlar da onlardır.

Giriş İşlemleri (Entry Processes) nedir#

Giriş işlemi, hesabınızda o an aynı anda çalışmakta olan PHP isteği sayısıdır — günlük toplam ziyaretçi değil, o saniyedeki eşzamanlı istek. Paylaşımlı paketlerde bu değer genellikle tek haneli veya 20-30 civarındadır.

Buradaki kritik nokta şu: bu sayaç istek süresiyle doğru orantılı çalışır. Sayfanız 0,2 saniyede üretiliyorsa 20 eşzamanlı istek limitine dayanmanız için saniyede yüz kişinin sayfa açması gerekir. Ama sayfanız 4 saniyede üretiliyorsa aynı limite saniyede 5 istekle dayanırsınız. Yani EP limiti aslında bir trafik sınırı değil, bir yavaşlık cezasıdır. Bu yüzden EP hatası alanların büyük çoğunluğunda çözüm "daha büyük paket" değil, "sayfa üretim süresini düşürmek"tir.

Faults sütunu nedir#

Faults, limitin kaç kez dolduğunu sayar; bir kaynağın adı değildir. CPU faults: 148 satırı "148 kez CPU limitine dayandınız" demektir. Faults sıfırdan büyükse ve grafikte karşılığı yoksa panik yapmayın: tek bir yedekleme anında 3-5 fault üretmek normaldir. Yüzlerce fault ve saatlere yayılmış bir dağılım ise gerçek bir sorundur.

Hangi Kaynak Doluyor: Doğru Teşhis Sırası#

Kaynak kullanımı sorunlarında yapılan en yaygın hata, ilk gördüğü kırmızı çizgiye göre hareket etmektir. Sıra şu olmalı:

1. I/O ve IOPS mi dolu? Genelde yedekleme, büyük log dosyası veya arama motoru indeksleme işidir. Sitenin kodu değil, disk trafiği suçludur.
2. Sanal bellek mi dolu? Tek bir ağır script (rapor üretimi, toplu ürün içe aktarma, resim işleme) sorumludur. Grafikte sivri ve kısa tepeler görürsünüz.
3. EP mi dolu? Site yavaştır; asıl sorun süre, trafiğin kendisi değil.
4. CPU mu dolu? En geniş kategori. Bot trafiği, ağır sorgu, önbelleksiz WordPress ya da kötü amaçlı script olabilir.

Bu sıralamayı takip ederseniz araştıracağınız dosya sayısı ciddi biçimde azalır.

Limiti Kim Dolduruyor: Ziyaretçi mi, Bot mu#

En hızlı cevabı ham erişim kayıtları verir. cPanel'de Metrikler → Ham Erişim (Raw Access) bölümünden sıkıştırılmış günlüğü indirebilirsiniz. Ancak SSH erişiminiz varsa iş çok daha hızlıdır:

cd ~/access-logs
ls -lh

Alan adınıza ait dosyayı bulduktan sonra en çok istek yapan IP adreslerini çıkarın:

awk '{print $1}' example.com | sort | uniq -c | sort -rn | head -20

Çıktı şuna benzer:

  48210 66.249.66.14
  31877 5.188.62.140
  12044 157.55.39.201
    980 88.230.14.7

Bu tabloyu okumanın yolu şudur: 66.249.* Google'ın tarayıcısıdır, 157.55.* Bing'dir. İlk iki satırdaki gibi on binlerce istek yapan ve bilinen bir arama motoruna ait olmayan adresler asıl şüphelilerdir. Hangi tarayıcı kimliğiyle geldiklerine bakın:

grep "5.188.62.140" example.com | awk -F'"' '{print $6}' | sort | uniq -c | sort -rn | head

Bir de en çok istenen adresleri çıkarın; bu, botun neyin peşinde olduğunu söyler:

awk '{print $7}' example.com | sort | uniq -c | sort -rn | head -20

Bu listenin başında /wp-login.php ya da /xmlrpc.php görürseniz, bu bir ziyaretçi trafiği değil kaba kuvvet denemesidir ve CPU'yu bu tüketiyordur. Bu durumda önce WordPress giriş limitleme ve XML-RPC kapatma adımlarını uygulamak, paket yükseltmekten çok daha etkilidir. Listenin başında /?s= ile başlayan yüzlerce farklı adres varsa, arama sayfanız bot tarafından taranıyor demektir; arama sonuçlarını robots.txt ile taramaya kapatmak tek başına CPU grafiğini yarıya indirebilir.

Şüpheli IP'yi engellemek için cPanel'de Güvenlik → IP Engelleyici ekranını kullanabilirsiniz. Aynı ağ bloğundan geliyorsa tek tek IP yerine 5.188.62.0/24 biçiminde blok girmek daha kalıcıdır.

Hangi Eklenti veya Script Yoruyor#

Bot değil de kendi kodunuz yoruyorsa iki yöntem işe yarar.

Birincisi: o anki süreçlere bakmak. SSH erişiminiz varsa hesabınızın canlı süreçlerini görebilirsiniz:

ps -u $(whoami) -o pid,%cpu,%mem,etime,cmd --sort=-%cpu | head -15

Uzun süredir çalışan (etime sütunu dakikalarca) bir php süreci görüyorsanız, tam komut satırında hangi dosyayı çalıştırdığı yazar. Genelde şu üç şeyden biri çıkar: bir yedekleme eklentisi, bir içe/dışa aktarma işlemi ya da bir arama/filtre isteği.

İkincisi: yavaş sorguyu bulmak. WordPress kullanıyorsanız wp-config.php dosyasına geçici olarak şunu ekleyin:

define( 'SAVEQUERIES', true );

Ardından bir tema dosyasının altına şu bloğu koyup yalnızca kendinizin göreceği biçimde çıktı alın:

if ( current_user_can( 'administrator' ) && defined( 'SAVEQUERIES' ) && SAVEQUERIES ) {
    global $wpdb;
    $slow = array_filter( $wpdb->queries, function( $q ) { return $q[1] > 0.05; } );
    error_log( 'Yavas sorgu sayisi: ' . count( $slow ) );
    foreach ( $slow as $q ) { error_log( round( $q[1], 3 ) . 's -> ' . substr( $q[0], 0, 200 ) ); }
}

Çıktı error_log üzerinden yazıldığı için ziyaretçi hiçbir şey görmez; kayıtları cPanel'in Hata Kayıtları ekranından veya ~/logs altından okursunuz. Testi bitirdiğinizde her iki eklemeyi de kaldırın — açık bırakılan SAVEQUERIES başlı başına bellek tüketir.

Eklenti bazında suçluyu bulmanın kaba ama en kesin yolu ise sırayla devre dışı bırakmaktır. Bu işi canlı sitede yapmak yerine bir staging ortamı üzerinde yapmak, hem ziyaretçiyi etkilemez hem de geri dönüşü kolaydır. Deneyimle söyleyeyim: kaynak tüketiminin arkasından en sık çıkan üçlü, sürekli çalışan bir "site istatistikleri" eklentisi, veritabanına her istekte yazan bir "ilgili yazılar" eklentisi ve ayarları yanlış yapılmış bir yedekleme eklentisidir.

Cron Görevleri ve WP-Cron Tuzağı#

Grafikte her gün aynı saatte tekrar eden bir tepe varsa şüpheli bir zamanlanmış görevdir. cPanel'de Gelişmiş → Cron İşleri ekranından listeyi kontrol edin. Aşağıdaki gibi bir satır klasik hatadır:

* * * * * /usr/local/bin/php /home/kullanici/public_html/wp-cron.php

Bu satır görevi her dakika çalıştırır. Çoğu site için 15 dakika fazlasıyla yeterlidir:

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

Sondaki >/dev/null 2>&1 kısmı önemlidir: onu yazmazsanız her çalıştırmada size e-posta gönderilir ve bu hem posta kotanızı hem sunucuyu yorar.

WordPress'in kendi sanal cron mekanizması ise ayrı bir tuzaktır. Varsayılan durumda wp-cron.php, siteye gelen her ziyaretçi tarafından tetiklenir. Trafiği yüksek bir sitede bu, sayfa açılışlarına gizli bir yük bindirir. Doğru yapılandırma, sanal cron'u kapatıp gerçek cron'a bağlamaktır:

define( 'DISABLE_WP_CRON', true );

Bu satırı wp-config.php içine ekledikten sonra yukarıdaki cron satırını mutlaka tanımlayın; aksi halde zamanlanmış yayınlar ve yedeklemeler çalışmaz.

Kaynak Tüketimini Gerçekten Düşüren Adımlar#

Teşhisi koyduktan sonra uygulanacak müdahaleler etkisine göre sıralanırsa şöyle bir liste çıkar:

1. Tam sayfa önbelleği açın. CPU probleminin en büyük tek çözümü budur. Sunucuda LiteSpeed varsa LiteSpeed Cache, yoksa dosya tabanlı bir önbellek eklentisi kurun. Önbellekli bir sayfa PHP'yi hiç çalıştırmaz; CPU ve EP grafiği aynı anda düşer.
2. PHP sürümünü güncelleyin. cPanel'de Yazılım → PHP Sürümünü Seç ekranından desteklenen güncel sürüme geçmek, aynı kodu belirgin biçimde daha az CPU ile çalıştırır. Geçmeden önce sitem PHP 8 ile çalışır mı kontrol listesini gözden geçirin.
3. OPcache'in açık olduğunu doğrulayın. PHP kodunun her istekte yeniden derlenmesini engeller; kapalıysa CPU'nun önemli bir kısmı boşa gider.
4. Veritabanını temizleyin. Kayıt revizyonları, süresi dolmuş geçici veriler (transient) ve spam yorumlar tabloları şişirir, her sorguyu yavaşlatır.
5. Görselleri küçültün. I/O ve bant genişliği tüketiminin çoğu ölçeklenmemiş fotoğraflardan gelir. WebP formatına dönüştürme tek başına disk trafiğini ciddi biçimde azaltır.
6. Gereksiz eklentileri kaldırın, devre dışı bırakmakla yetinmeyin — bazıları pasifken bile cron kaydı bırakır.
7. Log ve yedek dosyalarını taşıyın. public_html altında biriken eski yedek arşivleri hem disk hem de tarama yükü üretir. Disk tarafını ayrıca cPanel disk kullanımı yazısındaki yöntemle inceleyin.

Limit Gerçekten Yetmiyorsa Ne Yapmalı#

Yukarıdaki adımların hepsini uyguladınız, önbellek çalışıyor, bot engellendi, sorgular temiz — ama grafik hâlâ tavana vuruyorsa artık optimizasyon problemi değil, kapasite problemi vardır. Bunun birkaç net işareti şudur:

• Kırmızı alanlar günün belirli saatlerinde değil, gün boyunca dağılmışsa.
• Trafiğin arttığı ay ile limitin dolmaya başladığı ay örtüşüyorsa.
• Site önbellekliyken bile CPU tabanda yüksek seyrediyorsa (dinamik sepet/üyelik trafiği).
• E-ticaret sitesinde ödeme adımı yoğun saatte hata veriyorsa.

Bu tabloda iki yol vardır: aynı hosting ailesinde daha yüksek limitli bir pakete geçmek ya da kaynağın tamamen size ait olduğu bir sanal sunucuya taşınmak. Karar için hosting paketi yükseltme zamanı ve paylaşımlı hosting kaynak limitleri yazılarındaki eşikler yol gösterir. Kaba bir kural: sorunun kaynağı eşzamanlılık ise (EP ve CPU birlikte doluyorsa) paket yükseltmek işe yarar; sorunun kaynağı tek bir ağır işlem ise (bellek tepeleri) önce o işlemi düzeltmek gerekir, çünkü daha büyük paket aynı hatayı biraz daha geç verir.

Sıkça Sorulan Sorular#

cPanel kaynak kullanımı grafiği kırmızı ama site açılıyor ne yapmalıyım#

Grafikteki kırmızı alan, o dakikada limite dayanıldığını gösterir; sitenin tamamen kapandığını göstermez. Kısa süreli dayanmalarda ziyaretçi yalnızca yavaşlama hisseder. Yine de bu bir erken uyarıdır: trafiğin biraz artması durumunda aynı dayanmalar 508 hatasına dönüşür. Grafiği 7 günlük aralığa alıp kırmızı alanların sıklaşıp sıklaşmadığına bakın ve önce önbellek ile PHP sürümü gibi düşük riskli iyileştirmeleri uygulayın.

Entry process limiti ile ziyaretçi sayısı arasında nasıl bir ilişki var#

Doğrudan bir ilişki yoktur; giriş işlemi limiti eşzamanlı istek sayısını ölçer, günlük ziyaretçi sayısını değil. Sayfa üretim süresi kısaldıkça aynı ziyaretçi sayısı çok daha az eşzamanlı istek üretir. Bu nedenle 508 hatası alan bir sitede ilk yapılacak şey önbellek açmak ve yavaş sorguları temizlemektir. Sayfa süresini yarıya indirmek, pratikte limit kapasitesini ikiye katlamakla aynı etkiyi yapar.

Faults sayısının kaçtan sonrası tehlikeli sayılır#

Kesin bir eşik yoktur, ama günde birkaç fault normal, üç haneli fault sayıları müdahale gerektiren bir durumdur. Önemli olan sayının kendisi kadar dağılımıdır: tek bir saatte toplanmış 40 fault genelde bir yedekleme ya da içe aktarma işidir ve zararsızdır. Aynı 40 fault güne yayılmışsa site sürekli sınırda çalışıyor demektir. Bu ayrımı görmek için grafiği mutlaka saatlik kırılımda inceleyin.

Kaynak limitini aşan botu nasıl engellerim#

Önce ham erişim kayıtlarından IP ve tarayıcı kimliğini doğrulayın, ardından cPanel'in IP Engelleyici ekranından tekil adresi veya ağ bloğunu engelleyin. Arama motoru tarayıcılarını engellemeyin; onların yükünü robots.txt içindeki tarama kuralları ve gereksiz sayfaların taramaya kapatılmasıyla azaltın. Kaba kuvvet denemeleri söz konusuysa giriş sayfasını sınırlamak ve XML-RPC'yi kapatmak tek başına belirgin fark yaratır. Engelleme sonrası grafiği 24 saat izleyip etkiyi ölçün.

wp-cron yükü nasıl azaltılır#

WordPress'in sanal cron mekanizmasını wp-config.php içinde DISABLE_WP_CRON sabitiyle kapatıp yerine cPanel üzerinden gerçek bir cron görevi tanımlayın. Görevi her dakika değil, 15 dakikada bir çalışacak biçimde ayarlayın ve çıktısını /dev/null adresine yönlendirerek gereksiz e-posta üretimini engelleyin. Bu değişiklikten sonra zamanlanmış yayınların ve otomatik yedeklerin çalıştığını mutlaka doğrulayın, çünkü cron satırı hatalıysa bu işler sessizce durur.

Sanal bellek limiti dolunca site neden beyaz ekran veriyor#

Bellek limiti dolduğunda sunucu, limiti aşan PHP sürecini sonlandırır ve tarayıcıya hiçbir içerik ulaşmaz; sonuç boş bir sayfadır. Aynı olay bazen 500 hatası olarak da görünür. Nedenini bulmak için hata kayıtlarında Allowed memory size ... exhausted satırını arayın; satırın sonunda hafızayı tüketen dosyanın yolu yazar. Genelde sorumlu, çok büyük bir dosyayı belleğe alan bir içe aktarma veya görsel işleme kodudur.

Paket yükseltmek kaynak sorununu kesin çözer mi#

Hayır, yalnızca sorunun kaynağı gerçek kapasite yetersizliğiyse çözer. Kod kaynaklı bir sorunda daha yüksek limit sadece hatanın ortaya çıkma anını erteler; bir süre sonra aynı grafikle karşılaşırsınız. Bu yüzden önce önbellek, PHP sürümü, bot filtreleme ve yavaş sorgu temizliği yapılmalı, ardından grafik yeniden ölçülmelidir. Bu adımlardan sonra hâlâ sürekli tavan yapan bir grafik varsa yükseltme doğru karardır.

Kapanış#

cPanel kaynak kullanımı ekranı bir suçlama tablosu değil, bir teşhis aracıdır. Doğru okuma sırası her zaman aynıdır: önce hangi sütunun dolduğunu belirleyin, sonra bu sütunun kim tarafından doldurulduğunu ham erişim kayıtları ve süreç listesiyle kanıtlayın, en son müdahale edin. Giriş işlemi limitinin aslında bir yavaşlık cezası olduğunu, Faults sütununun bir kaynak değil bir sayaç olduğunu ve her gün aynı saatte tekrarlayan tepelerin neredeyse her zaman bir cron görevine ait olduğunu aklınızda tutarsanız, bu ekranın önünde geçirdiğiniz süre dakikalarla ölçülür.

Bu iş akışını kendiniz yürütmek istemiyorsanız veya ölçümler paketinizin gerçekten dolduğunu gösteriyorsa, bir üst kapasiteye geçmek en temiz çözümdür. Kaynakların komşu hesaplarla paylaşılmadığı bir yapı için VDS sunucu paketlerini inceleyebilir, WordPress tarafında önbellek ve PHP ayarları hazır gelen bir kurulum için WordPress hosting seçeneğine bakabilirsiniz. Yükün büyük kısmı ürün ve sepet trafiğinden geliyorsa e-ticaret hosting paketleri bu profile göre yapılandırılmıştır; sunucuyu kendiniz yönetmek istemiyorsanız sunucu yönetimi hizmeti izleme ve optimizasyon işini üstlenir.