- Konu sahibi
- #1
İlk olarak CPU’yu hangi işlem veya hizmetin tükettiğini belirleyin; nedeni görmeden servisi rastgele durdurmak sorunu gizleyebilir veya çalışan uygulamayı kesintiye uğratabilir. Linux sunucuda kısa süreli sıçrama normal olabilir, ancak kullanım sürekli yüksekse
SSH ile sunucuya bağlandıktan sonra aşağıdaki komutlardan biriyle canlı işlem listesini açın:
Tek seferlik ekran yerine süreçleri birkaç saniye aralıklarla kaydetmek için şu komut daha kullanışlıdır:
Aynı PID birkaç ölçümde üst sıralarda kalıyorsa sürekli CPU tüketen aday odur. Tek bir anlık ölçüm ise yalnız geçici bir işlem, trafik artışı veya planlanmış görev anlamına gelebilir; tek başına kalıcı sorun kanıtı değildir.
Sürecin hangi servise ait olduğunu ve nasıl başlatıldığını görmek için PID’yi değiştirerek şu bilgileri alın:
Buradaki
İşlemci kullanımını incelerken yalnız toplam yüzdeye bakmayın.
Aşağıdaki komutla CPU, bellek ve çalıştırılabilir süreç sayısını birlikte görün:
Sorunun kısa süreli mi kalıcı mı olduğunu görmek için süreç ölçümünü birkaç kez tekrarlayın:
Aşağıdaki ayrım, hangi ayarı değiştirmeniz gerektiğini belirler:
Uygulama süreci yüksekse önce günlüklerde aynı dakikadaki hata, istek yolu, sorgu veya iş kimliğini arayın. Web uygulamalarında bütün işçilerin aynı anda yükselmesi trafik veya pahalı bir uç nokta ihtimalini artırır; yalnızca bir işçi yükseliyorsa tek bir istek, görev veya hatalı işlem daha olasıdır. Günlükte neden görünmüyorsa geçici olarak daha ayrıntılı tanılama açılabilir; işlem bittikten sonra ayrıntılı günlük seviyesini ve hassas veri içerebilecek tanılama kayıtlarını kapatın.
Önce doğrudan web sunucusunu suçlamayın. Nginx veya Apache çoğu zaman isteği kabul ederken CPU’yu PHP-FPM, uygulama kodu veya veritabanı tüketebilir. Süreç listesinden hangi bileşenin yüksek olduğunu ayırın; ardından aynı zaman aralığındaki erişim ve hata günlüklerini istek yolu, yanıt kodu ve istek süresi açısından karşılaştırın.
Tüm PHP-FPM işçileri doluyor ve CPU yüksek kalıyorsa işçi sayısını hemen artırmayın. Daha fazla işçi, mevcut CPU’yu paylaşmak yerine bağlam değiştirme ve bellek baskısını artırabilir. Önce pahalı sorguyu, döngüyü, eklentiyi veya yoğun istek alanını düzeltin. Trafik gerçekten kapasiteyi aşıyorsa önbellekleme, sorgu optimizasyonu, istek sınırlama veya yatay ölçeklendirme değerlendirilir.
Veritabanı istemci sayısını ve çalışan sorguları inceleyin. Yavaş sorgu kayıtlarında sorgunun süresi, tablo erişimi ve taranan satır sayısı belirginleşebilir. İndeks eklemeden önce sorgunun gerçek çalışma planını ve yazma maliyetini değerlendirin; her kolona indeks eklemek okuma hızını her zaman artırmaz, yazma ve depolama maliyetini yükseltebilir.
CPU’yu geçici olarak düşürmek için ağır rapor veya bakım işini durdurmak gerekebilir, ancak önce bunun güvenli olduğundan emin olun. İşlem yarıda kalırsa veri tutarlılığı veya görev kuyruğu etkilenebileceğinden, veritabanı bakımını kesmeden önce uygulamanın ve işlemin geri alma davranışını bilin.
İşlemi hemen sonlandırmak yerine, hizmetin çalışmaya devam etmesi gerekiyorsa CPU önceliğini düşürebilirsiniz:
Bu işlem yalnızca CPU zamanlamasındaki önceliği azaltır; hatalı kodu, pahalı sorguyu veya aşırı trafiği düzeltmez. Süreç yeniden başlatıldığında ayar kaybolabilir. İşlem kullanıcı yetkileri nedeniyle değiştirilemiyorsa komutu uygun yönetici yetkisiyle çalıştırın; ancak üretim hizmetinde önce etkisini ve geri alma yolunu bilin.
Güvenli biçimde kapatılması gereken bir süreç için önce nazik sonlandırma sinyali gönderilir:
Süreç kapanmışsa CPU kullanımı düşer; fakat bu yalnızca sürecin yeniden başlatılmasına neden olan problemi çözmez. Süreç kapanmıyorsa ve hizmetin durumu biliniyorsa servis yöneticisi üzerinden kontrollü yeniden başlatma uygulanmalıdır.
Değişiklikten sonra aynı ölçümleri yeniden alın: yük ortalaması,
Sorun tekrar ediyorsa şu bilgileri aynı zaman aralığıyla saklayın: tarih ve saat, sunucunun sanal CPU sayısı,
top veya htop ile işlemi bulun, aynı işlemin zaman içindeki davranışını pidstat ile doğrulayın, ardından uygulama günlüklerini ve servis ayarlarını inceleyin. Sorun tek bir süreçteyse o süreci düzeltin; tüm sistemde yaygınsa disk beklemesi, bellek yetersizliği, sanallaştırma kotası veya yoğun istek trafiğini ayrıca ayırın.Önce CPU’yu hangi süreç tüketiyor, bulun
SSH ile sunucuya bağlandıktan sonra aşağıdaki komutlardan biriyle canlı işlem listesini açın:
Bash:
toptop içinde CPU kullanımına göre sıralama için genellikle P tuşu kullanılır. İlk satırlardaki %CPU değerine, PID işlem kimliğine, USER kullanıcısına ve COMMAND sütununa bakın. Daha okunabilir bir arayüz isterseniz htop kullanılabilir; kurulu değilse yalnız bu araç için paket kurmak yerine mevcut top ile de teşhis yapılabilir.Tek seferlik ekran yerine süreçleri birkaç saniye aralıklarla kaydetmek için şu komut daha kullanışlıdır:
Bash:
ps -eo pid,ppid,user,stat,etime,%cpu,%mem,cmd --sort=-%cpu | head -n 15Aynı PID birkaç ölçümde üst sıralarda kalıyorsa sürekli CPU tüketen aday odur. Tek bir anlık ölçüm ise yalnız geçici bir işlem, trafik artışı veya planlanmış görev anlamına gelebilir; tek başına kalıcı sorun kanıtı değildir.
Sürecin hangi servise ait olduğunu ve nasıl başlatıldığını görmek için PID’yi değiştirerek şu bilgileri alın:
Bash:
PID=1234
ps -p "$PID" -o pid,ppid,user,etime,%cpu,%mem,cmd
readlink -f "/proc/$PID/exe"
cat "/proc/$PID/cgroup"Buradaki
1234 yerine gerçek PID’yi yazın. Çıktıda PHP-FPM, MySQL/MariaDB, Nginx, Apache, bir kuyruk işçisi, yedekleme aracı veya uygulamanızın kendi süreci görünebilir. cgroup bilgisi işlemin bir systemd servisine, kapsayıcıya veya başka bir kaynak grubuna bağlı olup olmadığını anlamaya yardımcı olur.CPU yükünü doğru yorumlayın
İşlemci kullanımını incelerken yalnız toplam yüzdeye bakmayın.
top ekranındaki yük ortalaması, işlemcinin kaç çekirdeği olduğuyla birlikte değerlendirilmelidir. Örneğin dört sanal CPU’lu bir makinede yük ortalamasının 1 civarında olması, tek çekirdeğe yakın bir bekleme anlamına gelebilir; 4’ün üzerine çıkması ise tüm işlemcilerin sürekli meşgul veya çalıştırılacak iş bekliyor olabileceğini gösterir. Bu değerler tek başına CPU’nun kesin olarak yetersiz olduğunu kanıtlamaz; işlemler disk veya ağ beklediğinde de yük artabilir.Aşağıdaki komutla CPU, bellek ve çalıştırılabilir süreç sayısını birlikte görün:
Bash:
uptime
nproc
free -h
vmstat 1 5vmstat çıktısında r değeri sürekli olarak kullanılabilir CPU sayısından yüksekse işlemci kuyruğu oluşuyor olabilir. si ve so değerleri sürekli sıfırdan büyükse sistem takas alanını kullanıyor olabilir; bu durumda CPU’yu düşürmeye çalışmadan önce bellek tüketimini inceleyin. wa yüksekse işlemcinin kendisi değil, çoğunlukla disk veya depolama gecikmesi beklenmelidir.Sorunun kısa süreli mi kalıcı mı olduğunu görmek için süreç ölçümünü birkaç kez tekrarlayın:
Bash:
pidstat -u -r -d -p 1234 5 6pidstat yoksa aynı PID’yi ps ile aralıklarla kontrol edebilirsiniz. pidstat boyunca CPU yüksek kalıyorsa süreç gerçekten sürekli çalışıyor demektir. CPU hızla yükselip düşüyorsa cron görevi, kuyruk tüketimi, önbellek yenileme, yedekleme veya dış bir isteğe verilen yanıt gibi dönemsel bir iş araştırılmalıdır.Sonuca göre düzeltme yolunu seçin
Aşağıdaki ayrım, hangi ayarı değiştirmeniz gerektiğini belirler:
| Gözlenen durum | Olası anlamı | İlk sonraki işlem |
|---|---|---|
| Tek bir uygulama süreci sürekli yüksek | Yoğun istek, sonsuz döngü, pahalı sorgu veya hatalı kod | Uygulama ve servis günlüklerini PID, zaman ve istek bilgisiyle inceleyin |
| MySQL/MariaDB yüksek | Yavaş sorgu, eksik indeks, eşzamanlı sorgu veya büyük rapor işlemi | Çalışan sorguları ve yavaş sorgu kayıtlarını inceleyin; sorguyu optimize edin |
| Birden çok süreç yüksek | Trafik artışı, toplu görev, kaynak sınırı veya genel kapasite yetersizliği | İşlemci, bellek, disk beklemesi ve istek sayısını birlikte ölçün |
CPU düşük, wa yüksek | Disk veya depolama beklemesi | Depolama gecikmesini ve I/O kullanan süreci inceleyin |
| CPU yüksek, bellek çok az ve takas artıyor | Bellek yetersizliği CPU baskısı gibi görünüyor olabilir | Bellek tüketen süreci bulun; önbellek, işçi sayısı ve uygulama sınırlarını düzenleyin |
PHP-FPM, Apache veya Nginx süreçleri yüksekse
Önce doğrudan web sunucusunu suçlamayın. Nginx veya Apache çoğu zaman isteği kabul ederken CPU’yu PHP-FPM, uygulama kodu veya veritabanı tüketebilir. Süreç listesinden hangi bileşenin yüksek olduğunu ayırın; ardından aynı zaman aralığındaki erişim ve hata günlüklerini istek yolu, yanıt kodu ve istek süresi açısından karşılaştırın.
Tüm PHP-FPM işçileri doluyor ve CPU yüksek kalıyorsa işçi sayısını hemen artırmayın. Daha fazla işçi, mevcut CPU’yu paylaşmak yerine bağlam değiştirme ve bellek baskısını artırabilir. Önce pahalı sorguyu, döngüyü, eklentiyi veya yoğun istek alanını düzeltin. Trafik gerçekten kapasiteyi aşıyorsa önbellekleme, sorgu optimizasyonu, istek sınırlama veya yatay ölçeklendirme değerlendirilir.
Veritabanı süreci yüksekse
Veritabanı istemci sayısını ve çalışan sorguları inceleyin. Yavaş sorgu kayıtlarında sorgunun süresi, tablo erişimi ve taranan satır sayısı belirginleşebilir. İndeks eklemeden önce sorgunun gerçek çalışma planını ve yazma maliyetini değerlendirin; her kolona indeks eklemek okuma hızını her zaman artırmaz, yazma ve depolama maliyetini yükseltebilir.
CPU’yu geçici olarak düşürmek için ağır rapor veya bakım işini durdurmak gerekebilir, ancak önce bunun güvenli olduğundan emin olun. İşlem yarıda kalırsa veri tutarlılığı veya görev kuyruğu etkilenebileceğinden, veritabanı bakımını kesmeden önce uygulamanın ve işlemin geri alma davranışını bilin.
Geçici olarak önceliği azaltın, kalıcı çözüm sanmayın
İşlemi hemen sonlandırmak yerine, hizmetin çalışmaya devam etmesi gerekiyorsa CPU önceliğini düşürebilirsiniz:
Bash:
renice +10 -p 1234Bu işlem yalnızca CPU zamanlamasındaki önceliği azaltır; hatalı kodu, pahalı sorguyu veya aşırı trafiği düzeltmez. Süreç yeniden başlatıldığında ayar kaybolabilir. İşlem kullanıcı yetkileri nedeniyle değiştirilemiyorsa komutu uygun yönetici yetkisiyle çalıştırın; ancak üretim hizmetinde önce etkisini ve geri alma yolunu bilin.
Güvenli biçimde kapatılması gereken bir süreç için önce nazik sonlandırma sinyali gönderilir:
Bash:
kill -TERM 1234
sleep 10
ps -p 1234 -o pid,stat,etime,%cpu,cmdSüreç kapanmışsa CPU kullanımı düşer; fakat bu yalnızca sürecin yeniden başlatılmasına neden olan problemi çözmez. Süreç kapanmıyorsa ve hizmetin durumu biliniyorsa servis yöneticisi üzerinden kontrollü yeniden başlatma uygulanmalıdır.
kill -9 son çare olmalıdır; işlem temiz kapanış yapamaz ve açık işlerin, geçici dosyaların veya bağlantıların nasıl etkileneceği uygulamaya bağlıdır.Düzeltmenin işe yaradığını doğrulayın
Değişiklikten sonra aynı ölçümleri yeniden alın: yük ortalaması,
vmstat, ilgili PID’nin CPU kullanımı, bellek ve disk beklemesi. CPU yüzdesinin düşmesi tek başına yeterli değildir; yanıt süreleri, hata oranı, istek kuyruğu ve servis günlükleri de normale dönmelidir. CPU düştüğü hâlde web sitesi yavaşladıysa süreç kısıtlanmış olabilir veya asıl darboğaz disk, veritabanı ya da ağ tarafında bulunuyor olabilir.Sorun tekrar ediyorsa şu bilgileri aynı zaman aralığıyla saklayın: tarih ve saat, sunucunun sanal CPU sayısı,
uptime, free -h, vmstat 1 5, en yüksek CPU kullanan süreçlerin PID ve komut satırları, ilgili servis günlüklerindeki hata satırları ve mümkünse trafik veya sorgu yoğunluğu. Hassas parola, erişim belirteci ve kullanıcı verilerini paylaşmadan bu kayıtlarla hosting sağlayıcısından kaynak kotasını, sanal CPU komşuluğunu, kapsayıcı limitini veya fiziksel sunucu tarafındaki kısıtı incelemesini isteyin. Böylece talep yalnızca “CPU yüksek” şeklinde kalmaz; sorunun hangi süreçte, hangi saatte ve hangi kaynak davranışıyla oluştuğu gösterilebilir.