cPanel Kaynak Grafikleri: Birimler ve Fault Sayaçları

cPanel’deki kaynak grafiğini okumak için önce üç şeyi belirleyin: hangi büyüklük ölçülüyor, limit hangi birimle gösteriliyor ve değer hangi zaman aralığını özetliyor? CPU yüzdesi, bellek miktarı, disk hızı ve LVE giriş sayısı aynı ölçeğe sahip değildir. Bir fault kaydı da otomatik olarak bir başarısız HTTP isteği sayısı değildir.

Bu referans CloudLinux LVE kullanılan hesaplarda SPEED, PMEM, IO/IOPS, EP ve NPROC alanlarının anlamını açıklar. Ortalama ile maksimumu, kullanım ile limiti ve fault ile kullanıcı hatasını ayırır. Aşağıdaki sayısal okuma örnekleri varsayımsaldır; gerçek DCHost ekranı, paket limiti veya müşteri ölçümü değildir.

Grafiklerden bir teşhis kaydı çıkarın: zaman aralığı, birim, ortalama, varsa maksimum, limit, fault türü ve ilgili kullanıcı sonucu. Bir hatayı adım adım gidermek için Resource Limit Reached teşhis ve çözüm rehberine geçebilirsiniz.

Ölçümün Kapsamı: cPanel Arayüzü ve CloudLinux LVE

Paylaşımlı sunucuda hesaplar ortak kaynakları kullanabilir. CloudLinux LVE hesap düzeyinde kaynak kontrolü uygular; cPanel ise ilgili entegrasyonun gösterildiği kontrol panelidir. cPanel’in bulunması tek başına CloudLinux kurulu olduğunu veya her hesabın aynı sayaçlara sahip olduğunu göstermez.

Bir grafiği yorumlamadan önce kapsamını kaydedin:

• Hangi hesap ve siteler aynı LVE altında?
• CloudLinux/LVE sürümü, web sunucusu ve PHP handler hangisi?
• Gösterilen değer hesap kullanımı mı, veri tabanı ölçümü mü, tüm sunucu mu?
• Birim, gösterim ölçeği, zaman aralığı ve gerçek paket limiti nedir?

Paylaşımlı hosting veya VPS karşılaştırırken kaynak sınırlarını ve paylaşım koşullarını sağlayıcıdan doğrulayın. Limitler bir hesabın diğerleri üzerindeki etkisini azaltmaya yardımcı olur; kesintisiz hizmet, ayrılmış fiziksel çekirdek veya tüm saldırılara karşı koruma garantisi değildir.

CPU, PMEM, IO/IOPS ve EP Alanlarının Birimleri

CloudLinux Resource Usage eklentisi etkinse ilgili kullanım/limit alanlarını inceleyin. Menü adı, gösterilen kaynaklar ve geçmiş süreleri entegrasyona bağlıdır. Her grafiğe aynı “%100” anlamını yüklemeyin.

CPU / SPEED: Tek Çekirdek Ölçeği ve Normalize Yüzde

Modern CloudLinux SPEED, tek çekirdeğin kapasitesine göre ifade edilir. %100 bir çekirdek, %150 bir buçuk çekirdek karşılığı işlemci kapasitesi sınırıdır. Bu, fiziksel çekirdeğin yalnız size ayrıldığı anlamına gelmez.

İki farklı yüzde gösterimini ayırın:

• Ham SPEED ölçeğinde %200 limit ve %100 kullanım, bu limite göre %50 kullanımdır.
• Paket limitine normalize edilmiş grafikte aynı kullanım %50 gösterilebilir; %100 ise paket limitinin tamamını ifade eder.
• Ölçek belirtilmeden iki ekrandaki “%100” değerini karşılaştırmayın.

CPU zamanının hangi işten geldiğini grafik tek başına söylemez. İlgili iş yüklerini ayrı kayıtlarla araştırın:

