Kaç İçerik Bağlantısı Şalteri “normal” (CPU çekirdeğinin (ya da diğerlerinin) bir fonksiyonu olarak)?


34

Merhaba Linux / UNIX Overlords,

Bir Linux sunucusunda kaç tane işlemci anahtarı (işlemci çekirdeği başına) Normal olduğuna dair bir kuralınız var mı?

Buradaki üniversitem ortaya çıkardı ve 8 çekirdekli bir x86_64makinede 16 bin görüyor .

İşte son birkaç gündür sarface istatistikleri.

alt metin http://src.autonomy.net.au/imagebin/81895e338fae67d3d205c09db44a81e6-Picture_10.png

İşlem oluşturma istatistiklerini görmek için, işte aynı grafiğin logaritmik bir görünümü ...

alt metin http://src.autonomy.net.au/imagebin/7481f7e52bead4effc90248fc23c72fe-Picture_11.png

Ve 8 çekirdekten ölmek için sıkıldım ...

alt metin http://src.autonomy.net.au/imagebin/0e94326652e977fd74edcd840f94200f-Picture_12.png

CS vs IOwait (x10000 ölçeği)

alt metin http://src.autonomy.net.au/imagebin/a52a2a8a120394849c0da4045933e306-Picture_13.png

Birisi sorarsa daha yararsız bilgi ..

  • Sunucunun üzerinde çalıştığı depolama FC üzerinden 0.5 TB SAN'tır.
  • 8GB RAM var, çoğunlukla önbellek - değişim yok.

1
Belirli bir dönemde?
dmckee

İş yükü hakkında daha spesifik olabilir misiniz?
dmo

1
Bu grafiği nasıl yaptın? Gerçekten çok hoş görünüyor!
Antoine Benkemoun

Merhaba Antoine - Grafikler sarface'den yapılmıştır ( projects.autonomy.net.au/sarface )
Xerxes

Grafik bağlantıları şu an için ölü. @Xerxes oradan bir yerden alabilir misin?
törzsmókus

Yanıtlar:


25

Bu, çalıştırdığınız uygulamanın türüne çok bağlıdır. Çok tetikleyici mutlu WRT sistemlerine sahip uygulamalarınız varsa, yüksek miktarda içerik değiştirmeyi görmeyi bekleyebilirsiniz. Uygulamalarınızın çoğu boşta durursa ve yalnızca bir sokette bir şeyler olduğunda uyanırsanız, düşük bağlam geçiş hızları görmeyi bekleyebilirsiniz.

Sistem çağrıları

Sistem çağrıları, bağlam anahtarlarına kendi doğası gereği neden olur. Bir süreç bir sistem çağrısı yaptığında, temel olarak çekirdeğe, işlemin ayrıcalıklı olmadığı şeyleri yapması için o andaki zamanından ve belleğinden devralmasını ve yapıldığında aynı noktaya geri dönmesini söyler.

Yazma (2) sisteminin Linux'tan tanımına baktığımızda, bu çok açık bir şekilde ortaya çıkıyor:

ADI
       write - bir dosya tanıtıcısına yaz

ÖZET
       #Dahil etmek 

       ssize_t write (int fd, const void * buf, size_t sayısı);

AÇIKLAMA
       write (), dosyaya sivri uçlu bellekten bayt saymaya kadar yazar
       dosya tanıtıcısı fd. [..]

GERİ DÖNÜŞ DEĞERİ
       Başarı durumunda, yazılan bayt sayısı döndürülür (sıfır
       hiçbir şey yazılmadı). Hata durumunda, -1 döndürülür ve errno ayarlanır
       uygun şekilde.
       [..]

Bu, temel olarak çekirdeğe, işlemden işlemi devralmasını, countbaytlara gitmesini , işaret ettiği bellek adresinden başlayarak mevcut işlemin *bufdosya tanımlayıcısını fdbildirmesini ve ardından işleme geri dönmesini ve ona nasıl gittiğini anlatmasını söyler.

Bunu göstermek için güzel bir örnek Valve Source tabanlı oyunlar hlds için özel oyun sunucusu . http://nopaste.narf.at/f1b22dbc9 , üzerinde hiçbir oynatıcısı olmayan tek bir oyun sunucusu örneği tarafından yapılan bir saniyelik sistem çağrılarını gösterir. Bu işlem bir Xeon X3220'de (2.4Ghz) yaklaşık% 3 CPU süresi alıyor ve bu size bunun ne kadar pahalı olduğu konusunda bir fikir veriyor.

