Tiesto

Tiesto

WFN Üye
Konular
589
Mesajlar
589
Çözüm
0
Ticaret Puanı
0
Üyelik
23 Gün
Konum
Antalya
Web Sitesi
Var
Alanı
Domain Uzmanı
1/1
Konu sahibi
İlk olarak yüksek CPU kullanımının hangi süreçten ve hangi iş yükünden kaynaklandığını ölçün; süreci hemen sonlandırmak yerine önce top veya htop ile doğrulayın, ardından işlemin normal bir yoğunluk mu yoksa kontrolsüz bir döngü, saldırı, yanlış yapılandırma ya da yetersiz kaynak belirtisi mi olduğunu ayırın. Sorun tek bir süreçteyse o hizmetin yapılandırmasını ve loglarını inceleyin; CPU bütün süreçlerde yükseliyorsa disk beklemesi, bellek yetersizliği, sanallaştırma kotası ve trafik yükünü de kontrol edin. Nedeni düzelttikten sonra CPU kullanımını birkaç dakika boyunca yeniden izleyin; yalnızca süreci öldürmek kalıcı çözüm değildir.

Önce yüksek CPU kullanımını doğrulayın​


SSH ile sunucuya bağlandıktan sonra genel işlem durumunu görmek için şu komutu çalıştırın:

Bash: 
top

Ekranın üst bölümünde toplam CPU kullanımını, alt bölümünde ise işlemleri görürsünüz. İşlem listesini CPU kullanımına göre sıralamak için genellikle P tuşuna basılır. q tuşu ile çıkabilirsiniz. Kuruluysa daha okunabilir bir görünüm için şu komutu da kullanabilirsiniz:

Bash: 
htop

top içinde bir sürecin CPU yüzdesinin uzun süre yüksek kalması, o sürecin işlemci kullandığını gösterir; ancak tek başına bunun zararlı veya hatalı olduğunu kanıtlamaz. Örneğin yedekleme, sıkıştırma, veritabanı bakımı veya yoğun trafik sırasında geçici yükselme normal olabilir. Süreç adını, PID değerini, çalışma süresini ve CPU kullanımının ne kadar süredir yüksek olduğunu birlikte değerlendirin.

Anlık ölçüm yanıltıcı olabileceği için bir dakika arayla birkaç kez kontrol edin. Komut satırından süreçleri CPU kullanımına göre kısa biçimde görmek için:

Bash: 
ps -eo pid,ppid,user,%cpu,%mem,etime,cmd --sort=-%cpu | head -n 15

Çıktının ilk satırları en fazla CPU kullanan süreçleri gösterir. Örneğin php-fpm, mysqld, nginx, java veya tek bir kullanıcı programı üst sıralardaysa sonraki incelemeyi o hizmete göre yapmalısınız.

CPU yükünün türünü ayırın​


Linux'ta CPU kullanımının yüksek görünmesi her zaman işlemcinin gerçekten uygulama çalıştırdığı anlamına gelmez. top ekranındaki CPU satırında özellikle şu değerleri ayırın:
  • us veya user: Kullanıcı süreçlerinin işlemci kullanımıdır. Uygulama, PHP, Java, Python veya veritabanı sorguları yoğun olabilir.
  • sy veya system: Çekirdek ve sistem çağrıları için harcanan zamandır. Yoğun ağ, disk, sürücü veya çok sayıda sistem çağrısı söz konusu olabilir.
  • wa veya iowait: CPU'nun disk veya başka bir G/Ç işlemini beklediği zamandır. Bu değer yüksekse yalnızca CPU'yu kısmaya çalışmak sorunu çözmez; disk gecikmesi ve depolama durumunu incelemek gerekir.
  • st veya steal: Sanal sunucuda fiziksel makinenin işlemci zamanını başka sanal makinelerle paylaşması nedeniyle beklenen zamanı gösterir. Süreçleri öldürmek bu değeri düzeltmez; sanallaştırma sağlayıcısının CPU kotası veya fiziksel ana makine yükü incelenmelidir.