• Dinamik sayfa, AJAX veya API yolundaki PHP işi
• Önbelleğe uygun içerikte doğrulanmış HIT/MISS farkı
• Cron, dönüştürme, sıkıştırma veya içe aktarma işi
• Veri tabanı CPU ölçümü ve MySQL Governor/LVE atıf koşulları

CPU sınırında süreçler yavaşlatılır; doğrudan “CPU doldu, 508 oluşur” kuralı yoktur. Apache’de daha uzun süren istekler ayrı EP baskısına katkıda bulunabilir. Durum kodunu ve fault türünü aynı zaman penceresinde eşleştirin. CPU, IO ve MySQL darboğazı teşhisi rehberi bu teşhisi uygulama kayıtlarıyla tamamlar.

Physical Memory (RAM) Limiti

PMEM, LVE içindeki süreçlerin fiziksel belleğini ve paylaşılan belleği kapsar; disk page cache’in istatistiğe dahil edilmesi sürüm ve ayara bağlıdır. Aynı sunucudaki tüm veri tabanı belleği otomatik olarak bu hesaba ait değildir. PMEM değerini bir bellek birimiyle okuyun; varsayılan olarak yüzde değildir.

Bellek grafiğine açıklama ararken ayar ile gerçek tüketimi ayırın:

• memory_limit scriptin bellek ayırma sınırıdır; worker başına önceden ayrılan RAM değildir.
• Eşzamanlı işler, paylaşılan bellek ve diğer hesap süreçleri toplam fiziksel belleği etkiler.
• XML/CSV içe aktarma veya raporlama gibi işlerin gerçek tepe tüketimini ölçün.
• Eklenti adı ya da sayısı tek başına bellek miktarını göstermez.

PMEM baskısında CloudLinux önce geri kazanılabilir disk cache’i boşaltabilir. Yetmezse LVE içindeki bazı süreçleri sonlandırır ve fPMEM artar; 500/503 görülebilir. Yalnız yüksek grafik süreç sonlandırıldığını kanıtlamaz. PHP’nin kendi bellek hatası ayrı bir kayıttır. PHP bellek ve süre ayarları rehberi bu ayar ayrımını açıklar.

IO ve IOPS Limitleri

IO disk okuma ve yazmasının toplam veri hızını sınırlar; belgede KB/s, arayüzde başka birimlerle gösterilebilir. IOPS saniyedeki okuma/yazma işlem sayısıdır. MB/s ile işlem/s, depolama kapasitesi ve ağ trafiği ayrı büyüklüklerdir. Kaynak birimi doğrulanmadan KB, KiB, MB veya MiB etiketlerini birbirinin yerine kullanmayın.

Disk hızı grafiğini değerlendirirken ölçüm sınırını kaydedin:

• CloudLinux disk IO sayımı disk-cache erişimlerini içermez.
• Yedek, log, yükleme ve dönüştürmenin gerçek disk erişimi ile cache isabeti ayrılmalıdır.
• MySQL Governor veri tabanı ölçümü ile LVE IO çizgisi aynı veri kümesi olmayabilir; etkin modu doğrulayın.
• Cache yenilemesi kendi okuma/yazma yükünü oluşturabilir; daha az dosya her zaman daha düşük IO değildir.

IO sınırı süreçleri yavaşlatır; IOPS sınırında işlemler ilgili saniyenin sonuna kadar bekleyebilir. Bunlar disklerin dolu olduğunu veya fiziksel NVMe cihazının azami hıza ulaştığını göstermez. Disk, IOPS ve inode planlama rehberi kapasite, işlem hızı ve inode ayrımını tamamlar.

Entry Processes (EP) Limiti

EP, LVE’ye giriş sayısıdır; LVE içinde oluşturulan her alt süreç sayılmaz. Apache mod_hostinglimits altında dinamik CGI/PHP isteği girişleri tipik örnektir; entegre SSH/cron girişleri de sayılabilir. EP ziyaretçi sayısı, bütün bağlantılar veya PHP worker sayısı değildir.

Apache giriş modelini açıklayan ayrı, varsayımsal örnek:

