Combien de commutateurs de contexte sont «normaux» (en fonction des cœurs de processeur (ou autres))?

34

Salut suzerains Linux / UNIX,

L'un de vous a-t-il une règle générale quant au nombre de commutateurs de contexte (par cœur de processeur) qui est Normal sur un serveur Linux?

Mon collège ici l'a évoqué, et il voit 16K sur une x86_64machine à 8 cœurs .

Voici quelques statistiques de sarface ces derniers jours ...

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

Et pour voir les statistiques de création de processus, voici une vue logarithmique du même graphique ...

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

Et les 8 noyaux s'ennuient à mort ...

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

CS vs IOwait (échelle x10000)

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

Plus d'informations inutiles au cas où quelqu'un le demanderait.

  • Le stockage sur lequel le serveur fonctionne est un réseau SAN de 0,5 To via FC.
  • Il y a 8 Go de RAM, principalement du cache - pas de permutation.
linux performance context-switch Xerxes
la source
1
Dans une période particulière?
dmckee
Pouvez-vous être plus précis sur la charge de travail?
dmo
1
Comment as-tu créé ce graphique? Ça a l'air vraiment sympa!
Antoine Benkemoun
Bonjour Antoine - Les graphiques sont fabriqués à partir de sarface ( projects.autonomy.net.au/sarface )
Xerxès
les liens graphiques sont morts à partir de maintenant. @Xerxes pouvez-vous y arriver de quelque part?
törzsmókus

Réponses:

25

Cela dépend beaucoup du type d'application que vous exécutez. Si vous avez des applications qui sont des appels système WRT très faciles à déclencher, vous pouvez vous attendre à de grandes quantités de changements de contexte. Si la plupart de vos applications sont inactives et ne se réveillent que lorsque des problèmes se produisent sur un socket, vous pouvez vous attendre à des taux de commutation de contexte faibles.

Appels système

Les appels système provoquent des changements de contexte par leur nature même. Lorsqu'un processus effectue un appel système, il demande au noyau de prendre le relais de son heure actuelle et à la mémoire d'effectuer des tâches pour lesquelles le processus n'a pas le privilège de le faire, et de revenir au même endroit une fois terminé.

Lorsque nous regardons la définition de l'appel système write (2) de Linux, cela devient très clair:

PRÉNOM
       write - écrit dans un descripteur de fichier

SYNOPSIS
       #comprendre 

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

LA DESCRIPTION
       write () écrit jusqu'à compter le nombre d'octets du tampon indiqué par buf dans le fichier
       référencé par le descripteur de fichier fd. [..]

Valeur de retour
       En cas de succès, le nombre d'octets écrits est renvoyé (zéro indique
       rien n'a été écrit). En cas d'erreur, -1 est renvoyé et errno contient le code d'erreur
       de manière appropriée.
       [..]

En gros, cela indique au noyau de reprendre l’opération du processus, d’accéder aux countoctets, en partant de l’adresse mémoire indiquée par *bufle descripteur fdde fichier du processus en cours, puis de revenir au processus et de lui indiquer comment il s’est passé.

Un bon exemple à cet égard est le serveur de jeu dédié aux jeux basés sur Valve Source, hlds . http://nopaste.narf.at/f1b22dbc9 montre une seconde d'appels système effectués par une seule instance d'un serveur de jeu sur laquelle aucun joueur ne se trouve. Ce processus prend environ 3% de temps CPU sur un Xeon X3220 (2.4 Ghz), juste pour vous donner une idée de son coût.

Multi-tâches

Une autre source de changement de contexte peut être constituée par les processus qui ne font pas d'appels système, mais qui doivent être déplacés d'un processeur donné pour laisser la place à d'autres processus.

Cpuburn est une bonne façon de visualiser . cpuburn ne fait pas de appels système lui-même, il itère simplement sur sa propre mémoire, il ne devrait donc pas causer de changement de contexte.

Prenez un ordinateur inactif, démarrez vmstat, puis lancez burnMMX (ou tout autre test du package cpuburn) pour chaque cœur de processeur du système. Vous devriez avoir une utilisation complète du système à ce moment-là, mais pratiquement aucun changement de contexte accru. Ensuite, essayez de démarrer quelques processus supplémentaires. Vous verrez que le taux de commutation de contexte augmente à mesure que les processus commencent à concurrencer les cœurs de processeur. La quantité de commutation dépend du ratio processus / cœur et de la résolution multitâche de votre noyau.

Lectures complémentaires

linfo.org a un bon article sur le changement de contexte et les appels système . Wikipedia a des informations génériques et une belle collection de liens sur les appels système.

Michael Renner
la source
1
Cela a été utile - vous m'avez donné une bonne idée! =)
Xerxès
1
Votre déclaration System calls cause context switches by their very own naturesemble fausse. Les appels système provoquent un changement de mode, comme indiqué par linfo.org/context_switch.html
Nicolas Labrot le
6

Mon serveur Web moyennement chargé se situe entre 100 et 150 commutateurs une seconde la plupart du temps, avec des pics atteignant des milliers.

Les taux élevés de commutation de contexte ne sont pas un problème en soi, mais ils peuvent indiquer un problème plus grave.

edit: les commutateurs de contexte sont un symptôme, pas une cause. Qu'essayez-vous d'exécuter sur le serveur? Si vous avez un ordinateur multiprocesseur, vous pouvez essayer de définir l'affinité cpu pour les processus de votre serveur principal.

Sinon, si vous utilisez X, essayez de passer en mode console.

modifier à nouveau: à 16k cs par seconde, chaque unité centrale calcule une moyenne de deux commutateurs par milliseconde, soit un demi à un sixième du temps normal. Pourrait-il exécuter beaucoup de threads liés IO?