Yüksek us değeri genellikle belirli bir uygulamaya, sorguya veya isteğe işaret eder. Yüksek wa değeri depolama gecikmesini, yüksek st değeri ise sanal sunucunun işlemci paylaşımını düşündürür. Bu değerler yalnızca teşhis yönü verir; kesin nedeni loglar, süreç ayrıntıları ve uygulama ölçümleriyle doğrulamak gerekir.

En çok CPU kullanan süreci inceleyin​


Önce süreç hakkında temel bilgileri alın. Aşağıdaki örnekte 1234 yerine gerçek PID değerini yazın:

Bash: 
ps -fp 1234
tr '\0' ' ' < /proc/1234/cmdline; echo
readlink -f /proc/1234/exe

Bu komutlar sürecin hangi kullanıcıyla, hangi komut satırıyla ve hangi çalıştırılabilir dosyayla başlatıldığını gösterir. PID'nin sahibi olmadığınız bir süreci sonlandırmadan önce yetki ve hizmet bağımlılıklarını kontrol edin. Aynı adla çalışan birden fazla süreç varsa yalnızca adına bakarak karar vermeyin; PID, kullanıcı, komut satırı ve üst süreç bilgilerini birlikte karşılaştırın.

Sürecin hangi hizmete ait olduğunu anlamak için systemd kullanan dağıtımlarda şu komut denenebilir:

Bash: 
systemctl status servis-adi
systemctl cat servis-adi

Buradaki servis-adi değerini gerçek hizmet adıyla değiştirin. status çıktısı hizmetin çalışıp çalışmadığını, son durumunu ve varsa son log satırlarını gösterir. cat ise hizmetin nasıl başlatıldığını ve hangi seçeneklerle çalıştığını incelemenize yardımcı olur. Süreci doğrudan öldürmeden önce hizmetin neden yeniden başlatılabildiğini veya aynı yükü tekrar oluşturabileceğini anlamaya çalışın.

Logları zaman aralığı belirterek incelemek, CPU yükselmesinin uygulama hatasıyla eş zamanlı olup olmadığını gösterir:

Bash: 
journalctl -u servis-adi --since "30 minutes ago" --no-pager

Web uygulamalarında ayrıca web sunucusu, PHP-FPM, uygulama ve veritabanı loglarını ayrı ayrı kontrol edin. Aynı istemci adresinden gelen çok sayıda istek, tekrarlanan hata, başarısız veritabanı sorgusu veya yeniden başlatma döngüsü görülürse CPU kullanımını azaltmadan önce bu kaynağı düzeltin.

Sonuca göre doğru müdahaleyi seçin​


Yüksek CPU kullanımının kaynağına göre uygulanacak işlem değişir. Aşağıdaki ayrım, yanlış müdahaleyi önlemek için kullanılabilir.
Gözlenen durumMuhtemel anlamıİlk sonraki adım
Tek bir uygulama süreci sürekli üst sıradaSorgu, döngü, yoğun istek veya uygulama hatası olabilirPID, komut satırı, loglar ve uygulama metriklerini inceleyin
Birden çok işçi süreç aynı anda CPU kullanıyorTrafik artışı, işçi sayısının fazla olması veya kuyruk birikmesi olabilirİstek sayısını, işçi yapılandırmasını ve yanıt sürelerini kontrol edin
CPU satırında wa yüksekDepolama veya G/Ç beklemesi vardırDisk gecikmesini, disk doluluğunu ve çalışan yedekleme/raporlama işlerini inceleyin
CPU satırında st yüksekSanal CPU zamanı ana makineyle paylaşılıyor olabilirSağlayıcı panelindeki CPU kotasını ve komşu yük etkisini kontrol edin
Bellek az, swap kullanımı artıyorBellek baskısı CPU beklemesini ve genel yavaşlamayı artırabilirBellek tüketen süreci bulun; swapı kapatmak yerine önce bellek nedenini çözün
Bu tablo yalnızca yön gösterir. Örneğin mysqld sürecinin yüksek CPU kullanması veritabanının bozuk olduğu anlamına gelmez; eksik indeks, pahalı sorgu, yoğun raporlama veya normal trafik de aynı sonucu doğurabilir. Benzer şekilde php-fpm yüksek CPU kullanıyorsa PHP kodu, dış API beklemeleri, sonsuz döngü veya fazla sayıda eşzamanlı istek ayrı ayrı değerlendirilmelidir.

