Frage Wie viele Kontextschalter sind "normal" (abhängig von CPU-Kernen (oder anderen))?


Hallo Linux / UNIX Overlords,

Hat jemand von euch eine Faustregel, wie viele Kontextwechsel (pro Prozessorkern) es gibt? Normal auf einem Linux-Server?

Mein College hier brachte es auf, und er sieht 16K auf einem 8-Kern x86_64 Maschine.

Hier sind einige Statistiken von sarface in den letzten Tagen ...

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

Und um die Prozesserstellungsstatistiken zu sehen, hier ist eine logarithmische Ansicht derselben Grafik ...

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

Und die 8 Kerne sind zu Tode gelangweilt ...

alt text http://src.autonomy.net.au/imagebin/0e94326652e977fd74edcd840f94200f-Bild_12.png

CS vs IOwait (x10000 Skala)

alt text http://src.autonomy.net.au/imagebin/a52a2a8a120394849c0da4045933e306-Bild_13.png

Mehr nutzlose Informationen, falls jemand fragt ..

  • Der Speicher, auf dem der Server arbeitet, ist ein 0,5 TB SAN über FC
  • Es gibt 8 GB RAM, meist Cache - kein Swapping.

32
2018-05-29 01:45


Ursprung


In irgendeinem bestimmten Zeitraum? - dmckee
Können Sie sich genauer mit der Arbeitsbelastung befassen? - dmo
Wie hast du diese Grafik gemacht? Sieht wirklich gut aus! - Antoine Benkemoun
Hallo Antoine - Die Graphen sind aus Sarface (projects.autonomy.net.au/sarface) - Xerxes


Antworten:


Dies hängt sehr stark von der Art der Anwendung ab, die Sie ausführen. Wenn Sie Anwendungen haben, die sehr Trigger-glücklich WRT syscalls sind, können Sie erwarten, dass große Mengen von Kontextwechsel zu sehen. Wenn die meisten Ihrer Anwendungen im Leerlauf sind und nur aufwachen, wenn auf einem Socket etwas passiert, können Sie davon ausgehen, dass die Kontextwechselraten niedrig sind.

Systemaufrufe

Systemaufrufe verursachen Kontextwechsel aufgrund ihrer eigenen Natur. Wenn ein Prozess einen Systemaufruf ausführt, teilt er dem Kernel im Grunde mit, dass er den aktuellen Zeitpunkt und Speicher übernimmt, um Dinge zu tun, für die der Prozess nicht privilegiert ist, und an dieselbe Stelle zurückzukehren, wenn er fertig ist.

Wenn wir uns die Definition des write (2) syscall von Linux anschauen, wird dies sehr deutlich:

NAME
       Schreiben - Schreiben in einen Dateideskriptor

ZUSAMMENFASSUNG
       #umfassen

       ssize_t write (int fd, const void * buf, size_t count);

BESCHREIBUNG
       write () schreibt bis zum Zählen von Bytes von dem Puffer, der auf die Datei gepuffert ist
       mit dem Dateideskriptor fd bezeichnet. [..]

RÜCKGABEWERT
       Bei Erfolg wird die Anzahl der geschriebenen Bytes zurückgegeben (Null zeigt an
       nichts wurde geschrieben). Bei einem Fehler wird -1 zurückgegeben und errno wird gesetzt
       passend.
       [..]

Dies teilt dem Kernel im Prinzip mit, dass er die Operation aus dem Prozess übernehmen und nach oben gehen muss count Bytes, ausgehend von der Speicheradresse, auf die von gezeigt wird *buf zum Dateideskriptor fd des laufenden Prozesses und dann zurück zu dem Prozess und sagen ihm, wie es ging.

Ein schönes Beispiel dafür ist der dedizierte Spieleserver für Valve Source basierte Spiele, hlds. http://nopaste.narf.at/f1b22dbc9 zeigt eine Sekunde an Systemaufrufen, die von einer einzigen Instanz eines Spieleservers durchgeführt wurden, auf dem sich keine Spieler befanden. Dieser Prozess benötigt ungefähr 3% CPU-Zeit auf einem Xeon X3220 (2.4Ghz), nur um Ihnen ein Gefühl dafür zu geben, wie teuer das ist.

Multitasking

Eine andere Quelle für den Kontextwechsel können Prozesse sein, die keine Syscalls ausführen, sondern von einer bestimmten CPU verschoben werden müssen, um Platz für andere Prozesse zu schaffen.