Çok Amaçlı

Başka bir bağlam değiştirme kaynağı, sistem çağrısı yapmayan, ancak diğer işlemlere yer açmak için verilen bir CPU'dan ayrılması gereken işlemler olabilir.

Bunu görselleştirmenin güzel bir yolu cpuburn . cpuburn herhangi bir sistem çağrısı yapmaz, sadece kendi hafızası üzerinde yinelenir, bu nedenle herhangi bir bağlam değişimine neden olmamalıdır.

Boşta bir makine alın, vmstat'ı başlatın ve daha sonra sistemin sahip olduğu her CPU çekirdeği için bir burnMMX (veya cpuburn paketinden farklı bir test) çalıştırın. O zamana kadar tam sistem kullanımına sahip olmanız gerekir, ancak içerik bağlamında herhangi bir artış olmaz. Sonra birkaç işlem daha başlatmaya çalışın. İşlemler CPU çekirdeği üzerinde rekabet etmeye başladığında içerik değiştirme oranının arttığını göreceksiniz. Geçiş miktarı, işlem / çekirdek oranına ve çekirdeğinizin çoklu görev çözünürlüğüne bağlıdır.

daha fazla okuma

linfo.org, bağlam anahtarlarının ve sistem çağrılarının ne olduğuna dair güzel bir yazı yazıyor . Wikipedia genel bilgiler ve Sistem aramalarında hoş bir bağlantı koleksiyonuna sahiptir.


1
Bu faydalı oldu - bana harika bir fikir verdin! =)
Xerxes

1
İfadende System calls cause context switches by their very own natureyanlış geliyor. Sistem çağrıları, linfo.org/context_switch.html
Nicolas

6

orta derecede yüklü web sunucum, saniyede 100-150 anahtar değerinde oturuyor ve çoğu zaman tepe noktalarla birlikte binlerce.

Yüksek bağlamda değişim oranları kendileri bir sorun değildir, ancak daha önemli bir soruna yol açabilir.

düzenleme: Bağlam anahtarları bir neden değil, bir belirtidir. Sunucuda ne çalıştırmaya çalışıyorsunuz? Çok işlemcili bir makineniz varsa, ana sunucu işlemleriniz için cpu benzeşimi ayarlamayı denemek isteyebilirsiniz.

Alternatif olarak, eğer X kullanıyorsanız, konsol moduna geçmeyi deneyin.

tekrar düzenleme: saniyede 16k cs'de, her cpu milisaniyede iki anahtarın ortalamasıdır - normal zaman diliminin yarısı ile altıda birinde. Bir sürü IO bağlı iplik çalıştırıyor olabilir mi?

yeniden düzenleme sonrası grafikleri: Kesinlikle görünüyor IO bağlı. bağlamı yüksekken sistem zamanının çoğunu SYS'de geçiriyor mu?

bir kez daha düzenleyin: Bu son grafikteki yüksek iowait ve sistem - tamamen kullanıcı alanını gizliyor. G / Ç probleminiz var.
Hangi FC kartını kullanıyorsunuz?

düzenleme: hmmm. SAN erişiminiz sırasında bonnie ++ veya dbench ile bazı ölçütler alma şansınız var mı? Benzer sonuçları olup olmadığını görmek isterim.

düzenleme: Bu hafta sonu boyunca düşündüm ve bonnie "bir seferde bir bayt yazmak" geçerken yaparken benzer kullanım patters gördüm. Bu, her bir yazma için ayrı bir sistem çağrısı gerektireceğinden, büyük miktarda geçiş yapıldığını açıklayabilir.


Hala yüksek bir içerik-değişim oranının bir sorun olmadığı konusunda ikna olmadım, 100-150'den değil, 4K'dan 16K'ya kadar yüksek olduğundan bahsediyorum.
Xerxes

Sunucularımızdan hiçbiri X kullanmıyor. IO bekleme probleminde sizinle aynı fikirdeyim ve bununla CS arasındaki ilişki. HBA kartı şüpheli değil, çünkü aynı kartı diğer yüzlerce sunucuda kullanıyoruz ... Sonuç olarak, SAN ekiplerini EVA SAN'ı her zaman umutsuzca denedikleri ve savunmaya zorladıkları için suçluyorum. Yüksek bir IO-bekleyişinin her zaman alarm verilmesi gerekmediğine dikkat edin, bir makinedeki işlemlerin çoğu IO'ya bağlıysa, sunucunun bu boşta dönüşleri yapacak daha iyi bir şeyi olmaması beklenir.
Xerxes