Geçici olarak önem sırasını düşürme​


İşlem kontrollü bir bakım veya arka plan görevi ise önceliğini düşürerek ana hizmetlerin etkilenmesini azaltabilirsiniz. Örneğin çalışan bir sürecin PID'si 1234 ise:

Bash: 
renice +10 -p 1234

Bu işlem süreci durdurmaz; yalnızca CPU için yarışırken önceliğini düşürür. Görev hâlâ çok fazla işlemci tüketebilir ve işin tamamlanma süresi uzayabilir. Web sunucusu, veritabanı veya kritik bir sistem sürecinde bu ayarı rastgele uygulamayın; yanıt sürelerini kötüleştirebilirsiniz.

Yeni bir bakım komutunu düşük öncelikle başlatmak için:

Bash: 
nice -n 10 uzun-suren-komut

Bu yöntem bakım, sıkıştırma veya raporlama gibi ertelenebilir görevlerde daha uygundur. Ancak CPU tüketiminin nedeni hatalı bir döngüyse önceliği düşürmek hatayı düzeltmez; yalnızca etkisini kısmen gizler.

Kontrollü biçimde yeniden başlatma veya sonlandırma​


Bir hizmet kilitlenmişse veya acil olarak kaynak tüketimini durdurmanız gerekiyorsa önce normal durdurmayı deneyin:

Bash: 
sudo systemctl stop servis-adi

Hizmetin durduğunu şu komutla kontrol edin:

Bash: 
systemctl is-active servis-adi
systemctl status servis-adi

Sonuç inactive veya benzeri bir durmuş durum gösteriyorsa süreç artık çalışmıyor olabilir. Hizmet kısa süre sonra yeniden başlıyorsa bir yeniden başlatma politikası, izleme aracı, zamanlayıcı veya başka bir üst süreç onu tekrar başlatıyor olabilir. Bu durumda yalnızca kill kullanmak yerine hizmetin başlatılma nedenini ve yapılandırmasını inceleyin.

Normal durdurma yanıt vermiyorsa, PID'yi yeniden doğruladıktan sonra önce nazik sonlandırma sinyali gönderilebilir:

Bash: 
kill 1234
sleep 5
ps -p 1234 -o pid,stat,cmd

Süreç hâlâ çalışıyorsa ve sunucunun hizmet vermesini ciddi biçimde engelliyorsa zorla sonlandırma son çare olarak kullanılabilir:

Bash: 
kill -9 1234

kill -9 uygulamanın temizlik yapmasına fırsat vermez. Veritabanı, dosya yazan uygulama veya kuyruk işleyicilerinde veri bozulması, yarım kalan iş veya kilit dosyası riski oluşturabilir. Bu nedenle PID'yi kesin olarak doğrulamadan ve normal durdurmayı denemeden kullanmayın.

Yaygın kaynaklara göre kalıcı çözüm yolları​


Web sunucusu veya PHP-FPM CPU kullanıyorsa​


İstek sayısını, en uzun süren URL'leri ve hata oranını birlikte inceleyin. Tek bir URL'nin sürekli pahalı sorgu çalıştırması veya botların aynı uç noktayı yoğun biçimde çağırması CPU'yu yükseltebilir. Erişim loglarında zaman aralığı, istemci adresi, istenen yol ve yanıt durumlarını karşılaştırın.