• Hesabın EP limitini 20 ve o anda 20 dolu giriş olarak varsayın.
• Bu girişler henüz çıkmadan yeni bir dinamik istek LVE’ye girmeyi deniyor.
• Bu değerler gerçek plan önerisi değildir; ziyaretçilerin toplam sayısı bu örneğin girdisi değildir.

Apache mod_hostinglimits yeni girişi yapamazsa 508 döndürebilir; otomatik kuyruk varsayılmaz. LiteSpeed’de sayım farklıdır: workgroup düzenindeki lsphp master alt süreçler oluşturabilir ve her çocuk/istek için EP artmaz. Aynı yükte Apache ile LiteSpeed EP sayıları birebir karşılaştırılamaz.

• Önbelleksiz giriş sayfasındaki işin süresi ve gerçek handler
• Kişisel sepet/ödeme yanıtlarının ortak cache dışında kalması
• Bot ya da API isteklerinin oranı, süresi ve meşru kullanım ayrımı

Bu bilgiler EP grafiğine olası açıklamalar sağlar; tek başına sınır ihlali kanıtı değildir. cPanel kaynak limitleri rehberi ilişkili kavramlar için ek bir kaynaktır.

NPROC ve inode: Giriş Sayısından Farklı Sınırlar

Bu iki alanı EP veya disk hızıyla eşitlemeyin:

• NPROC: LVE içindeki süreç ve thread toplamını sınırlar. Sınırda yeni süreç oluşturulamaz; 500/503 görülebilir. EP ve PHP worker/pool ayarları farklıdır.
• inode: Dosya sistemi nesne sayımıyla ilgilidir; dosya ve dizinleri kapsar. Bayt cinsinden disk kapasitesi veya saniyedeki IO değildir; sağlayıcının kota kapsamını doğrulayın.

Inode temizliği rehberi ilgili temizlik konusunu ele alır. Bir inode uyarısı CPU, PMEM veya EP faultu olarak yorumlanmamalıdır; bu kaynakların hepsi aynı tür zaman serisiyle sunulmayabilir.

Ortalama, Maksimum, Limit ve Fault Alanlarını Okuma

Bir çizgi tek başına yeterli değildir. Aynı zaman penceresi için ölçüm tanımı, kullanım, limit ve mevcut fault alanlarını bir araya getirin.

1. cPanel Resource Usage Ekranını Kontrol Edin

Resource Usage eklentisi etkinse ayrıntılı kullanım ekranını açın; yoksa eşdeğer kaydı sağlayıcıdan isteyin. Sunulan arayüzde şunları kontrol edin:

• Zaman aralığı, saat dilimi ve örnekleme/toplama birimi
• Kullanım ortalaması, gerçek limit ve varsa maksimum
• Fault türü ve seçilen aralığa ait sayı
• Varsa olay sonrası snapshot ve toplandığı an

Renge tek başına anlam vermeyin; ekranın lejandını okuyun. Ortalama çizgi kısa yükselmeleri gizleyebilir. “Veri yok”, “fault alanı sunulmuyor” ve “fault 0” farklı durumlardır. Kısa sıçrama da kritik bir ödeme veya kayıt işlemini etkileyebilir.

2. Fault Sayısı ile HTTP Hatasını Ayırın

Fault alanı ilgili kaynak sınırı ihlalini bildirir. Aşağıdakileri birbirine dönüştürmeyin:

• Bir PMEM faultu, EP giriş reddiyle aynı olay değildir.
• Fault sayısı tekil ziyaretçi veya başarısız HTTP isteği sayısı değildir.
• PHP bellek hatası, proxy hatası ve kaynak faultu ayrı kayıtlar olabilir.
• Bir snapshotta görünmeyen süreç olay anında hiç çalışmadı sonucu çıkarılamaz; toplama gecikebilir.