modifier à nouveau les graphiques de post: semble certainement lié à IO. le système passe-t-il le plus clair de son temps dans SYS lorsque les changements de contexte sont élevés?

éditer une fois de plus: High iowait et system dans ce dernier graphe - éclipsant complètement l'espace utilisateur. Vous avez des problèmes d'E / S.
Quelle carte FC utilisez-vous?

edit: hmmm. avez-vous une chance d'obtenir des points de repère sur votre accès SAN avec Bonnie ++ ou dbench pendant le temps mort? Je serais intéressé de voir si ils ont des résultats similaires.

edit: J'y ai pensé pendant le week-end et j'ai vu des modèles d'utilisation similaires lorsque Bonnie exécute la passe "écrire un octet à la fois". Cela peut expliquer le grand nombre de commutations en cours, chaque écriture nécessitant un appel système distinct.

Jay_dubya
la source
Je ne suis toujours pas convaincu qu'un taux élevé de commutation de contexte ne pose pas de problème. Je parle de taux élevés, comme entre 4K et 16K, pas 100-150.
Xerxes
Aucun de nos serveurs n’exécute de X. Je suis d’accord avec vous sur le problème d’attente d’IO et sur la relation entre cela et le CS. La carte HBA n’est pas suspecte, car nous utilisons la même carte sur la centaine de serveurs restants… La conclusion est que je blâme les équipes de SAN, le EVA SAN, qu’elles essayent désespérément de défendre tout le temps. Notez qu'une attente IO élevée n'est pas toujours une raison de s'alarmer. Si la plupart des processus d'une machine sont liés à l'IO, il est prévu que le serveur n'aura rien de mieux pour effectuer cette rotation inactive.
Xerxes
Le deuxième graphique ci-joint montre que ce n’est pas vraiment aussi proche que je le pensais au début. Pas tout à fait une éclipse. Je blâme toujours le SAN cependant. =)
Xerxès
1

Je suis plus enclin à s'inquiéter du taux d'occupation du processeur de l'état du système. Si elle est proche de 10% ou plus, cela signifie que votre système d’exploitation passe trop de temps à changer de contexte. Même si certains processus sont transférés sur une autre machine beaucoup plus lentement, ils méritent de le faire.


la source
1

Des choses comme celle-ci sont la raison pour laquelle vous devriez essayer de conserver des lignes de base de performances pour vos serveurs. De cette façon, vous pouvez comparer des choses que vous remarquez tout à coup avec des choses que vous avez enregistrées dans le passé.

Cela dit, j'ai des serveurs en cours d'exécution (principalement des serveurs Oracle très peu occupés), qui sont stables autour de 2k avec quelques pics de 4k. Pour mes serveurs, c'est normal, pour les serveurs d'autres personnes, il peut être trop bas ou trop haut.

Jusqu'où pouvez-vous remonter dans vos données?

Quel type d'informations de processeur pouvez-vous nous donner?

wzzrd
la source
Je suis tout à fait d’accord avec le maintien d’une base de référence, et nous avons des données nagios qui remontent sur de longues périodes - le problème avec ce serveur est que c’est du sang neuf - n’existe que depuis peu de temps. En outre, il exécute un logiciel d'entreprise (lire: merde) - Teamsite - qui vient d'être ajouté à la liste des variables non définies. Je préfère toujours sar (préférence personnelle), je vais donc le configurer pour conserver plus que la valeur par défaut (2 semaines) et voir comment ça se passe.
Xerxes
L'utilisation de sar en combinaison avec rrdtool (qui ressemble à vos graphiques) peut être un moyen facile de conserver vos données (ou du moins de les résumer) pendant longtemps.
wzzrd
0

Il n'y a pas de règle de base. Un commutateur de contexte est simplement le processeur qui passe du traitement d'un thread à un autre. Si vous exécutez beaucoup de processus (ou quelques processus hautement threadés), vous verrez plus de commutateurs. Heureusement, vous n'avez pas à vous soucier du nombre de changements de contexte, le coût est faible et plus ou moins inévitable.

Alex J
la source
6
En réalité, le coût d'un changement de contexte coûte cher . C'est encore pire sur les machines virtuelles - nous avons fait quelques tests il y a quelques mois, qui ont montré que l'une des principales causes des performances des machines virtuelles était la commutation de contexte.
Xerxès
En fait, dans tout système d'exploitation moderne (multi-tâches), la minimisation de la commutation de contexte est une tâche d'optimisation très importante. Avez-vous des sources pour confirmer votre affirmation selon laquelle le coût est faible?
Xerxès
Désolé, parlez-vous de minimiser les changements de contexte du point de vue du développement du système d'exploitation? N'ayant rien à voir avec un tel développement, je n'ai pas d'opinion sur les avantages de la conception d'un système pour minimiser la CS: Si vous parlez de minimiser les commutations de contexte sur un serveur, le problème est d'atténuer les commutations de contexte, ce qui introduit une latence à d'autres endroits. Par exemple, si vous réduisez le nombre de processus sur une machine, vous devez les transférer sur une autre machine, ce qui signifie que la communication a lieu sur un réseau, ce qui est beaucoup plus lent!
Alex J
Je crois que votre définition des changements de contexte est imparfaite. ils se produisent également lorsqu'un appel système est effectué, même s'il renvoie au même thread. Les applications optimisent contre cela en effectuant diverses astuces. Par exemple, Apache doit avoir très souvent l'heure système. à cette fin, un thread appelle à plusieurs reprises localtime et stocke le résultat dans la mémoire partagée. Les autres threads doivent uniquement lire dans la RAM et n'engendrent pas de changement de processus.
NiXar