Linux sunucuda CPU kullanımı %100: yüksek load average ve yavaşlık nasıl çözülür?
VPS çok yavaş, Linux CPU kullanımı %100 veya load average sürekli yüksek görünüyor. Önce işlemcinin gerçekten iş yetiştiremediğini mi, uygulamanın bir kaynağı beklediğini mi, yoksa kendi CPU kotasına takıldığını mı bulacağız. Aynı belirti, farklı nedenlerden kaynaklanabilir.
Bu rehber, Linux'ta yüksek CPU kullanan süreci bulmak ve yavaşlığın nedenine göre işlem seçmek içindir. Bir yedekleme veya veri işleme işi kısa süreli yüksek CPU kullanıp başarıyla bitebilir. Yalnız yüzdeyi düşürmek, müşterinin açtığı sayfayı veya beklediği işlemi hızlandırdığınız anlamına gelmez.
Gereken erişim: SSH bağlantısı ve gerektiğinde sudo yetkisi. Komutlar bağlandığınız Linux sunucuda çalışır. root olarak bağlıysanız sudo önekini atlayabilirsiniz. İnceleme komutları ayar değiştirmez. Paylaşımlı hosting kullanıyorsanız tüm sunucuyu yönetemezsiniz; cPanel kaynak kontrolü ile kendi hesabınızın sınırlarını inceleyin. Genel RAM ve disk kontrolü için sunucu kaynakları rehberine bakın.
SSH da yanıt vermiyorsa DCHost müşteri portalındaki konsolu deneyin. Konsola da erişemiyorsanız hizmet numarası ve olay saatiyle destek talebi açın; yüksek load gördüğünüz için art arda yeniden başlatma yapmayın.
Görseller, Ubuntu 24.04 LTS ve 1 vCPU kullanan gerçek bir demo VPS'ten alınmıştır. Sonlu bir test işi yalnız bu çalışma için oluşturulan serviste, süre ve kaynak sınırlarıyla çalıştırılmıştır. Aynı iş iki farklı CPU kotasıyla karşılaştırılır. Bu, müşteri uygulamasında arıza veya fiziksel sunucuda kapasite sorunu oluşturulduğu anlamına gelmez. Kendi sunucunuzda teşhis için işlemciyi bilerek doldurmanız gerekmez.
1. CPU yüzdesi ile load average aynı şey mi?
Hayır. CPU yüzdesi, işlemcinin ölçüm aralığındaki zamanını nasıl geçirdiğini gösterir. Load average, çalışabilir durumdaki işler ile kesilemeyen bekleme durumundaki işlerin yük ortalamasıdır. Bir sayı yüzdeyi, diğeri iş yoğunluğunu anlatır.
Önce ölçüm zamanını, işlem birimi sayısını ve yükü kaydedin:
date -Is
nproc
uptime
vmstat 1 5
nproc, bu süreç için kullanılabilir işlem birimi sayısını gösterir; fiziksel çekirdeğin yalnız size ayrıldığını veya servisin CPU kotasının sınırsız olduğunu göstermez. CPU yakınlığı, konteyner sınırları ve araç sürümü de bağlama göre önemlidir. DCHost VPS/VDS altyapısında Proxmox/KVM kullanılması, tek başına her uygulamaya aynı performansı garanti etmez.
uptime içindeki üç load değeri 1, 5 ve 15 dakikalık zaman ölçeklerine aittir. Çalışan veya CPU sırası bekleyen işler ile genellikle I/O bekleyen D durumundaki işler bu hesaba girebilir. CPU sayısına göre otomatik bölünmez. Bu nedenle load değerini doğrudan “%CPU” diye okumayın; kısa iş bittikten sonra load'ın hemen sıfırlanmasını da beklemeyin.
Yük ortalamasını yorumlamadan önce kullanılabilir mantıksal CPU sayısını öğrenin. Bu ilk ölçüm test başlamadan alındı.
1. adım: Kullanılabilir CPU sayısını bulun
- Kullanılabilir CPU sayısını bulun
nproc bu oturum için 1 gösteriyor. Yükü değerlendirirken sunucunuzdaki CPU sayısını ve varsa servis kotasını birlikte düşünün.
- Üç zaman aralığını ayırın
Sırasıyla son 1, 5 ve 15 dakikanın yük ortalamaları gösterilir. Bu örnekte değerler 0,02, 0,02 ve 0,00.
Load average bir CPU kullanım yüzdesi değildir. CPU bekleyen işlerin yanında kesilemeyen bekleme durumundaki işler de bu değere katılır.
Başlangıçta nproc 1 gösterdi. Load değerleri 0,02 / 0,02 / 0,00, sonraki iki vmstat örneğinde boşta geçen zaman %99 idi. Bunlar test işi başlamadan önceki ölçümlerdir; her sunucu için hedef değer değildir.
vmstat çıktısında hangi sütunlar önemli?
İlk satırın CPU ve I/O hızları açılıştan beri geçen süreyi, sonraki satırlar birer saniyelik aralığı temsil eder. Süreç ve bellek alanları ise anlıktır. Güncel eğilim için sonraki örnekleri birlikte okuyun.
| Alan | Anlamı |
|---|---|
r | Çalışan veya CPU sırası bekleyen işler. Tek bir yüksek örnek yerine sürekliliğe bakın. |
b | I/O tamamlanmasını bekleyen işler. |
us / sy | Uygulama ve çekirdek tarafında geçen CPU zamanı. vmstat, nice önceliğiyle çalışan kullanıcı işlerinin zamanını da us içinde sayar. |
id | Boşta geçen CPU zamanı. |
wa | I/O beklemesiyle ilişkili zaman hesabı; tek başına disk arızası veya disk hız ölçümü değildir. |
st | Sanal makinenin sanallaştırma katmanı nedeniyle CPU çalıştıramadığı zamanın ölçümü; kendi servisinizdeki CPU kotasıyla aynı şey değildir. |
vmstat çıktısındaki son iki satır, test işi çalışırken alınan birer saniyelik ölçümlerdir.
1. adım: Son iki CPU örneğini okuyun
- Son iki CPU örneğini okuyun
us 98 ve 99, sy 1, id 0. Bu ölçümlerde CPU yoğun biçimde çalışıyor; tek satırı uzun dönemli sonuç gibi kullanmayın.
- r ve b sütunlarını ayırın
r çalışan veya CPU sırası bekleyen işleri, b ise I/O tamamlanmasını bekleyen işleri gösterir. Son örnekte r 1, b 0.
İlk satırdaki hız ve CPU yüzdeleri açılıştan bu yana ortalamadır; süreç ve bellek alanları aynı şekilde yorumlanmaz. Sonraki satırlar ölçüm aralığını gösterir.
Test işi %100 CPU kotasında çalışırken sonraki iki bir saniyelik vmstat örneğinde us=%98 / %99, sy=%1, id=%0 görüldü. st bu örneklerde %1 ve %0 idi. Buradaki kullanıcı zamanı nice önceliğiyle çalışan demo işini de içerir. İlk, açılıştan beri ortalama veren satırla bu aralıkları karıştırmayın.
2. Linux'ta CPU kullanan süreci bulun
Başlangıç listesi için:
ps -eo pid,ppid,comm,etime,%cpu,%mem --sort=-%cpu | head -n 11
PID süreç numarası, PPID onu başlatan üst sürecin numarası, COMMAND program adı, ELAPSED ise açık kalma süresidir. Tam komut satırı yerine program adını gösteriyoruz; komuta yazılmış erişim anahtarlarını paylaşmayın.
ps içindeki %CPU, o sürecin ömrü boyunca kullandığı CPU zamanının geçen süreye oranıdır. Uzun zamandır çalışan ama son birkaç saniyedir yoğunlaşan bir uygulama bu listede düşük görünebilir. Anlık sayılabilecek aralık ölçümü için top ile devam edin:
top -d 1
- Birkaç yenileme bekleyin; karşılaştırmayı ilk ekranla sınırlamayın.
- Büyük
P, süreçleri CPU kullanımına göre sıralar. 1, birden fazla işlem birimi varsa ayrı CPU satırlarını açıp kapatır.q, uygulamaları durdurmadantopekranından çıkar.
Bu ekran yalnız demo sürecine filtrelenmiş top çıktısının ikinci örneğidir. Genel süreç listesinin tamamını göstermiyor.
1. adım: CPU zamanının hangi alanda olduğunu görün
- CPU zamanının hangi alanda olduğunu görün
ni 100,0 görünüyor. Demo işi nice değeri 10 ile çalıştığı için kullanıcı işi bu alana yazılıyor; id bu örnekte 0,0.
- Süreç satırındaki CPU payını okuyun
Seçili python3 süreci yüzde 99,9 gösteriyor. top’un varsayılan Irix modunda yüzde 100, bir mantıksal CPU’nun tamamına karşılık gelir.
Bu karedeki oranlar örnek aralığına aittir. İlk top örneği ve önceki ölçümlerdeki steal değerleri farklı olabilir.
Görsel yalnız demo PID'sine filtrelenmiş çıktıyı gösterir; bütün süreçlerin listesi değildir. Gerçek kaydın ikinci top güncellemesinde demo süreci %99,9 CPU, toplu satır ise ni=%100 ve id=%0 gösterdi. Bu örnek, 1 vCPU üzerinde CPU hesaplaması yapan sonlu işin ölçümüdür. Daha önceki kısa ilk ekrandaki st değeriyle sonraki bir saniyelik örneği aynı aralık gibi karşılaştırmayın.
Bir süreç nasıl %100'ün üzerinde CPU kullanabilir?
top varsayılan Irix gösteriminde bir mantıksal CPU'yu %100 kabul eder. Çok iş parçacıklı bir süreç birden fazla CPU üzerinde çalıştığında %100'ü aşabilir. Solaris gösteriminde ise süreç yüzdesi CPU sayısına bölünür; I tuşu bu gösterimler arasında geçiş yapar.
Üstteki toplu %Cpu(s) satırıyla bir sürecin %CPU sütununu aynı payda gibi karşılaştırmayın. Örneğin dört işlem birimli sistemde bir CPU'yu tamamen kullanan tek iş, toplu kullanımda yaklaşık %25 görülebilir. Bu yalnız payda örneğidir; bu rehberdeki demo 1 vCPU kullanır. Birden çok CPU eklemek de tek iş parçacığıyla çalışan her işlemi kendiliğinden paralelleştirmez.
top, nice önceliğiyle çalışan kullanıcı işlerinin zamanını ni alanında ayrıca gösterir. Demo işi Nice=10 kullanır; bu nedenle CPU zamanı büyük ölçüde ni içinde görünür. ni yüksekken yalnız us düşük diye CPU boşta sanmayın. vmstat bu nice zamanını us içine katar. Nice göreli çalışma önceliğini değiştirir; sert CPU kotası değildir ve kullanılabilir işlemciyi kullanmayı engellemez.
Süreci doğru uygulamayla eşleştirin
Aşağıdaki 1234 yerine gerçek PID'yi yazın:
CHECK_PID=1234
ps -p "$CHECK_PID" -o pid,ppid,comm,etime,stat,%cpu,%mem
systemctl status "$CHECK_PID" --no-pager
systemctl status, uygun bir systemd birimiyle eşleştirebildiğinde ilgili servisi gösterir. Her süreç ayrı bir systemd servisi olmak zorunda değildir. Süreç bitmiş veya PID başka bir işe verilmiş olabilir; adı ve zamanı yeniden kontrol edin. Durum ekranının hata koduyla bitmesi de servisin etkin olmaması gibi bir durumu gösterebilir; yalnız kodu görüp yeni bir arıza varsaymayın. systemctl status, tam komut satırı ve son günlük kayıtlarını da gösterebilir; paylaşmadan önce özel bilgileri gizleyin.
Süreç adına bakarak işlem yapmak yerine PID, sahibi ve systemd servis kimliğini birlikte doğrulayın.
1. adım: PID ve MainPID eşleşmesini kontrol edin
- PID ve MainPID eşleşmesini kontrol edin
ps listesindeki PID 13616, systemctl çıktısındaki MainPID ile aynı. Böylece hangi servisi incelediğimizi doğruluyoruz.
- Servis adını kaydedin
Id alanı dchost-cpu-demo.service değerini gösteriyor. Kendi sunucunuzda günlükleri ve yapılandırmayı bu doğruladığınız servis üzerinden inceleyin.
ps çıktısındaki yüzde 96,9 CPU değeri sürecin ömrü boyunca ortalamadır; top’un son örneğiyle birebir anlık değer gibi karşılaştırmayın.
Demoda PID 13616, dchost-cpu-demo.service ile eşleştirildi. O andaki ps ömür ortalaması %96,9 idi; bu değerin önceki top aralık ölçümüyle birebir aynı olması gerekmez. STAT içindeki R çalışabilir durumu, N ise daha düşük nice önceliğini gösteriyordu.
Yalnız listenin başında diye veritabanını, yedekleme işini veya bilinmeyen bir süreci kapatmayın. Önce ne yaptığını ve kullanıcıların hangi işleminin yavaşladığını eşleştirin. Bir süreç adı, tek başına zararlı yazılım veya hatalı uygulama kanıtı değildir.
3. Load yüksek ama CPU düşükse neye bakmalısınız?
High load, low CPU durumunda bütün sorunları işlemciye bağlamak yanıltıcıdır. Yük ortalamasına giren işler disk veya başka bir kaynağı bekliyor olabilir; uygulama da CPU kotası nedeniyle çalıştırılmıyor olabilir.
| Birlikte gördüğünüz bulgu | Sonraki inceleme |
|---|---|
Yüksek us / sy, düşük id, tekrar tekrar üstte görülen uygulama | Uygulamanın işi, eşzamanlı işlem sayısı, sorgular ve CPU kapasitesi. top okurken nice kullanıcı zamanını da hesaba katın. |
Yüksek load, belirgin b / wa, düşük uygulama CPU kullanımı | I/O bekleyen süreçler, uygulama ve depolama kayıtları. wa tek başına “disk bozuk” demek değildir. |
| Düşük kullanılabilir RAM, devamlı swap hareketi | RAM, OOM ve swap incelemesi. |
| Yeterli genel CPU boşluğu, servis kotasında artan throttling | Servisin CPU sınırı. |
| Kaynaklar normal, yalnız belirli sayfa veya iş yavaş | Uygulama sorgusu, kilit, dış API veya ağ yanıtı. Uygulamanın kendi kaydını inceleyin. |
wa özellikle çok CPU'lu sistemlerde yorumlanması güç bir sayaçtır; çekirdek belgelendirmesi de bu hesabın sınırlamalarını açıklar. Her D durumu arızalı disk anlamına gelmez. Dış bir API yanıtını beklemek de mutlaka yüksek wa oluşturmaz.
PSI ile bekleme baskısını birlikte okuyun
Sunucunuz destekliyorsa şu dosyalar salt okunur ölçüm sunar:
cat /proc/pressure/cpu
cat /proc/pressure/io
cat /proc/pressure/memory
PSI, kaynak beklenirken işlerin ne kadar süre durakladığını gösterir. some satırındaki avg10, avg60 ve avg300, 10, 60 ve 300 saniyelik zaman ölçeklerindeki bekleme yüzdeleridir; CPU kullanım yüzdesi değildir. total mikrosaniye cinsinden birikmiş beklemedir. Yalnız büyük bir toplam görmek, şu anda baskı olduğunu göstermez.
Sistem genelindeki CPU full ölçümü tanımlı değildir ve uyumluluk için sıfır görünebilir; bunu “CPU tarafında hiç bekleme yok” diye yorumlamayın. Dosyalar yoksa çekirdek/ortam desteğini kontrol edin; onları oluşturmak veya içine değer yazmak bu incelemenin parçası değildir.
PSI, işlerin kaynak beklerken durakladığı süreyi gösterir. CPU, disk ve bellek baskısını ayrı okuyun.
1. adım: CPU some değerinin anlamını okuyun
- CPU some değerinin anlamını okuyun
avg10 44,38, son 10 saniyelik pencerede en az bir işin CPU beklediği zaman payını anlatır. Bu değer CPU kullanımının yüzde 44,38 olduğu anlamına gelmez.
- Kaynakları ayrı karşılaştırın
Aynı anda I/O some avg10 0,14; bellek some avg10 0,00. Bir kaynağın baskısını diğerinin kullanım yüzdesiyle eşitlemeyin.
Sistem genelindeki CPU full alanı anlamlı bir ölçüt değildir. total birikimli süredir; yakın dönem ortalaması sıfır olsa bile geçmiş toplamı sıfır olmayabilir.
%25 kotalı iş çalışırken alınan bu sistem geneli örnekte CPU some avg10=44.38 idi; bu, CPU kullanımının %44,38 olduğu anlamına gelmez. I/O için some avg10=0.14, bellek için güncel ortalamalar sıfırdı. Buna karşın geçmişten biriken I/O ve bellek total değerleri sıfır değildi. Bu sayılar tek başına disk veya fiziksel sunucu arızası teşhisi koydurmaz.
4. CPU kotası ve steal time farkını kontrol edin
CPUQuota, belirli servis veya konteynerin kullanabileceği CPU zamanını sınırlar. CPU steal time (st) ise sanal makinenin sanallaştırma katmanı nedeniyle CPU çalıştıramadığı zamanı gösterir. Bu iki bulgu farklı katmanlara aittir; birbirinin yerine kullanılmaz.
st tekrar eden ölçümlerde yüksekse olay saatini, örnekleri ve uygulamadaki etkisini kaydedin. Tek bir sıçramadan fiziksel sunucunun arızalı veya komşu sanal makinelerin kesin neden olduğu sonucunu çıkarmayın. st=0 da her tür performans sorununun dışlandığı anlamına gelmez.
Kendi servis adınızı yazıp ilgili sınırları okuyun:
APP_UNIT=my-app.service
systemctl show "$APP_UNIT" \
--property=LoadState,ActiveState,ControlGroup,CPUQuotaPerSecUSec,CPUQuotaPeriodUSec,CPUWeight
LoadState=not-found ise servis adını düzeltin. CPUQuotaPerSecUSec=250ms, saniye başına en fazla 250 milisaniyelik CPU zamanı bütçesi anlamına gelir; bu, bir CPU'ya göre %25'tir. CPUQuota=100%, tüm çok CPU'lu sunucunun %100'ü değil, bir CPU kadar toplam zaman bütçesidir. Bu bütçe servisteki süreçler arasında paylaşılır; belirli fiziksel çekirdeğin size ayrıldığı anlamına gelmez.
CPUWeight, rekabet eden gruplar arasındaki göreli payı etkiler; yüzde veya sert üst sınır değildir. Üst grubun kotası da alt servisi sınırlayabilir. Sınırları, o uygulamanın ve aynı sunucudaki diğer servislerin ihtiyacına göre değerlendirin. [not set], o birimde özelliğin açıkça ayarlanmadığını gösterir; CPU ağırlığının sıfır olduğu anlamına gelmez.
CPU kullanımı beklediğiniz gibi değilse servis grubunun sınırını kontrol edin. Bu ilk çalışmanın kotası yüzde 100.
1. adım: cpu.max içindeki iki değeri ayırın
- cpu.max içindeki iki değeri ayırın
100000 100000, her 100000 mikrosaniyelik dönem için 100000 mikrosaniyelik CPU bütçesidir. Bu, bir mantıksal CPU’nun yüzde 100’üne karşılık gelir.
- Kısıtlama sayaçlarını kaydedin
Bu örnekte nr_periods 55; nr_throttled ve throttled_usec 0. Daha düşük kota denemesinde aynı alanların nasıl değiştiğine bakacağız.
Bu kontrol yalnız demo servisine aittir. Kısıtlama sayaçlarının o anda sıfır olması başka servislerin veya sonraki ölçümlerin de aynı olduğu anlamına gelmez.
İlk demo servisinde CPUQuotaPerSecUSec=1s, dönem 100ms ve canlı grup dosyasında cpu.max=100000 100000 görüldü. İkinci servis %25 için 250ms ve 25000 100000 kullandı. Bu değerler iki ayrı demo servisinin ayarlarıdır.
cgroup v2 sayaçlarını doğru yerde okuyun
Önce servisin gerçek grup yolunu alın. Aşağıdaki blok yol boş veya kök grup olduğunda dosya okumaya geçmez:
APP_CGROUP=$(systemctl show "$APP_UNIT" --property=ControlGroup --value)
printf 'ControlGroup=%s\n' "$APP_CGROUP"
if [ -n "$APP_CGROUP" ] && [ "$APP_CGROUP" != / ]; then
sudo cat "/sys/fs/cgroup$APP_CGROUP/cpu.max"
sudo cat "/sys/fs/cgroup$APP_CGROUP/cpu.stat"
fi
Bu yol, çalışan servise ve cgroup v2 ortamına aittir. Servis tamamlanıp grup kaldırıldıysa dosyalar bulunmayabilir. Kök cgroup'da cpu.max bulunmamasını bozuk yapılandırma gibi yorumlamayın; rastgele başka bir grup yolundan aldığınız sayacı da uygulamanıza atfetmeyin.
| Alan | Nasıl okunur? |
|---|---|
cpu.max | Kota ve dönem, mikrosaniye olarak iki sayıdır. Örneğin 25000 100000, her 100 ms dönemde en fazla 25 ms CPU bütçesidir. max, o grupta sonlu kota olmadığı anlamına gelir. |
usage_usec | Grubun birikmiş CPU zamanı; işin saat üzerinden geçen toplam süresi değildir. |
nr_throttled | Kota nedeniyle sınırlama görülen dönemlerin/olayların sayacı. Tek başına CPU kullanım yüzdesi değildir. |
throttled_usec | Birikmiş sınırlanma süresi. Ölçüm aralığını ve grup kapsamını bilmeden “uygulama şu kadar yavaşladı” hesabına çevirmeyin. |
Yüzde 25 kotasındaki servis için iki saniye arayla aynı cgroup sayaçları okundu.
1. adım: İlk örneği referans alın
- İlk örneği referans alın
İlk okumada nr_periods 60, nr_throttled 59. throttled_usec, kısıtlama altında geçen birikimli süreyi mikrosaniye cinsinden gösterir.
- İkinci örnekteki farkı hesaplayın
İki saniye sonra değerler 80 ve 79. Sayaçların artması, bu süreç grubunun belirlenen CPU bütçesine takıldığını gösteriyor.
Bu sayaçlar servisin CPU kotası altında tutulduğunu gösterir; sunucunun genel CPU kullanım yüzdesi değildir.
İkinci, %25 kotalı servisin aynı cgroup dosyasından iki saniye arayla okunduğunda nr_periods 60 → 80, nr_throttled 59 → 79 oldu. usage_usec 1505097 → 2005453, throttled_usec 4348414 → 5844204 olarak değişti. Bunlar o grubun artan sayaçlarıdır; farklı servislerin toplamlarını birbirinden çıkararak hız karşılaştırması yapmıyoruz.
İki saniyede yaklaşık 0,50 saniye CPU zamanı kullanılması, bu tek CPU'lu %25 kota örneğiyle uyumludur. Sayaçtaki artışın kendisi “sunucu arızalı” anlamına gelmez; sınırın uygulandığını gösterir.
Bu ikinci çalışma aynı miktarda iş yapıyor; yalnız CPU kotası yüzde 25. Ekran, seçili demo sürecinin ikinci top örneğidir.
1. adım: Boş CPU varken de iş bekleyebilir
- Boş CPU varken de iş bekleyebilir
Bu örnekte ni 25,2 ve id 72,1. Servisin kotası, genel CPU boş olsa bile bu işin daha fazla CPU zamanı almasını sınırlayabilir.
- Süreç kullanımını yeniden ölçün
Demo süreci bu aralıkta yüzde 24,0 CPU gösteriyor. Yüzde 25 kota, her kısa örnekte tam yüzde 25,0 görüleceği anlamına gelmez.
Daha düşük kullanım daha hızlı bitiş anlamına gelmez. İş süresini iki çalışma tamamlandıktan sonra ayrıca karşılaştıracağız.
%25 kotalı işin ikinci top aralık örneğinde süreç %24,0 CPU kullanırken toplu satırda ni=%25,2, id=%72,1 ve st=%0,9 görüldü. Sunucu boşta zaman gösterebilirken belirli bir işin kendi kotası nedeniyle daha yavaş tamamlanması mümkündür. Bu değerler tek örneğe aittir; her aralıkta tam %25 beklemeyin.
5. Yük artışı yedekleme veya zamanlanmış işle aynı saate mi denk geliyor?
Her gün benzer saatte yavaşlama oluyorsa yedekleme, sıkıştırma, antivirüs taraması, rapor oluşturma ve güncelleme işlerini inceleyin. Zaman çakışması iyi bir başlangıçtır; tek başına neden-sonuç kanıtı değildir.
systemctl list-timers --all --no-pager
crontab -l
Timer listesindeki LAST, zamanlayıcının son tetiklenmesini; ACTIVATES, başlattığı birimi gösterir. İşin başarıyla tamamlandığını bu listeden anlayamazsınız. ACTIVATES sütunundaki gerçek servis adını aşağıdaki ilk satıra yazıp günlüğünü olay saatiyle eşleştirin:
JOB_UNIT=scheduled-job.service
sudo journalctl -u "$JOB_UNIT" --since "30 minutes ago" --no-pager
crontab -l, yalnız bağlı olduğunuz kullanıcının kayıtlarını gösterir; “no crontab” sonucu sunucuda hiç zamanlanmış iş olmadığı anlamına gelmez. Root kullanıcısının ayrı crontab'ı, /etc/crontab, /etc/cron.d/, systemd timer'ları ve panel içindeki görevler ayrıca bulunabilir. cPanel cron rehberi hesap görevleri içindir.
CPU artışı belirli saatlerde tekrarlanıyorsa systemd zamanlayıcılarını ve cron görevlerini inceleyin. Burada yalnız mevcut envanteri okuyoruz.
1. adım: Son tetiklenme zamanını görevin adıyla eşleştirin
- Son tetiklenme zamanını görevin adıyla eşleştirin
PASSED son tetiklenmeden bu yana geçen süreyi, UNIT zamanlayıcının adını gösterir. Şüphelendiğiniz görevi olay saatiyle karşılaştırın.
- Cron tarafını da kontrol edin
Cron servisi active görünüyor; cron.d içinde e2scrub_all ve sysstat dosyaları var. Bu yalnızca envanterdir, nedensellik kanıtı değildir.
Listede bulunması, bir görevin CPU artışına neden olduğunu kanıtlamaz. Olay saatini ve ilgili servisin günlüklerini birlikte inceleyin.
Demoda timer listesi, cron.service durumu ve /etc/cron.d dosya adları yalnız okundu. Cron etkin görünüyordu. Listede bir bakım işinin bulunması, o işin bu CPU yükünü oluşturduğunu göstermez; rehberdeki yük, kimliğini bildiğimiz ayrı demo programından geldi.
Yükü azaltmak için yedeklemeyi iptal etmek yerine işleri farklı saatlere dağıtmayı ve aynı işin üst üste başlamasını önlemeyi değerlendirin. Saat değiştirirken sunucunun saat dilimini, yedek penceresini ve uygulamanın görev ayarlarını koruyun. Güncelleme servisini, posta kuyruğunu veya güvenlik taramasını yalnız CPU kullanıyor diye kapatmayın.
6. CPU yüzdesini değil, işin sonucunu iyileştirin
Aynı sabit işi iki CPU kotasıyla çalıştırdık. Burada veri miktarı ve yapılacak hesap değişmedi; yalnız demo servisinin CPU zamanı bütçesi değişti.
İki sonlu iş de tamamlandı. Aynı 6 milyon işlemin gerçek test ölçümleri ve doğrulanan servis kotaları bu tabloda karşılaştırılıyor.
1. adım: İş miktarını ve CPU süresini karşılaştırın
- İş miktarını ve CPU süresini karşılaştırın
İki satırda da 6000000 işlem var. CPU üzerinde harcanan süreler 13,957 ve 14,141 saniye; işin sonucu da aynı.
- İşin tamamlanması için geçen süreyi okuyun
Elapsed time, başlangıçtan bitişe geçen süredir. Yüzde 25 kotada bu iş 56,570 saniyede bitiyor; daha düşük CPU kullanımı daha kısa bekleme sağlamıyor.
Bu demoda geçen süre oranı 3,98. Bu oran başka bir uygulama için performans vaadi değildir; daha düşük CPU bütçesinin bu işe etkisini gösterir.
Her iki denemede 6.000.000 SHA-256 işlemi, aynı girdilerle tamamlandı ve tam sonuç özeti birebir eşleşti. Özetin başlangıcı 43cba29b3c80… idi.
| Gerçek demo sonucu | %100 CPU kotası | %25 CPU kotası |
|---|---|---|
| Test işinin kullandığı CPU zamanı | 13,957 saniye | 14,141 saniye |
| Başlangıçtan bitişe geçen süre | 14,228 saniye | 56,570 saniye |
| Yapılan işlem sayısı | 6.000.000 | 6.000.000 |
| Sonuç özeti | Aynı | Aynı |
| Servis sonucu | success, çıkış kodu 0 | success, çıkış kodu 0 |
Bu demoda daha düşük kota ile aynı işin tamamlanması yaklaşık 3,98 kat uzun sürdü. Bu oran, bu denemenin sonucudur; her uygulama için genel performans katsayısı değildir. İş miktarı ve eşzamanlılık azaltılmadı.
Demo servisleri oneshot ve RemainAfterExit ayarlıydı. İş bittikten sonra birimler active görünse de MainPID=0 idi; hesaplama sürmüyordu. Boşalan cgroup yolları da kaldırıldığından karşılaştırmada canlı cpu.max okunmadı: çalışma sırasındaki kayıtlar, yüklü birim ayarları ve tamamlanan işin sonuç dosyaları birlikte kullanıldı.
Bu karşılaştırma, düşük CPU yüzdesinin tek başına daha iyi performans demek olmadığını gösterir. Arka plandaki bir işe kota koymak başka işlere alan bırakabilir; aynı işin bitmesini de geciktirebilir. Bu demoda müşteri web sitesi hızlanması ölçülmedi; kendi uygulamanızdaki yanıtı ayrıca kontrol edin.
| Bulduğunuz neden | Uygulanabilecek değişiklik |
|---|---|
| Aynı anda çok fazla işçi süreci (worker) çalışıyor | Uygulamanın kendi ayarından eşzamanlı işi azaltın; kuyruk bekleme süresinin artıp artmadığını kontrol edin. |
| Yedekleme, tarama ve rapor aynı saate yığılmış | Zamanlamayı ayırın; işlerin yine tamamlandığını ve yedeğin kullanılabildiğini doğrulayın. |
| Tek bir sorgu veya kod yolu aşırı CPU tüketiyor | Uygulama kayıtları ve profil ölçümüyle o işlemi inceleyin. Bütün sunucuya rastgele ayar uygulamayın. |
| Servisin kotası beklenen işe göre düşük | Mevcut sınırı ve diğer servislerin ihtiyacını kaydedin; uygun bütçeyi kontrollü olarak planlayın. |
| Gerekli normal iş yükü sürekli mevcut kapasiteyi aşıyor | Paket yükseltmeyi değerlendirin; uygulamanın ek CPU'lardan yararlanıp yararlanamadığını da kontrol edin. |
Uygulamanın desteklediği yöntemle, etkisini bildiğiniz bir değişiklik yapın. kill -9, bütün sunucuyu yeniden başlatmak veya CPU kotasını herkese aynı değerde ayarlamak genel optimizasyon yöntemi değildir. Çalışan bir işi durdurmanız gerekiyorsa önce yarım kalan işlem, veritabanı ve kuyruk üzerindeki etkisini belirleyin; uygulamanın normal durdurma yöntemini ve uygun bakım zamanını kullanın.
İki sonlu işin tamamlanmasının ardından CPU ve yük ortalamaları yeniden ölçüldü.
1. adım: Son CPU aralıklarını karşılaştırın
- Son CPU aralıklarını karşılaştırın
İlk ortalama satırından sonraki id değerleri 99, 100 ve 99. Bu ölçüm aralıklarında CPU’nun büyük bölümü boş.
- Yük ortalamasının zamana yayıldığını unutmayın
Bir, beş ve on beş dakikalık değerler 0,14, 0,08 ve 0,02. İş bitse bile bu ortalamaların hemen sıfırlanmasını beklemeyin.
Bu boş CPU ölçümü, sonlu işlerin tamamlanmasından sonra alındı. Load average geçmiş aralıkları da içerir; anlık CPU yüzdesiyle aynı değildir.
İki iş tamamlandıktan sonra alınan aralık örneklerinde CPU %99 / %100 / %99 boşta idi; load değerleri 0,14 / 0,08 / 0,02 kaldı. CPU düşüşü işlerin bitmesiyle ilişkilidir; düşük kota uygulanarak işin hızlandığı anlamına gelmez. Yük ortalamasının hemen sıfırlanmaması normaldir.
İki iş tamamlandıktan sonra alınan yaklaşık 17 saniyelik gerçek karşılaştırma kaydı. Aynı işin CPU kotası, CPU süresi ve geçen süresi okunuyor. Kayıt 1× hızda; orijinal zamanlama korunmuştur.
Kaydın yazılı anlatımı
Bu kısa kayıt, iki iş tamamlandıktan sonra alınan gerçek terminal karşılaştırmasıdır. Ekrandaki compare.py, yalnız bu demo için hazırlanan ve doğrulanmış sonuç dosyalarını okuyan yardımcıdır; kendi sunucunuzda bulunması beklenmez.
- İki demo servisinin başarılı sonucu, sıfır çıkış kodu ve farklı CPU kotaları okunur.
- Tamamlanan sonuçların özeti, her iki işte 6.000.000 işlem yapıldığını ve aynı sonuç özetinin elde edildiğini gösterir.
- CPU zamanı ile başlangıçtan bitişe geçen süre ayrı karşılaştırılır: %25 kotalı deneme bu örnekte yaklaşık 3,98 kat uzun sürmüştür.
- İşler bittikten sonraki
uptimevevmstatölçümleri okunur; CPU yeniden büyük ölçüde boşta görünür.
7. Son kontrolü aynı işlemle yapın
Değişiklikten önce yavaşlayan aynı sayfayı veya işi, benzer kullanım altında tekrar kontrol edin. Bir kerede birçok ayarı değiştirirseniz hangisinin etkili olduğunu ayırt etmek zorlaşır.
- İş doğru sonuçla tamamlandı mı; beklenen veri veya çıktı oluştu mu?
- Kullanıcının bekleme süresi ve uygulama hata sayısı nasıl değişti?
- Aynı aralıkta
top,vmstat, ilgili kota sayaçları ve uygulama günlükleri ne gösteriyor? - İş tamamlanınca CPU düşüyor mu; yük ortalaması zaman içinde normale dönüyor mu?
- Diğer servislerin ve zamanlanmış işlerin çalışması devam ediyor mu?
Geçici demo iş dosyaları ve servisleri kaldırıldıktan sonra aynı temel kontroller tekrarlandı.
1. adım: Son aralıkta CPU durumunu okuyun
- Son aralıkta CPU durumunu okuyun
Son iki örnekte us 0, sy 1, id 99 ve st 0. Bu değerler son ölçüm aralıklarını gösteriyor.
- SSH erişimini ve hata listesini kontrol edin
SSH servisi active. systemctl --failed çıktısında 0 loaded units listed görülüyor; bu kontrolde başarısız birim yok.
Bu ekran, demo temizliğinden sonraki anlık doğrulamadır. Üretim uygulamanızın yanıt süresini ve normal iş yükünü de kendi ölçümünüzle takip edin.
Son kontrolden önce yalnız bu çalışma için oluşturulan dosyalar ve iki geçici demo servisi kaldırıldı; içerikleri temizlenmeden önce doğrulandı. Normal sistem günlükleri korunur.
Son ekranda load 0,01 / 0,04 / 0,00, sonraki iki vmstat aralığında us=%0, sy=%1, id=%99, wa=%0, st=%0 idi. SSH active, başarısız systemd birimi sayısı 0 göründü. Bu, demonun o andaki bitiş kontrolüdür; kendi uygulamanızın sağlıklı çalıştığını ayrıca doğrulamalısınız.
Sık sorulan sorular
Linux CPU kullanımı %100 görünüyorsa sunucu arızalı mı?
Hayır. Yapılacak iş varsa işlemcinin kullanılması normaldir. İşin ne olduğu, ne kadar sürdüğü, beklenen sonucu üretip üretmediği ve diğer kullanıcıları etkileyip etkilemediği önemlidir. Sürekli doygunluk ve gecikme birlikte görülüyorsa nedenini araştırın.
Yüksek load average her zaman CPU yetersizliği mi?
Hayır. Çalışabilir işlerin yanı sıra kesilemeyen beklemedeki işler de yüke katılabilir. r, b, CPU alanları, PSI ve uygulama kayıtlarını birlikte inceleyin. Load, doğrudan bir CPU yüzdesi değildir.
ps ile top neden farklı CPU yüzdesi gösteriyor?
ps süreç ömründeki CPU zamanını geçen süreye böler. top süreçlerin son güncelleme aralığındaki kullanımını gösterir; ayrıca Irix/Solaris gösterimi ve iş parçacığı görünümü de önemlidir. Aynı süreci ve aynı zaman aralığını karşılaştırın.
VPS CPU steal yükselirse ne yapmalıyım?
Birden fazla zaman damgalı ölçüm ve uygulamadaki etkisini kaydedin; DCHost desteğine hizmet numarasıyla iletin. Tek bir st örneğiyle fiziksel sunucu arızası veya komşu sanal makine kaynaklı sorun teşhisi koymayın. Servis kotasını ayrıca kontrol edin.
CPU kotasını düşürmek VPS'i hızlandırır mı?
Her zaman değil. Bir işin CPU payını sınırlar ve diğer işlere alan bırakabilir; sınırlanan işi uzatabilir. Kota, eşzamanlılık ve uygulama yanıtını birlikte değerlendirin. Bu rehberde aynı işi %25 kota altında çalıştırmak bir hızlandırma olarak sunulmaz.
CPU normal ama VPS çok yavaşsa neye bakmalıyım?
RAM baskısı, I/O, uygulama kilitleri, veritabanı sorguları, ağ ve dış servis yanıtlarını inceleyin. RAM/OOM ve disk doluluğu rehberleri farklı sorunlar için ayrı adımlar sunar; disk doluluğu ile disk gecikmesi de aynı şey değildir.
Özellikle dış servis çağrısı zaman aşımına uğruyorsa DNS ile bağlantı ve uygulama yanıtını ayırın. DNS’in bir IP döndürmesi, hedef porta erişilebildiğini veya uygulamanın zamanında yanıt verdiğini tek başına göstermez.
Destek için hangi bilgileri göndermelisiniz?
DCHost müşteri portalından destek talebi açarken hizmet numarasını, saat dilimiyle olay zamanını, yavaşlayan işlemi ve son değişiklikleri belirtin. Aynı aralıkta alınmış birkaç CPU örneği, süreç/servis adı, kota bilgisi ve ilgili kısa günlük kesiti incelemeyi kolaylaştırır. Parola, özel anahtar, erişim belirteci veya tüm yapılandırma dosyalarını göndermeyin; herkese açık ekranlarda IP ve özel sunucu adlarını gizleyin.