Saat dilimi eşleşen erişim ve uygulama kayıtlarıyla kullanıcı etkisini inceleyin. PHP hata kaydı rehberi olayın kaydını geliştirmeye yardımcı olur; gizli bilgiler ve kişisel veriler paylaşılacak örneklerden çıkarılmalıdır.

3. Aynı Aralığı ve Aynı İstatistiği Karşılaştırın

Bir dakikalık maksimum ile bir saatlik ortalama aynı soruya yanıt vermez. İki dönemi karşılaştırırken şunları eşleştirin:

• Aynı kaynak birimi, CPU ölçeği ve limit
• Aynı toplama aralığı, saat dilimi ve iş yükü kapsamı
• Ortalama ile ortalama; mevcut maksimum ile aynı tür maksimum
• Tamamlanan işlemler, gecikme ve hata kayıtları

Uptime ve uygulama izleme verileri kaynak grafiğinin göstermediği kullanıcı etkisini ekleyebilir. VPS kaynak kullanımı izleme rehberi sunucu düzeyinde başka ölçüler sunar; hesap LVE grafiğini tüm sunucu metriğiyle özdeşleştirmeyin.

Varsayımsal Okuma Tablosu: Beş Dakikalık Tek Aralık

Aşağıdaki tablo gerçek ekran veya ölçüm değildir. Aynı beş dakikalık aralıkta CPU’nun ham SPEED ölçeğinde, belleğin MiB ve disk hızının MB/s gösterildiğini varsayar. Maksimum alanı varsa ayrıca alınmıştır; her arayüz bu alanı sunmaz. “Sunulmadı” sıfır anlamına gelmez.

CPU ortalaması limitin %30’u, maksimumu %100’üdür: 60÷200 ve 200÷200. EP ortalaması 5 olsa da maksimum 20’ye ulaşmıştır; bu, 20 ziyaretçi olduğu anlamına gelmez. İki PMEM ve üç EP faultunu toplayıp “beş başarısız müşteri isteği” demeyin. Önce olay zamanlarını, gerçek handlerı ve kullanıcı sonuçlarını eşleştirin. Bu tablodan belirli bir eklenti, yedek veya saldırı sonucu çıkarılamaz.

Grafiğe Açıklama Eklerken Hangi Kaydı Aramalısınız?

Aşağıdaki başlıklar grafik üzerine not düşmek için kanıt alanlarıdır. Bunlar bir ayar reçetesi veya otomatik ürün seçimi değildir. Dedicated sunucu ve VPS de fiziksel kapasiteye ve yapılandırılmış sınırlara sahiptir.

1. Uygulama, Sorgu ve Cache Kayıtları

Aynı iş yükü için istek yolu, çalışma süresi, CPU zamanı, bellek ve cache durumunu kaydedin. Veri tabanı sorgusu beklemek ile PHP CPU tüketmek aynı şey değildir.

• Bir eklenti değiştiyse önce/sonra aynı gerekli işin çalıştığını doğrulayın; eklenti sayısı kaynak metriği değildir.
• wp_options ve autoload verisini uygulama davranışıyla birlikte inceleyin; körlemesine silmeyin. WordPress veritabanı optimizasyon rehberi ilgili uygulama adımlarını açıklar.
• Sayfa cache’inde yalnız aynı herkese açık yanıtları ortak kullanın; sepet, ödeme, hesap ve özel API yanıtlarını ayırıp invalidasyonu test edin.
• LiteSpeed sayfa cache’i etkin uyumlu sunucu/LSCache veya uygun QUIC.cloud hizmeti gerektirir. Eklenti kurulumu tek başına HIT kanıtı değildir.
• Sorgu değişikliğini plan, süre ve sonuç doğruluğuyla doğrulayın; garantili CPU/IO düşüşü varsaymayın.

Cache etkisini karşılaştırılabilir isteklerle değerlendirin. Grafik notuna gerçek HIT/MISS kapsamını, tamamlanan işi ve yanıt doğruluğunu yazın; belirli bir kat performans kazanımını varsaymayın.

2. PHP Ayarı ile Ölçülen Kullanımı Ayırın