PHP-FPM kullanılıyorsa işçi süreç sayısını doğrudan artırmak her zaman çözüm değildir. Her işçi bellek ve CPU tüketir; işçi sayısı CPU kapasitesini aşarsa daha fazla eşzamanlılık toplam yanıt süresini artırabilir. Önce yavaş kodu, veritabanı sorgularını, dış servis çağrılarını ve önbellekleme eksikliğini düzeltin. Daha sonra işçi sayısını mevcut bellek ve CPU kapasitesine göre kademeli değiştirip her değişiklikten sonra CPU, bellek ve yanıt süresini izleyin.

Veritabanı süreci CPU kullanıyorsa​


Önce aktif sorguları ve yavaş sorgu kayıtlarını inceleyin. Yüksek CPU tek başına veritabanını yeniden başlatma gerekçesi değildir; yeniden başlatma soruna neden olan sorguyu veya eksik indeksi ortadan kaldırmaz. Sorgu planını, filtrelenen ve sıralanan sütunları, dönen veri miktarını ve aynı anda çalışan sorgu sayısını kontrol edin.

Sorun tek bir sorgudan kaynaklanıyorsa sorguyu uygulama tarafında daraltmak, uygun indeks eklemek veya pahalı raporu yoğun saatler dışına taşımak daha kalıcıdır. Şema değişikliği yapmadan önce yedek, geri dönüş planı ve sorgunun mevcut uygulamayla uyumluluğu hazırlanmalıdır.

Cron, yedekleme veya raporlama işi CPU kullanıyorsa​


Görevin ne zaman başladığını ve CPU yükselmesiyle çakışıp çakışmadığını kontrol edin. Aynı işin önceki çalışması bitmeden yeniden başlaması, her çalışmada tüm veritabanının taranması veya sıkıştırmanın çok sayıda çekirdeği kullanması sık görülen nedenlerdir.

Görevi durdurmak yerine çalışma sıklığını azaltmak, yalnızca değişen verileri işlemek, arka plan işini nice ile düşük öncelikte çalıştırmak veya yoğun olmayan saatlere taşımak daha güvenlidir. Değişiklikten sonra cron çıktısını ve bir sonraki çalışma zamanını kontrol edin; görevin tamamen kaybolması başarı anlamına gelmez.

Bilinmeyen veya şüpheli bir süreç CPU kullanıyorsa​


Sürecin PID'sini, sahibini, çalıştırılabilir dosya yolunu, üst sürecini, başlangıç zamanını ve açtığı dosyaları kaydedin. Ardından ilgili kullanıcı hesabının giriş kayıtlarını, zamanlanmış görevleri, systemd hizmetlerini, web erişim loglarını ve son paket/yapılandırma değişikliklerini inceleyin.

Süreç rastgele bir dizinden çalışıyor, tanınmayan bir kullanıcıya ait oluyor, kendisini yeniden oluşturuyor veya ağ bağlantıları açıyorsa bunu yalnızca CPU optimizasyonu olarak değerlendirmeyin. Önce mümkünse sunucunun anlık görüntüsünü ve ilgili logları koruyun, etkilenen hizmeti ağdan sınırlayın ve güvenlik incelemesi başlatın. Süreci silmek kanıtları yok edebilir ve yeniden oluşan sürecin nedenini gizleyebilir.

Değişiklikten sonra sonucu ölçün​


Bir ayar değiştirdikten veya ağır süreci durdurduktan sonra top ekranına hemen bakıp karar vermeyin. En az birkaç ölçüm aralığında şu değerleri karşılaştırın:
  • Toplam CPU kullanımı ve us, sy, wa, st dağılımı.
  • En çok CPU kullanan süreçler ve bunların tekrar ortaya çıkıp çıkmadığı.
  • Web yanıt süresi, hata oranı ve istek sayısı.
  • Bellek kullanımı, swap etkinliği ve disk doluluğu.
  • Veritabanı sorgu süresi, bağlantı sayısı ve kuyruk birikimi.
  • Hizmetin yeniden başlatılıp başlatılmadığı ve loglarda yeni hata oluşup oluşmadığı.
