Combien de commutateurs de contexte est "normal" (en fonction des cœurs de processeur (ou autres))?
Salut les Overlords Linux/UNIX,
L'un de vous a-t-il une règle de base sur le nombre de commutateurs de contexte (par cœur de processeur) Normal sur un serveur Linux?
Mon université ici l'a soulevé, et il voit 16K sur un 8-core x86_64 machine.
Voici quelques statistiques de sarface ces derniers jours ...
texte alternatif 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 ...
texte alternatif http://src.autonomy.net.au/imagebin/7481f7e52bead4effc90248fc23c72fe-Picture_11.png
Et les 8 noyaux s'ennuient à mort ...
texte alternatif http://src.autonomy.net.au/imagebin/0e94326652e977fd74edcd840f94200f-Picture_12.png
CS vs IOwait (échelle x10000)
texte alternatif http://src.autonomy.net.au/imagebin/a52a2a8a120394849c0da4045933e306-Picture_13.png
Plus d'informations inutiles au cas où quelqu'un demanderait ..
- Le stockage sur lequel le serveur fonctionne est de 0,5 To SAN via FC
- Il y a 8 Go de RAM, principalement du cache - pas d'échange.
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 déclencheurs, vous pouvez vous attendre à voir de grandes quantités de changement de contexte. Si la plupart de vos applications sont inactives et ne se réveillent que lorsqu'il se passe des choses sur un socket, vous pouvez vous attendre à des taux de changement de contexte bas.
Appels système
Les appels système provoquent des changements de contexte par leur propre nature. Lorsqu'un processus fait un appel système, il dit essentiellement au noyau de prendre le relais de son point dans le temps et de la mémoire pour faire des choses que le processus n'est pas privilégié et de revenir au même endroit lorsqu'il est terminé.
Lorsque nous regardons la définition de l'appel système write (2) de Linux, cela devient très clair:
NOM Écriture - écriture dans un descripteur de fichier SYNOPSIS #Include Ssize_t write (int fd, const void * buf, size_t count); DESCRIPTION write () écrit pour compter les octets du tampon pointé buf dans le fichier auquel il est fait référence par le descripteur de fichier fd. [..] VALEUR RENVOYÉE 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 est défini correctement sur . [..]
Cela indique essentiellement au noyau de prendre le relais de l'opération du processus, de monter jusqu'à count octets, en commençant par l'adresse mémoire pointée par *buf au descripteur de fichier fd du processus en cours, puis revenez au processus et dites-lui comment cela s'est passé.
Un bon exemple pour le montrer est le serveur de jeu dédié aux jeux basés sur Valve Source, hlds . http://nopaste.narf.at/f1b22dbc9 montre une seconde de syscalls effectués par une seule instance d'un serveur de jeu sans joueurs. 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 pourrait être les processus qui ne font pas d'appels système, mais doivent être retirés d'un processeur donné pour faire de la place à d'autres processus.
Une belle façon de visualiser cela est cpuburn . cpuburn ne fait aucun appel système lui-même, il itère simplement sur sa propre mémoire, donc il ne devrait pas provoquer de changement de contexte.
Prenez une machine inactive, démarrez vmstat, puis exécutez un 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 d'ici là, mais pratiquement aucun changement de contexte accru. Essayez ensuite de démarrer quelques processus supplémentaires. Vous verrez que le taux de changement de contexte augmente à mesure que les processus commencent à rivaliser avec les cœurs de processeur. La quantité de commutation dépend du rapport processus/cœur et de la résolution multitâche de votre noyau.
Lectures complémentaires
linfo.org a un bel article sur ce que sont changements de contexte et appels système . Wikipedia a des informations génériques et une belle collection de liens sur les appels système.
mon serveur Web modérément chargé se situe à environ 100-150 commutateurs une seconde la plupart du temps avec des pics par milliers.
Les taux de changement de contexte élevés ne sont pas eux-mêmes un problème, mais ils peuvent ouvrir la voie à un problème plus important.
edit: Les changements de contexte sont un symptôme, pas une cause. Qu'essayez-vous d'exécuter sur le serveur? Si vous avez une machine multiprocesseur, vous pouvez essayer de définir l'affinité cpu pour vos processus serveur principaux.
Sinon, si vous exécutez X, essayez de passer en mode console.
modifier à nouveau: à 16k cs par seconde, chaque processeur est en moyenne de deux commutateurs par milliseconde - soit la moitié à un sixième de la tranche de temps normale. Pourrait-il exécuter beaucoup de IO threads liés?
modifier à nouveau les graphiques de publication: semble certainement IO lié. le système passe-t-il la plupart de son temps dans SYS lorsque les changements de contexte sont élevés?
modifier une fois de plus: iowait élevé et système dans ce dernier graphique - éclipsant complètement l'espace utilisateur. Vous avez des problèmes IO.
Quelle carte FC utilisez-vous?
modifier: hmmm. toute chance d'obtenir des benchmarks sur votre SAN avec bonnie ++ ou dbench pendant les temps morts? Je serais intéressé de voir s'ils ont des résultats similaires.
edit: J'y ai pensé au cours du week-end et j'ai vu des modèles d'utilisation similaires lorsque Bonnie fait le passage "écrire un octet à la fois". Cela peut expliquer le grand nombre de commutations en cours, car chaque écriture nécessiterait un appel système distinct.
Des choses comme celle-ci sont la raison pour laquelle vous devriez essayer de conserver des références de performances pour vos serveurs. De cette façon, vous pouvez comparer des choses que vous remarquez tout d'un coup avec des choses que vous avez enregistrées dans le passé.
Cela dit, j'ai des serveurs en cours d'exécution (des serveurs Oracle peu occupés, principalement), qui sont stables autour de 2k avec des pics de 4k. Pour mes serveurs, c'est normal, pour les serveurs d'autres personnes qui pourraient être bien trop bas ou trop hauts.
Jusqu'où pouvez-vous remonter dans vos données?
Quel type d'informations sur le processeur pouvez-vous nous fournir?
Je suis plus enclin à m'inquiéter du taux d'occupation du processeur de l'état du système. S'il est proche de 10% ou plus, cela signifie que votre système d'exploitation passe trop de temps à faire les changements de contexte.Bien que déplacer certains processus vers une autre machine soit beaucoup plus lent, cela mérite de le faire.
Il n'y a pas de règle d'or. Un changement de contexte est simplement le CPU qui passe du traitement d'un thread à un autre. Si vous exécutez de nombreux processus (ou quelques-uns 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.