Sunucu yükünün artmasının nedenini bulma


12

Sunucumla ilgili yük sorunları yaşıyorum ve biraz deneyimli bir Linux yöneticisi olmama rağmen şu anda fikirlerim bitti.

Sorun, belirgin bir neden olmadan sunucuda yavaş ama sürekli artan bir yüktür.

Sunucu, 6GB RAM'li bir AMD Athlon (tm) 64 X2 Çift Çekirdekli İşlemci 6000+. Linux ile Debian Kararlı çalışıyor 2.6.26-2-amd64 # 1 SMP Çar 19 Ağu 22:33:18 UTC 2009 x86_64 GNU / Linux.

Sunucu temel olarak Lighttpd, birkaç FastCGI PHP işlemi ve bir MySQL veritabanı çalıştırır. Tipik web sunucusu görevleri.

CPU asla gerçekten tamamen kullanılmaz ve bellek esas olarak tamponlar ve önbellek için kullanılır. Bunlardan birinin yükü tekrar azaltıp azaltmayacağını görmek için çeşitli hizmetleri yeniden başlatmayı denedim, ancak şanssız.

Yük, CPU ve IOStat'ı gösteren grafikler:

Yani soru şu: Yavaş ama sürekli artan bir yüke ne sebep olabilir? Ve neyin sorumlu olduğunu nasıl öğrenebilirim?

Güncelleme: Söylemeyi unuttum, sunucuyu yeniden başlattığımda, yük yaklaşık 0,3 ila 0,6'ya düşecek ve önümüzdeki haftalarda tekrar yavaşça tırmanmaya başlayacak.


1
Gönderdiğiniz görüntüler artık mevcut değil. Hâlâ kopyalarınız varsa, bunları yeniden yüklemek için çekinmeyin.
Michael Hampton

Yanıtlar:


6

Her zombi işlemi yüke 1.0 ekler. Bir zombi birikimi görüyor olabilirsiniz.


Evet. " İşlem Sayısı " grafiğini kontrol edin.
Teddy

Bu doğruysa, yazmanın for N in {1..100} ; do sleep 60 & done ; exec sleep 500yüksek bir yüke neden olması için yeterli olması gerekir. Ama öyle değil. Bu komut 100 zombi üretir, ancak bilgisayarımdaki yük 1'in altında kaldı.
kasperd

5

Farklı bir soruya cevap olarak mükemmel bir ipucu buldum .

'D' durumundaki işlemleri aramak, yük eğrisindeki "adımlara" karşılık gelen bir süre beklediği görülen dört PHP işlemini gösterir:

#> ps aux | awk '$8 ~ /D/  { print $0 }'
wiki      6651  0.0  0.0      0     0 ?        D    Oct04   0:41 [php-cgi]
bugs      6731  0.0  0.0      0     0 ?        D    Oct27   0:14 [php-cgi]
manpages  7536  0.0  0.0      0     0 ?        D    Oct30   0:21 [php5-cgi]
wiki     23847  0.0  0.0      0     0 ?        D    Oct06   1:32 [php-cgi]

Sorun bunlar gibi görünüyor. Şimdi bu süreçler asılırken ve nasıl düzeltileceğini öğrenmem gerekiyor. Herkese teşekkürler.


Bu cevap sorunumu çözdü. Yük 0,5'ten 350'ye yükseldi ve yükselmeye devam etti. Silinen bir uzak klasörü okumaya çalışan zombi süreçlerinden kaynaklanıyordu.
Philippe Delteil

2

Tahminimce sunucu IO aç, belki de iotop istatistiklerini grafiklere eklemelisiniz

Sunucu yükü için bir faktör olan uygulama başına bir etkinliğiniz olup olmadığını merak ediyorum

http://rt.wiki.kernel.org/index.php/I/Otop_utility

diğer araç dstat


IOStat için de grafikler ekledim. Disk IO, yük arttıkça artmaz. Hedeflediğiniz bu mu?
Andreas Gohr

Oh ve dstat faydalı görünüyor. Bununla ilgili biraz daha okumalıyım.
Andreas Gohr

2

G / Ç olsaydı, o zaman cpu grafiklerinde iowait (pembe) görürdü.


0

Bu tür sorunlar genellikle MySQL veritabanı ve HTTP sunucusu için gerekli verileri sunmak için yeterli olmayan sabit diskten kaynaklanır. Iostat komutuna bakmalısınız


ES bana normal gözüküyor. Ve yükün neden yavaşça arttığını açıklamayacaktır.
Andreas Gohr

-1

Genel olarak, yüksek bir sunucu yüküne sahip olmak aslında kötü bir şey değildir; bu, boşta oturmamanız ve aksi halde yapabileceğinizden daha az şey yapmamanız anlamına gelir. Toplam kapasitenizin% 80-% 90'ı (bazı "patlama" odalarıyla) genellikle aranan şeydir. Mpstat ve vmstat çıktılarını kontrol etmenizi tavsiye ederim. Özellikle, vmstat'ın ilk 2 sayısı, çalışma kuyruğundaki işlemler açısından nasıl "yedeklendiğiniz" konusunda size daha anlamlı bilgiler verebilir. Vmstat çıktısının son sütunu ("wa"), G / Ç tamamlamalarını bekleyip beklemediğinizi ve ne kadar süreyle beklediğinizi söyleyebilir. Çalışma kuyruğu boyutu ve G / Ç bekleme süresi genellikle ilişkilidir. Ayrıca sar (sysstat paketinden): bir süre boyunca neler olup bittiğine dair ayrıntılı bir görünüm sağlar; kaydettiği metrikler çok ayrıntılı.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.