CPU yüzdesinin düşmesi tek başına başarı kanıtı değildir. Örneğin bir süreci öldürdüğünüzde CPU düşebilir ancak web sitesi hata vermeye, kuyruk büyümeye veya veritabanı bağlantıları kopmaya başladıysa sorun çözülmemiştir. Doğru sonuç, CPU yükünün azalmasıyla birlikte hizmetin yanıt vermesi, hata oranının artmaması ve aynı nedenin kısa süre içinde tekrarlanmamasıdır.

Sorun devam ediyorsa destek talebine yalnızca “CPU yüksek” yazmayın. Şu bilgileri ekleyin: sorunun başladığı UTC tarih ve saat, etkilenen sunucu ve hizmet, top veya ps çıktısındaki en yüksek süreçler, CPU satırındaki us/sy/wa/st değerleri, değişikliklerden önce ve sonraki sonuçlar, ilgili logların zaman aralığı ve sanal sunucuysa st değerinin seyri. Böylece talep, genel bir yeniden başlatma isteği yerine belirli bir süreç, disk gecikmesi, CPU kotası veya uygulama yükü üzerinden incelenebilir.

Sık sorulan sorular​

CPU kullanımı yüzde 100 olunca sunucuyu hemen yeniden başlatmalı mıyım?​

Hayır. Önce hangi sürecin yük oluşturduğunu ve wa ile st değerlerinin yüksek olup olmadığını kontrol edin. Yeniden başlatma geçici rahatlama sağlayabilir ancak hatalı sorgu, trafik saldırısı, yeniden başlayan bir süreç veya sağlayıcı kaynak sorununu düzeltmez. Yalnızca hizmet yanıt vermiyorsa ve temel ölçümleri aldıysanız kontrollü yeniden başlatmayı değerlendirin.

Bir sürecin CPU kullanımını sınırlamak sorunu çözer mi?​

Genellikle hayır. nice veya benzeri kaynak sınırlamaları kritik hizmetlerin etkilenmesini azaltabilir; fakat sonsuz döngü, kötü sorgu, yoğun trafik veya zararlı süreç devam eder. Sınırlamayı geçici koruma olarak kullanıp asıl nedeni ayrıca düzeltin.

CPU kullanımı yüksek değilken sunucu neden yavaş olabilir?​

Disk beklemesi, bellek yetersizliği, swap kullanımı, ağ gecikmesi, sanal CPU paylaşımı veya tek iş parçacıklı bir uygulamanın tek çekirdeği doldurması sunucuyu yavaşlatabilir. Bu nedenle yalnızca toplam CPU yüzdesine değil, çekirdek başına yük, wa, st, bellek ve disk davranışına da bakın.

Hangi durumda sağlayıcıdan CPU kotası incelemesi istemeliyim?​

Sanal sunucuda st değeri sürekli yüksekse veya kendi süreçleriniz belirgin biçimde yoğun değilken CPU kullanımı ve yanıt süreleri kötüleşiyorsa sağlayıcıya başvurun. Talebe ölçüm saatlerini, top çıktısını, etkilenen sanal sunucuyu ve sorunun hangi zaman aralıklarında tekrarlandığını ekleyin; “sunucu yavaş” ifadesi yerine sanal CPU çalma zamanının incelenmesini isteyin.
 

Sende şimdi bize katılmak ister misin?

Kayıt ol

Bize katılım kolay ve ücretsizdir!

Üye ol
Foruma git ?

Bu konuyu görüntüleyen kullanıcılar

Bu konuyu şu anda görüntüleyen üye bulunmuyor.
Robotlar:
  • Anthropic
Toplam: 1 (Üye: 0, misafir: 0, robot: 1)