- Konu sahibi
- #1
CPU kullanımını düşürmek için önce yükün hangi işlemden ve hangi koşulda kaynaklandığını bulun; ardından o işin yaptığı çalışmayı azaltın, yoğun işleri farklı zamanlara taşıyın veya gerektiğinde kaynak kapasitesini artırın. Yalnızca bir işlemi durdurmak ya da önceliğini değiştirmek, altta yatan nedeni çözmeyebilir.
Sunucuya SSH ile bağlanın ve aşağıdaki komutları çalıştırın. Sistem genelindeki işlemleri görebilmek için gerektiğinde yetkili bir hesap kullanın:
Bu göstergeler tek başına kesin neden belirtmez. Örneğin yüksek
Web veya uygulama işlemleri öndeyse sorunun belirli bir URL, eklenti veya zamanlanmış işle ilgili olup olmadığını uygulama ve web sunucusu günlüklerinden araştırın. Örneğin aynı sayfaya tekrarlanan istekler uygulamayı her defasında çalıştırıyorsa, içeriğin uygun olduğu durumlarda sayfa veya uygulama önbelleği kullanmak bu işi azaltabilir. Özel kullanıcı verisi içeren sayfaları herkese açık önbelleğe almadan önce erişim ve önbellek kurallarını doğrulayın. Anormal istek yoğunluğunda kaynağı ve istek yollarını inceleyin; meşru kullanıcıları etkilemeyecek biçimde hız sınırlaması veya engelleme uygulayın.
Veritabanı işlemi öndeyse, işlem adından hareketle rastgele ayar değiştirmek yerine uzun süren sorguları araştırın. MySQL kullanıyorsanız yetkili bir istemci oturumunda aşağıdaki komutlar yavaş sorgu günlüğünün durumunu ve dosya konumunu gösterir:
Günlük etkinse ve çıktı hedefi dosyaysa, yetkili hesapla gösterilen dosyayı inceleyerek tekrarlanan sorguları belirleyin. Uzun süre, tek başına sorgunun CPU tükettiğini kanıtlamaz; kilit veya başka beklemeler de süreyi etkileyebilir. Uygun bir
Yedekleme, raporlama veya toplu iş yük oluşturuyorsa, işin zamanlamasını uygulamanın kendi ayarından ya da ilgili cron veya systemd zamanlayıcısından kontrol edin. Mümkünse yoğun saatlerin dışına taşıyın ve aynı anda başlayan işleri farklı zamanlara yayın. Yeni başlatılacak, acil olmayan tek bir işi daha düşük CPU önceliğiyle çalıştırmak için komutun başına
Tanımadığınız bir işlemi yalnızca CPU kullanıyor diye sonlandırmayın. Önce
Her seferinde tek bir değişiklik yapın ve aynı tür iş yükü sırasında
İş yükü makul biçimde azaltıldığı hâlde CPU sürekli doluysa, işlemci kapasitesi yetersiz kalıyor olabilir. Önce yoğun işlem ve saat bilgilerini, çekirdek sayısını ve ölçümleri kaydedin; ardından uygulamayı daha fazla kaynağa taşıma, kaynak artırma veya işi birden fazla sunucuya dağıtma seçeneklerini değerlendirin.
CPU yükünü oluşturan işlemi bulun
Sunucuya SSH ile bağlanın ve aşağıdaki komutları çalıştırın. Sistem genelindeki işlemleri görebilmek için gerektiğinde yetkili bir hesap kullanın:
Kod:
nproc
uptime
topnproc kullanılabilir işlemci sayısını gösterir. top ekranında birkaç yenileme bekleyin; P tuşuyla işlemleri CPU kullanımına göre sıralayabilir, q ile çıkabilirsiniz. Sürekli üst sıralarda kalan işlemin PID, USER ve COMMAND bilgilerini not edin. Çok çekirdekli sistemlerde bir işlemin CPU değeri %100'ü aşabilir; bu, işlemin birden fazla çekirdekte çalışabildiğini gösterebilir.uptime ve top içindeki load average, son 1, 5 ve 15 dakikanın ortalama sistem yüküdür. Bu değer CPU yüzdesi değildir: CPU bekleyen işler yanında kesintisiz bekleme durumundaki işler de yük ortalamasına katkıda bulunabilir. Bu yüzden yalnızca yük ortalamasına bakarak işlemciyi suçlamayın.Ölçümü yorumlayın
top ekranındaki CPU satırı, yüksek kullanımın yönünü belirlemeye yardımcı olur:| Gösterge | Ne anlatır? | İlk inceleme |
|---|---|---|
| us yüksek | Uygulamalar CPU zamanı kullanıyor. | Üstteki işlemi ve yaptığı işi inceleyin. |
| sy yüksek | Çekirdek düzeyindeki çalışma yoğun. | Yoğun ağ, disk ve ilgili işlemleri inceleyin. |
| wa yüksek | Bekleyen disk işlemleri varken CPU boş kalıyor. | Disk gecikmesini ve yoğun okuma/yazmayı araştırın. |
| st yüksek | Sanal CPU, hipervizör başka işler yürütürken bekliyor. | Sağlayıcıya ölçüm ve zaman aralığıyla başvurun. |
wa, uygulamanın neden fazla disk erişimi yaptığını açıklamaz; yüksek st ise hangi komşu sistemin sorumlu olduğunu göstermez. Sürekli yüksek st görüyorsanız zaman aralığını, sanal sunucu kimliğini ve CPU ölçümlerini sağlayıcıya iletip fiziksel sunucudaki kaynak rekabetinin incelenmesini isteyin.Bulduğunuz işin yükünü azaltın
Web veya uygulama işlemleri öndeyse sorunun belirli bir URL, eklenti veya zamanlanmış işle ilgili olup olmadığını uygulama ve web sunucusu günlüklerinden araştırın. Örneğin aynı sayfaya tekrarlanan istekler uygulamayı her defasında çalıştırıyorsa, içeriğin uygun olduğu durumlarda sayfa veya uygulama önbelleği kullanmak bu işi azaltabilir. Özel kullanıcı verisi içeren sayfaları herkese açık önbelleğe almadan önce erişim ve önbellek kurallarını doğrulayın. Anormal istek yoğunluğunda kaynağı ve istek yollarını inceleyin; meşru kullanıcıları etkilemeyecek biçimde hız sınırlaması veya engelleme uygulayın.
Veritabanı işlemi öndeyse, işlem adından hareketle rastgele ayar değiştirmek yerine uzun süren sorguları araştırın. MySQL kullanıyorsanız yetkili bir istemci oturumunda aşağıdaki komutlar yavaş sorgu günlüğünün durumunu ve dosya konumunu gösterir:
SQL:
SHOW VARIABLES LIKE 'slow_query_log';
SHOW VARIABLES LIKE 'slow_query_log_file';
SHOW VARIABLES LIKE 'log_output';
SHOW VARIABLES LIKE 'long_query_time';Günlük etkinse ve çıktı hedefi dosyaysa, yetkili hesapla gösterilen dosyayı inceleyerek tekrarlanan sorguları belirleyin. Uzun süre, tek başına sorgunun CPU tükettiğini kanıtlamaz; kilit veya başka beklemeler de süreyi etkileyebilir. Uygun bir
SELECT sorgusunun başına EXPLAIN ekleyerek sorgu planını inceleyin; gereksiz taramaları, sorguyu veya uygun indeks ihtiyacını değerlendirin. Günlük kapalıysa üretim ortamında açmadan önce disk alanını, kayıt hedefini ve mevcut ayarları belirleyin; kısa bir ölçümden sonra eski duruma döndürün. Sorgu kayıtları hassas veri içerebileceğinden erişimi kısıtlayın ve geçici kopyaları iş bitince silin.Yedekleme, raporlama veya toplu iş yük oluşturuyorsa, işin zamanlamasını uygulamanın kendi ayarından ya da ilgili cron veya systemd zamanlayıcısından kontrol edin. Mümkünse yoğun saatlerin dışına taşıyın ve aynı anda başlayan işleri farklı zamanlara yayın. Yeni başlatılacak, acil olmayan tek bir işi daha düşük CPU önceliğiyle çalıştırmak için komutun başına
nice -n 10 ekleyebilirsiniz. Bu yöntem işin toplam hesaplama ihtiyacını azaltmaz ve tamamlanmasını geciktirebilir; özellikle CPU için rekabet olduğunda diğer işlere daha fazla fırsat verir.Tanımadığınız bir işlemi yalnızca CPU kullanıyor diye sonlandırmayın. Önce
ps -fp PID komutunda PID yerine gördüğünüz numarayı yazarak sahibi ve komut satırını inceleyin. Komut satırı hassas bilgiler içerebilir; çıktıyı paylaşmadan önce ayıklayın. Şüpheli veya yetkisiz görünen bir işlemde sahibi ve çalışma kaynağını araştırın; gerekli kanıtları koruyarak güvenlik incelemesi yapın.Değişikliği aynı koşullarda doğrulayın
Her seferinde tek bir değişiklik yapın ve aynı tür iş yükü sırasında
top ile ilgili işlemin CPU kullanımını, uygulamanın yanıt süresini ve hata kayıtlarını yeniden karşılaştırın. CPU düşerken yanıt süreleri veya hata sayısı kötüleşiyorsa yük yalnızca kısıtlanmış ya da başka bir kaynağa taşınmış olabilir; değişikliği gözden geçirin veya geri alın.İş yükü makul biçimde azaltıldığı hâlde CPU sürekli doluysa, işlemci kapasitesi yetersiz kalıyor olabilir. Önce yoğun işlem ve saat bilgilerini, çekirdek sayısını ve ölçümleri kaydedin; ardından uygulamayı daha fazla kaynağa taşıma, kaynak artırma veya işi birden fazla sunucuya dağıtma seçeneklerini değerlendirin.
