Çalma Süresini İzleme Araçları (st)


12

Teorik olarak sunucudaki tek kişi olduğumuz anlamına gelen sanal bir "özel" sunucu üzerinde çalışıyoruz. Uygulamada .... Olmayacağımızı düşünüyorum.

resim açıklamasını buraya girin

Makinemizi öldürüyor gibi görünsek de, "Çalma zamanı" nın% 71

Yükle ilgili istatistikleri alıyorum ve bu statün grafiklerimde görünmediğinden hayal kırıklığına uğradım. Bunu izleyen ve yardımcı olabilecek araçlar var mı?


Ek bilgi:

4 çekirdek çalıştırıyoruz, model:

# grep "model name" /proc/cpuinfo | sort -u
model name  : Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz

1
Sanal adanmış mı? XEN durumunda, VM'nizde özel kullanım için özel çekirdekleri sabitlemeleri gerekir. Sağlayıcınızın adil olmayan bir işlemle CPU'lara çifte rezervasyon yaptırdığı anlaşılıyor. Buna ne diyor?
Nils

1
Kaç tane vCPU'nuz var ve ne tür CPU rapor ediliyor grep "model name" /proc/cpuinfo|sort -u? Bu gerçekten adanmış bir sunucu varsa o zaman Dom0 CPU zamanı yiyor bir şey var. VEYA size Dom0'da bulunandan daha fazla vCPU verdiler.
Nils

1
Bu anlık bir aykırı değilse, isp'niz size yalan söylüyor gibi görünüyor ve aslında, bu makinede diğer cpu ağır vms çalıştırıyorlar veya dom0'ın çok fazla cpu zamanı tutmasına neden olan çok yanlış yapılandırılmış bir şey var .
Haziran'da psusi

1
SuSE, diğer sanal makineleri rahatsız etmeden tüm IO işlemlerini yapabilmesi için yalnızca Dom0 için iki çekirdeğin ayrılmasını önerir. Benim gözümde bu sadece DomU'larda çalınan sistemler ve ağır IO trafiği için gerekli olurdu. Sağlayıcınızın mantıksal çekirdeklerden daha fazla vCPU tahsis edip etmediğini bilmek istedim - Dom0'da sadece 2 mantıksal CPU mevcutken - bu da "çalındı" yı açıklayacaktır (ve oldukça cesur bir fikir - ama XEN'de mümkün) .
Nils

1
Bunun temel nedeni, ISS'nin VM'yi yanlış yapılandırmış olduğu ortaya çıktı. Konuk aslında yaptığı daha fazla çekirdek vardı söylendi. Bu, programlamaya zarar veriyor gibi görünüyordu. ISS akıllı teknik destek sağlayamadı, ancak / proc içindeki tek sayılı çekirdekleri devre dışı bırakarak sorunu "kanıtlayabildik". Asla sorun değil o zamandan beri.
mgjk

Yanıtlar:


12

Sorunuz iyi tanımlanmış, ancak ortamınız, şu anda nasıl izlediğiniz veya hangi grafik araçlarını kullandığınız hakkında çok fazla bilgi vermiyorsunuz. Bununla birlikte, SNMP'nin hemen hemen evrensel olarak kullanıldığı göz önüne alındığında, onu kullandığınızı ve en azından biraz aşina olduğunuzu varsayacağım.

Her ne kadar (anlatabildiğim kadarıyla) CPU Çalma süresi snmpd'de mevcut olmasa da, UCD-SNMP-MIB::extOutputnesneyle ve execkomutlarla kendiniz uzatabilirsiniz .

Çalma zamanını almanın en kolay yolu (bulduğum) iostat. Aşağıdaki yapıyı kullanarak sadece çalma süresini elde edebiliriz :

$ iostat -c | awk 'NR==4 {print $5}'
0.00

Bu nedenle, snmpd.conf dosyasına aşağıdakileri ekleyin:

exec cpu_steal_time /usr/bin/iostat -c | /usr/bin/awk 'NR==4 {print $5}'

(Alternatif olarak komutu bir sarıcı komut dosyasına koyabilir ve sarıcıyı içeriden çağırabilirsiniz snmpd.conf.)

Her execçağrı snmpd.conf1'den başlayarak dizine eklenir. Dolayısıyla, yalnızca tek bir exec deyiminiz varsa, yoklamak istersiniz UCD-SNMP-MIB::extOutput.1. Bu 5. yürütme ifadesi ise anket UCD-SNMP-MIB::extOutput.5vb.

Sayısal OID UCD-SNMP-MIB::extOutputdeğeri, .1.3.6.1.4.1.2021.8.1.101eğer dizin 1'deyseniz .1.3.6.1.4.1.2021.8.1.101.1ve dizin 5 ise .1.3.6.1.4.1.2021.8.1.101.5vb. Olacaktır.

Daha sonra 0-100 arasında bir tür ölçer SNMPD OID olan bir grafik yoklaması oluşturun. Bu size bazı güzel grafikler vermelidir.


Mükemmel cevap. Bu statik ne sıklıkla toplanacak? Anket sırasında ya da RMON-MIB'de dış anket olmadan değerleri kaydedecek bir yol var mı?
Nils

Bu snmpdOID için her sorgulandığında bunu çekeceğine inanıyorum .
Bahama

İostat kurulu değilse: top -bn1 | sed -nr '3s /.*,// gp'
davide

9

sar -usizin durumunuzda yardımcı olabilir. sar normalde sysstat paketinin bir parçasıdır .


Keşke kabul edilen cevap olarak birden fazla cevap verebilsem. Her iki cevap da çok faydalı oldu :-) Teşekkürler!
mgjk

0

En çok oylanan cevap harika, ama şu anda tam olarak çalışmıyor: net-snmp çağrıdaki boruyu kaybediyor exec, bu yüzden bu böyle görünmeli

extend-sh cpu_steal_time /usr/bin/iostat -c 1 1 | /usr/bin/awk '!/%user|Linux|^$/ {print $5}'

Ve sonuç aşağıda görülebilir nsExtendOutput1Table:

# snmpwalk localhost NET-SNMP-EXTEND-MIB::nsExtendOutput1Table
NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."cpu_steal_time" = STRING: 0.60
NET-SNMP-EXTEND-MIB::nsExtendOutputFull."cpu_steal_time" = STRING: 0.60
NET-SNMP-EXTEND-MIB::nsExtendOutNumLines."cpu_steal_time" = INTEGER: 1
NET-SNMP-EXTEND-MIB::nsExtendResult."cpu_steal_time" = INTEGER: 0

burada nsExtendOutput1Lineoid .1.3.6.1.4.1.8072.1.3.2.3.1.1:

snmpwalk localhost .1.3.6.1.4.1.8072.1.3.2.3.1.1
NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."cpu_steal_time" = STRING: 0.60
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.