Ein schöner Weg, dies zu visualisieren ist cpuburn. cpuburn syscalliert sich selbst nicht, es iteriert nur über seinen eigenen Speicher, so dass es keinen Kontextwechsel verursachen sollte.

Nehmen Sie eine leere Maschine, starten Sie vmstat und führen Sie dann für jeden CPU-Kern, den das System hat, einen burnMMX (oder einen anderen Test aus dem cpuburn-Paket) aus. Bis zu diesem Zeitpunkt sollten Sie eine volle Systemauslastung haben, aber kaum einen erhöhten Kontextwechsel. Versuchen Sie dann, ein paar weitere Prozesse zu starten. Sie werden feststellen, dass die Kontextwechselrate zunimmt, wenn die Prozesse über CPU-Kerne konkurrieren. Die Höhe der Umschaltung hängt vom Prozess / Kern-Verhältnis und der Multitasking-Auflösung Ihres Kernels ab.

Weiterführende Literatur

linfo.org hat eine nette Beschreibung auf was Kontextwechsel und Systemaufrufe sind. Wikipedia hat allgemeine Informationen und eine nette Linksammlung zu Systemaufrufen.


24
2018-05-31 02:58



Das war nützlich - du hast mir eine großartige Idee gegeben! =) - Xerxes
Deine Meinung System calls cause context switches by their very own nature scheint falsch zu sein. Systemanrufe verursachen einen Moduswechsel wie von angegeben linfo.org/context_switch.html - Nicolas Labrot


Mein mäßig geladener Webserver sitzt die meiste Zeit bei etwa 100-150 Switches mit Spitzen in die Tausende.

Hohe Kontextwechselraten sind selbst kein Problem, aber sie können den Weg zu einem signifikanteren Problem weisen.

edit: Kontextwechsel sind ein Symptom, keine Ursache. Was versuchen Sie auf dem Server auszuführen? Wenn Sie über einen Multiprozessorcomputer verfügen, sollten Sie versuchen, die CPU-Affinität für Ihre Hauptserverprozesse festzulegen.

Wenn Sie X verwenden, sollten Sie versuchen, in den Konsolenmodus zu wechseln.

bearbeite noch einmal: bei 16k cs pro Sekunde zählt jede CPU durchschnittlich zwei schalter pro Millisekunde - das ist die Hälfte bis ein Sechstel des normalen Zeitfensters. Könnte er eine Menge IO-gebundene Threads ausführen?

Bearbeiten Sie die Diagramme erneut: Sicherlich sieht IO gebunden aus. verbringt das System die meiste Zeit in SYS, wenn die Kontextwechsel hoch sind?

editieren Sie noch einmal: High Iowait und System in diesem letzten Graphen - vollständig überdecken den Benutzerraum. Sie haben E / A-Probleme.
Welche FC Karte verwendest du?

editieren: hmmm. Sie haben die Möglichkeit, während der Deadtime mit bonnie ++ oder dbench einige Benchmarks für Ihren SAN-Zugriff zu erhalten? Ich wäre daran interessiert zu sehen, ob sie ähnliche Ergebnisse haben.

edit: Ich habe über das Wochenende darüber nachgedacht und ähnliche Usage-Muster gesehen, als Bonnie den "write byte by a time" -Pass macht. Das erklärt möglicherweise die große Menge an Switching, da jeder Schreibvorgang einen separaten Systemaufruf erfordert.


6
2018-05-29 04:39



Ich bin immer noch nicht davon überzeugt, dass eine hohe Kontextwechselrate kein Problem ist, ich spreche von High als in 4K bis 16K, nicht 100-150. - Xerxes
Keiner unserer Server führt ein X aus. Ich stimme Ihnen mit dem IO-Warteproblem und der Beziehung zwischen diesem und dem CS zu. Die HBA-Karte ist jedoch kein Verdächtiger, weil wir die gleiche Karte auf den anderen hundert oder so Servern verwenden ... Fazit ist, dass ich den beschissenen EVA SAN der SAN-Teams die Schuld gebe, die sie verzweifelt versuchen, die ganze Zeit zu verteidigen. Beachten Sie, dass eine hohe IO-Wartezeit nicht gilt immer Grund zur Beunruhigung, wenn die meisten Prozesse auf einer Maschine IO-gebunden sind, wird erwartet, dass der Server nichts besseres zu tun hat, als Leerlaufspins. - Xerxes
Auf der zweiten Seite - das vierte Diagramm zeigt, dass es nicht wirklich so nah ist, wie ich es zuerst getan habe. Nicht unbedingt eine Sonnenfinsternis. Ich gebe dem SAN trotzdem die Schuld. =) - Xerxes