Yapılandırma değerleri, kaynak grafiğinin doğrudan ölçümleri değildir:

• memory_limit artırmak hesabın PMEM sınırını yükseltmez; script sınırı işletim sistemi RSS değeriyle aynı değildir.
• max_execution_time değerini gerçek duvar saati, dış servis bekleme süresi veya CPU tüketimi olarak okumayın; süre sınırlarının davranışı ortam ve PHP yürütme yoluna bağlıdır.
• Güvenlik desteği süren, uygulamayla uyumlu PHP dalını seçin; yeni sürümün kaynak etkisini aynı işte ölçün.

Ayarın hangi domain ve handler üzerinde etkin olduğunu doğrulayın. PHP ayarları rehberi ve cPanel’de çoklu PHP sürümü yönetimi rehberi ilgili yapılandırma ayrıntılarını ele alır.

3. Zamanlanmış Görevleri Grafiğe İşaretleyin

Cron, yedek, rapor ve içe aktarma için yalnız planlanan saati değil gerçek başlangıç, bitiş ve tamamlanma durumunu yazın. Aynı saatlerdeki tekrarlama bir araştırma ipucudur; nedenin kanıtı değildir.

• Aynı anda çalışan görevler ve tekrar denemeler
• Görevin işlediği veri miktarı ve bitirme süresi
• Gerekli son teslim zamanı ve yedek geri dönüş kapsamı

Bir zamanlama değişikliğinin yorumunu şu kontrollerle tamamlayın:

• Çakışma azaldığında gerekli işler hâlâ zamanında tamamlanıyor mu?
• Cron/CLI de hesap kaynaklarını kullanır; entegrasyona göre EP girişine dahil olabilir.
• wp-cron.php için alternatif sistem tetikleyicisini doğrulamadan sayfa tetiklemeyi kapatmayın. Gerçek cron kurulum rehberi ilgili uygulama sırasını açıklar.

Cron ile yedek, rapor ve bakım rehberi uygulama adımlarını açıklar. Harici yedek hedefi yerel okuma/sıkıştırma maliyetini kendiliğinden kaldırmaz; yük düşüşünü tamamlanma ve geri yükleme kontrolüyle birlikte kaydedin.

4. Bot ve API Trafiğini Ayrı Sayın

Tarayıcı analitiğinde görülmeyen bot, API veya arka plan işi kaynak tüketebilir. Aynı IP birden fazla kullanıcıyı temsil edebilir ve User-Agent taklit edilebilir; düşük ziyaretçi sayısı veya gece saati tek başına saldırı kanıtı değildir.

• Login/XML-RPC yollarının gerçek istek oranı, süresi ve sonucu
• Form korumasının meşru gönderimlere etkisi
• WAF veya rate-limit sonrasında origin’e ulaşan iş; gerekli callback ve API istemcilerinin sonucu

DDoS koruma stratejileri ve iletişim formu spam’ini azaltma rehberimiz uygulama seçeneklerini açıklar. PHP içinde çalışan filtre de kaynak kullanabilir; edge veya sunucu katmanı ile aynı işlem noktasında değildir.

5. CDN ve Tarayıcı Cache Kapsamını Ayırın

CDN veya tarayıcı cache’i origin’e gelen bazı istekleri azaltabilir. Ancak kaç PHP işi, disk erişimi veya baytın ortadan kalktığı cache konumuna ve isabete bağlıdır; ağ tasarrufu otomatik olarak aynı oranda LVE IO/CPU düşüşü değildir.

• Cache-Control süresi ve içerik güncelleme/invalidasyon gereksinimi
• Gerçekte cache’den gelen kaynaklar ve origin fetch sayısı
• HTTP/2 veya HTTP/3 kullanımı: tek başına daha düşük hesap CPU/IO kanıtı değildir

Origin kaynaklarını CDN’nin kullanıcıya gönderdiği baytlardan ayrı değerlendirin. Tarayıcı ve CDN önbellekleme rehberi ve CDN karar rehberi bu kapsamı planlamaya yardımcı olur.

