Yüksek CPU kullanımı apache işleminin gerçekte ne yaptığını öğrenin?


18

Şu anda sunucumuzla birkaç sorun yaşıyoruz, aralıklı olarak% 100 CPU alarak sadece çalışan ve çalışan apache süreçleri alıyoruz.

Üstte koşarken aşağıdakileri görüyoruz:

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
20788 www-data  20   0  318m  18m 3984 R  100  0.0  40:29.21 /usr/sbin/apache2 -k start
23523 www-data  20   0  319m  20m 4684 R  100  0.0   4:12.36 /usr/sbin/apache2 -k start

Denemek ve buna neden olan komut dosyası (ya da ne olursa olsun) bulmak istiyorum, bu yüzden denedim:

 strace -p 20788

Ama bu hiç bir çıktı göstermiyor (yaklaşık 10 dakika bıraktım ve hiçbir şey göstermiyor). Anladığım kadarıyla, bu sonsuz bir döngüde sıkıştığı anlamına gelebilir ve gösterilecek herhangi bir "sistem çağrısı" yoktur.

Neler olduğunu göstermek için yapabileceğim başka bir şey var mı?

Teşekkürler

Edit - Bahsetmeyi unuttum, bu herhangi bir zamanda birkaç yüz kullanıcısı olan canlı bir sunucudur! Bu yüzden, yapılandırma seçeneklerini değiştirmeyi gerçekten deneyemiyorum ve apache'yi yeniden başlatamıyorum.

Edit 2 - gdb backtrace (bt) PHP --enable-debug ile yapılandırılmadığında yararlı görünmüyor - sadece "execute ()" gösterir, ama PHP betiğinin ne olduğunu bilmeliyim aslında çalışıyor .. başka yolu var mı?

#0  0x00007f6c143fb0c5 in ?? () from /usr/lib/apache2/modules/libphp5.so
#1  0x00007f6c143b040b in execute () from /usr/lib/apache2/modules/libphp5.so
#2  0x00007f6c1438b970 in zend_execute_scripts () from     /usr/lib/apache2/modules/libphp5.so
#3  0x00007f6c14337fe3 in php_execute_script () from     /usr/lib/apache2/modules/libphp5.so
#4  0x00007f6c1441ae7d in ?? () from /usr/lib/apache2/modules/libphp5.so
#5  0x00007f6c18912508 in ap_run_handler ()
#6  0x00007f6c1891297e in ap_invoke_handler ()
#7  0x00007f6c18922570 in ap_process_request ()
#8  0x00007f6c1891f398 in ?? ()
#9  0x00007f6c18918fa8 in ap_run_process_connection ()
#10 0x00007f6c189271d0 in ?? ()
#11 0x00007f6c1892793a in ?? ()
#12 0x00007f6c189284e7 in ap_mpm_run ()
#13 0x00007f6c188fd4a4 in main ()

1
Apache "zarif" yeniden başlatmayı destekler, neden olmasın?
poige

1
Ben daha önce denediğimizde, "sıkışmış" apache süreçleri nedeniyle zarif bir şekilde yeniden başlatılamadı düşünüyorum ... Bu yanlış olsa da, bir süre önceydi.
BT643 13.03.2013

Başka bir hile, farklı bağlantı noktasında başka bir apache örneği çalıştırmak ve ona yeni bağlantıları yönlendirmektir .
poige

Yanıtlar:


9

Cesur hissediyorsanız:

gdb -p 20788

sonra btyığın çerçevesini görmek için sorun , örneğin

Ve BTW, ayrıca ltracebahsedilecek - bunu da deneyin.

UPD. : Peki, tamam, şimdi Apache'nin gerçekten bir şey çalıştırdığına dair bir fikrimiz var, neden mod_statusçıktıya bakmıyorsunuz - Genişletilmiş olan?