Ich bin eher geneigt, mich um die CPU-Belegungsrate des Systemzustands zu kümmern. Wenn es in der Nähe von 10% oder höher ist, bedeutet dies, dass Ihr Betriebssystem zu viel Zeit damit verbringt, die Kontextwechsel durchzuführen. Obwohl einige Prozesse auf einen anderen Rechner verschoben werden viel langsamer, es verdient es, dies zu tun.


1
2018-05-29 06:23





Es gibt keine Faustregel. Ein Kontextwechsel ist nur die CPU, die sich von der Verarbeitung eines Threads zu einem anderen bewegt. Wenn Sie viele Prozesse ausführen (oder ein paar stark mit Threads), werden Sie mehr Optionen sehen. Glücklicherweise müssen Sie sich keine Gedanken darüber machen, wie viele Kontextwechsel es gibt - die Kosten sind gering und mehr oder weniger unvermeidbar.


0
2018-05-29 02:02



Tatsächlich sind die Kosten für einen Kontextwechsel teuer. Dies ist sogar am schlimmsten bei virtuellen Maschinen - vor ein paar Monaten haben wir einige Tests durchgeführt, die gezeigt haben, dass einer der größten Gründe für die VM-Leistung der Kontextwechsel war. - Xerxes
Tatsächlich ist in jedem modernen (Multitasking-) Betriebssystem die Minimierung des Kontextwechsels eine sehr wichtige Optimierungsaufgabe. Haben Sie Quellen, die Ihre Behauptung stützen, dass die Kosten gering sind? - Xerxes
Entschuldige, sprichst du über die Minimierung von Kontextwechsel aus der Perspektive der OS-Entwicklung? Da ich mit einer solchen Entwicklung nichts zu tun habe, habe ich keine Meinung über die Vorteile des Entwerfens eines Systems zum Minimieren von CS :) Wenn Sie über das Minimieren von Kontextwechsel auf einem Server sprechen, besteht das Problem darin, Latenzen an anderen Stellen zu reduzieren. Wenn Sie beispielsweise die Anzahl der Prozesse auf einer Maschine reduzieren, müssen Sie diese Prozesse auf eine andere Maschine verschieben, was bedeutet, dass die Kommunikation über ein Netzwerk erfolgt viel Langsamer! - Alex J
Ich glaube, Ihre Definition von Kontextwechsel ist fehlerhaft; Sie treten auch auf, wenn ein Systemaufruf ausgeführt wird, selbst wenn er zum selben Thread zurückkehrt. Anwendungen optimieren sich dagegen durch verschiedene Tricks. Zum Beispiel muss Apache sehr oft Systemzeit bekommen; Zu diesem Zweck ruft ein Thread wiederholt localtime auf und speichert das Ergebnis im Shared Memory. Die anderen Threads müssen nur aus dem RAM lesen und müssen dabei keinen Prozesswechsel vornehmen. - niXar


Aus diesem Grund sollten Sie versuchen, die Leistungsbasislinien für Ihre Server beizubehalten. Auf diese Weise können Sie Dinge, die Sie plötzlich bemerken, mit Dingen vergleichen, die Sie in der Vergangenheit aufgezeichnet haben.

Das heißt, ich habe Server laufen (nicht sehr beschäftigt Oracle-Servern, vor allem), die stabil sind rund 2k mit einigen 4k Spitzen. Für meine Server ist das normal, für die Server anderer Leute, die viel zu niedrig oder zu hoch sind.

Wie weit können Sie Ihre Daten zurückverfolgen?

Welche Art von CPU-Informationen können Sie uns geben?


0
2018-05-29 08:17



Ich stimme definitiv einer Baseline zu, und wir haben Nagios-Daten für längere Zeit zurück - das Problem mit diesem Server ist, dass es neues Blut ist - nur für eine kurze Zeit. Darüber hinaus wird die Enterprise (Read: Crap) Software - Teamsite - ausgeführt, die nur zur undefinierten Variablenliste hinzugefügt wird. Ich bevorzuge immer noch sar (persönliche Präferenz), also werde ich es konfigurieren, um mehr als die Standard (2-Wochen) zu halten, und sehen, wie es geht. - Xerxes
Die Verwendung von sar in Kombination mit rrdtool (aus der Ihre Diagramme stammen könnten) kann eine einfache Möglichkeit sein, Ihre Daten (oder zumindest Abstracts davon) lange Zeit zu speichern. - wzzrd