Plan Karşılaştırmasına Hangi Ölçüler Taşınmalı?

Grafik, plan seçimi için bir girdidir. Gerçek sınırın gerekli kullanıcı işlemini etkilediğini ve alternatif planın hangi kapasite veya yetkiyi değiştirdiğini belgeleyin.

1. Aynı Platformdaki Tahsisi Karşılaştırın

İki planı karşılaştırırken yalnız grafik yüksekliğini veya site sayısını kullanmayın:

• CPU ölçeği, limit ve paylaşım koşulları
• PMEM, IO/IOPS, EP/NPROC ve handler/worker sınırları
• Gerekli işin gecikmesi, hata oranı ve yoğun dönem kapsamı

Daha yüksek paket ancak ilgili kapasiteyi veya gerekli kontrolü sağlıyorsa yardımcı olabilir. Bir–üç site gibi evrensel bir sayı ya da kısa pik süresi, tek başına yeterlilik kanıtı değildir.

2. Dedicated Sunucu veya VPS Kapsamında Ek Kayıtlar

Ayrı kaynak veya işletim yetkisi değerlendirirken şu gereksinimleri açık yazın:

• Gerekli CPU, bellek, disk ve ağ kapasitesi; paylaşım veya garanti koşulları
• Veri tabanı, queue ve arka plan worker yönetimi
• Yedek, izleme, güncelleme ve taşıma sorumluluğu
• Uyum yükümlülüğünün gerçek teknik/organizasyonel gereği; sunucu türü tek başına PCI DSS veya KVKK/GDPR uyumu oluşturmaz

VPS, dedicated veya colocation seçenekleri için sunulan tahsis ve işletim kapsamını doğrulayın. “Dedicated sunucu mu VPS mi?” rehberimiz karşılaştırmaya yardımcı olur. Sağlayıcıdan beklenen mimari ve taşıma desteğinin kapsamını ayrıca netleştirin.

Sağlayıcıdan İstenecek Grafik Açıklaması

Kaynak tablosunda belirsiz kalan alanlar için şu soruları kayda ekleyin:

• CPU normalize mi, ham SPEED mi; her satırın birimi nedir?
• Ortalama/maksimum nasıl toplanıyor, zaman dilimi ve saklama süresi nedir?
• Fault alanı hangi kaynağı ve hangi aralığı gösteriyor?
• PMEM cache muhasebesi, MySQL Governor modu ve Apache/LiteSpeed EP sayımı nasıl?
• Eksik veri ve snapshot gecikmesi nasıl anlaşılır?

Bu yanıtlar olmadan panel rengini gerçek performans garantisine çevirmeyin. DCHost’a başvururken hesap, olay zamanı ve mevcut kayıtları iletin; analiz hizmetinin kapsamını ayrıca doğrulayın.

Okuma Sonucu: Birimleri ve Kanıt Sınırını Kaydedin

CPU işlemci kullanımını, IO/IOPS farklı disk hızlarını, PMEM fiziksel bellek kapsamını ve EP LVE girişlerini gösterir. NPROC süreç/thread sayısıdır. Hiçbiri tek başına bir eklentinin suçlu olduğunu, kaç ziyaretçinin desteklendiğini veya yeni bir ürün gerektiğini kanıtlamaz.

Kullanım, limit, ortalama/maksimum, fault türü ve zaman aralığı birlikte anlam kazanır. Aynı aralıkta gerekli kullanıcı işlemlerini doğrulayın; düşük ortalama kısa ihlali, az fault da kritik bir başarısız işlemi önemsiz yapmaz.

Sonraki kişiye aktarılabilir bir kayıt bırakın: ne gözlendi, hangi birimle ölçüldü, ne hâlâ bilinmiyor ve hangi log bu boşluğu doldurabilir? Kaynak tablosunu bu şekilde okumak, teşhis ve kapasite kararının doğrulanabilir temelini oluşturur.