İkinci olarak - ekli 4. grafik, ilk başta düşündüğüm kadar yakın olmadığını gösteriyor. Tam olarak bir tutulma değil. Yine de SAN'ı suçluyorum. =)
Xerxes

1

Sistem durumunun CPU doluluk oranı hakkında endişelenmeye daha meyilliyim. % 10 veya daha yüksekse, işletim sisteminizin bağlam anahtarlarını yapmak için çok fazla zaman harcadığı anlamına gelir. Bazı işlemleri başka bir makineye taşımak çok daha yavaş olsa da, bunu hak eder.


1

Bunun gibi şeyler, sunucularınız için performans taban çizgilerini denemelisiniz. Bu şekilde, aniden fark ettiğiniz şeyleri geçmişte kaydettiğiniz şeylerle karşılaştırabilirsiniz.

Bu, bazı 4k zirveleri ile 2k civarında sabit çalışan sunucularım (çoğunlukla çok yoğun olmayan Oracle sunucuları). Sunucularım için bu normaldir, başkalarının sunucuları için çok düşük veya çok yüksek olabilir.

Verilerinize ne kadar geri gidebilirsiniz?

Bize ne tür CPU bilgileri verebilirsin?


Temelde kalmaya kesinlikle katılıyorum ve uzun süredir geri dönen nagios verilerimiz var - bu sunucunun sorunu yeni kan olması - kısa bir süredir buralarda. Buna ek olarak, tanımsız değişken listesine eklemek için kurumsal (okuma: bok) yazılımı - Teamsite - çalışıyor. Hala sar'yı (kişisel tercihi) tercih ediyorum, bu yüzden onu varsayılandan (2 hafta) daha fazla tutacak şekilde ayarlayacağım ve nasıl geçtiğini göreceğim.
Xerxes

Sar'ı rrdtool ile birlikte kullanmak (grafiklerinizden geliyor gibi görünüyor) verilerinizi (veya en azından özetlerini) uzun süre saklamak için kolay bir yol olabilir.
wzzrd

0

Hiçbir kural yok. Bir içerik anahtarı, sadece bir iş parçacığını işlemek diğerine hareket eden CPU'dur. Çok fazla işlem çalıştırırsanız (veya birkaç tane yüksek dişli işlemi gerçekleştirirseniz) daha fazla anahtar görürsünüz. Neyse ki, kaç tane bağlam anahtarının var olduğu konusunda endişelenmenize gerek yok - maliyet az ve kaçınılmazdır.


6
Aslında bir bağlam anahtarının maliyeti pahalıdır . Bu, Sanal makinelerde daha da kötü - birkaç ay önce VM performansının en büyük nedenlerinden birinin bağlam değiştirme olduğunu gösteren bazı testler yaptık.
Xerxes

Aslında, herhangi bir modern (çoklu görev) işletim sisteminde, bağlam değişiminin en aza indirilmesi çok önemli bir optimizasyon görevidir. Maliyetin küçük olduğu iddiasını destekleyecek herhangi bir kaynağınız var mı?
Xerxes

Maalesef, bağlam anahtarlarının işletim sistemi gelişimi açısından en aza indirilmesinden mi bahsediyorsunuz? Böyle bir geliştirmeyle ilgisi olmayan CS'yi en aza indirecek bir sistem tasarlamanın faydaları hakkında hiçbir fikrim yok :) Bir sunucudaki bağlam anahtarlarının en aza indirilmesi hakkında konuşuyorsanız, sorun, bağlam anahtarlarının başka yerlerde gecikmeyi de beraberinde getirmesidir. Bir makinedeki işlem sayısını azaltan EG, bu işlemleri başka bir makineye taşımanız gerektiği anlamına gelir; bu, iletişimin bir ağ üzerinden gerçekleşmesi anlamına gelir; bu, çok daha yavaştır!
Alex J

Bağlam anahtarları tanımınızın hatalı olduğuna inanıyorum; aynı konuya geri dönseler bile, bir sistem çağrısı yapıldığında da olurlar. Uygulamalar çeşitli hileler yaparak buna karşı optimize eder. Örneğin Apache'nin sistem zamanını çok sık alması gerekiyor; bu amaç için bir iş parçacığı defalarca yerel arama yapar ve sonucu paylaşılan hafızaya kaydeder. Diğer dişler sadece RAM'den okumak zorundadır ve bunu yaparken bir işlem anahtarına maruz kalmazlar.
niXar
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.