gdb kurulu değil :( herhangi bir soruna neden olmadan yükleyebileceğimi görmek için yarın işe geri dönene kadar beklemek zorunda kalacak .. ltraceherhangi bir çıktı da göstermedi.
BT643

Sadece gdb bt sonuçları ilk yazıya ekledi .. gerçekten bana çok fazla şey söylemiyor!
BT643

Oh, doğru yönü önerdiğimi gördüğüme sevindim. )
poige

@ BT643, bkz. UPD.
poige

4
Gerçekleştirilmiş mod_status varsayılan olarak zaten etkinleştirildi, sadece 127.0.0.1'den erişim ile sınırlıydı. Az önce SSH ile giriş yaptım ve çıktıyı bir dosyaya aktardım curl domain.com/server-status > randomfile.html- sonra dosyayı gördüm . Bir döngü (PHP dosyası) içinde sıkışıp eski bir geliştirici kodu olduğu ortaya çıktı! Hepsi sıralandı. Yardımın için teşekkürler :)
BT643

2

Çok kolay bir yaklaşım kullanmaktır htop. Yüksek CPU işlemleri için sıralama yapabilir ve ardından

  • için s stracebir yöntem
  • l lsofbir süreçlerin açık dosyaları görmek için
  • L'ye ltrace.

Bu seçeneklerden en az birinin yükü oluşturan komut dosyasını bulduğunu ve elbette bunu bir üretim web sunucusunda hata ayıklamak için kullanabileceğinizi buldum.


1

Deneyebilirsiniz:

  • iotop (sistemde G / Ç gösteriliyor)
  • netstat -t (bağlantıları gösteriyor)
  • Apache günlük dosyalarına bir göz atın ve sunucunun en son ne yaptığını öğrenin
  • apache işlemi için bazı RLimits ayarları. Bu sınırlara ulaşıldığında, işlem biraz daha bilgi vererek öldürülecek

0

Komutunuz, bu PID'yi tetikleyen bir HTTP isteği yapmanız koşuluyla çalışmalıdır.

Belki de Apache'yi sadece bir alt süreçle geçici olarak yeniden yapılandırmak istersiniz?


Yalnızca bir alt işlemin Apache'nin yalnızca tek bir istekte bulunabileceği anlamına geldiğini ve bu tek çocuk sıkışmışsa Apache'nin herhangi bir istekte bulunamayacağını unutmayın.
Stefan Lasiewski

Yüzlerce eşzamanlı kullanıcısı olan canlı bir sunucu olduğu için bunu yapamazsınız (bunu daha önce net olmadığı için
OP'ye eklediniz

0

Bu apache örneğinin PID'si düşük, her şeyin babası olabilir. Bu kesinlikle yüksek CPU kullanımını açıklar (etrafta kalır, diğerleri yüklenir ve yüke göre geri çağrılır). Birikmiş CPU zamanı çok uzun süredir çalıştığı anlamına gelebilir. Hiçbir çıkış strace(1)sadece sistem çağrısı yapmadığı anlamına gelir. Evet, sıkı bir döngüde olabilir, ancak apache aslında 'net üzerinden G / Ç'dir, bu yüzden yararlı bir şey yapmadığını düşünürdüm. Her durumda bir CPU'nun garip% 100'ü.


Düşük PID mutlaka eski bir süreç olduğu anlamına gelmez. PID'lerin maksimum değeri vardır ve düşük PID'ler kullanılarak yeni işlemler oluşturulabilmesi için etrafına sarın.
austinian

0

Bunu dene:

1) Tarih / saat, PHP betiği ve PID kullanarak bir günlük başlatma getmypid()

2) Ardından sunucunuzu top

3) Apache işleminin yükseldiğini gördüğünüzde, günlüklerinizde aynı tarih / saati ve PID'yi arayın. Sorunlu komut dosyasını bulabilmeniz gerekir.


Bu ilginç bir çözüm, ancak mod_statusişini oldukça iyi yaptığı göz önüne alındığında, değerinden daha fazla kaynak aldığını görebiliyorum .
austinian
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.