Créer de nouveaux processus est très lent sur certaines de mes machines et non d'autres.
Les machines sont toutes similaires et certaines des machines lentes exécutent exactement les mêmes charges de travail sur le même matériel et le même noyau (2.6.32-26, Ubuntu 10.04) comme certaines des machines rapides. Les tâches qui n'impliquent pas la création de processus sont les mêmes vitesses sur toutes les machines. P>
Par exemple, ce programme exécute ~ 50 fois plus lent sur les machines affectées: P>
int main()
{
int i;
for (i=0;i<10000;i++)
{
int p = fork();
if (!p) exit(0);
waitpid(p);
}
return 0;
}
5 Réponses :
Je pourrais commencer par utiliser la strace pour voir quels appels système sont en cours d'exécution et où les lents sont suspendus. Je suis également curieux de savoir comment vous utilisez WaiterPID () ici. Sur mes systèmes, la signature pour WaiterPID est
pid_t waitpid(pid_t pid, int *status, int options);
C'est la même chose que alterpid (p, 0, 0) qui attend simplement le PID p pour quitter. * Statut est un pointeur pour rédiger les informations de statut si vous le souhaitez (je m'en fiche, si nul), pas le ou les indicateurs comme vous avez dit (c'est le Options param). Changer le code sur PAIDPID (0, 0, 0) ou JUST WAIT (0) donne les mêmes résultats. J'ai aussi mis à jour la question avec mes résultats de la strace.
Vous avez raison, mon mauvais, en ce qui concerne les paramètres de statut / options. Le fait que le clone soit lent est très intéressant. Cela devrait être très rapide. Je spécule sauvagement ici, mais il me semble que cela ne devrait être que lent que si le noyau se débattait d'une manière ou d'une autre (peut-être traiter avec des interruptions du matériel? Peut-être avec une allocation de mémoire?). Je pourrais regarder Dmesg sur les machines lentes et voir s'il y a quelque chose de évidence étrange se passe, comme un contrôleur SCSI paniquer.
Vous voudrez peut-être également examiner la sortie de "VMSTAT 5" pendant un moment, sur l'hypothèse que si les machines concernées ont beaucoup de changements de contexte ou d'interruptions se passent par rapport aux mêmes statistiques d'une machine de travail, cela pourrait conduire à le coupable (vérifier les colonnes "dans" et "cs")
Les différences à regarder sont le noyau (paramètres, pilotes de périphérique, modules actifs) et au matériel (version CPU, nombre de processeurs, configuration de la mémoire, périphériques).
Aussi: Les machines changent-elles après un cycle de redémarrage / de puissance?
EDIT:
La faible performance est probablement liée à la hiérarchie de la mémoire (virtuelle). Cette hiérarchie est très complexe et cette complexité peut entraîner des effets étranges. Quelque part sur le chemin de TLB aux caches de données aux principaux conflits étrangers peuvent survenir. Ceux-ci peuvent être causés par une disposition de mémoire légèrement différente des noyaux des différentes machines, ou parce que la hiérarchie de la mémoire (matériel) est en fait légèrement différente.
Bien sûr, il pourrait y avoir d'autres raisons, un périphérique étrange (génération d'interruptions), une charge de travail différente (par exemple un nombre de processus actifs), ...
Si vous pouvez résoudre ce problème, veuillez partager les résultats! Merci.
sont les valeurs de Permettre à l'agent de surcadrement apportera / sbin / sysctl vm.overcommit_memory identique pour tous les systèmes? Sinon, cela pourrait expliquer la différence.
Fourche () beaucoup plus rapidement, mais cela signifie que les pages nouvellement allouées ne seront pas soutenues par la RAM ou l'échange. Si / lorsque vous touchez une page non commune, le système d'exploitation doit trouver un soutien pour cela - et s'il ne le peut pas, le processus est tué. Ce n'est pas un problème si tout l'enfant fait est EXEC () , comme se produit dans un System () appel, car toutes ces pages nonBacked sont supprimées; Cependant, cela pourrait entraîner de graves problèmes pour les autres utilisateurs de Fourche () .
Avez-vous vérifié la configuration du BIOS, au cas où vous auriez les caches CPU désactivés ou la configuration d'alimentation enfreinte, ou que certains systèmes se surchauffent ou que certaines mémoires sont omniprésentes ...
Nous avons connu le même problème avec notre pile d'applications, en remarquant une dégradation massive dans la performance des applications et des temps de clonage plus longs avec la strace. En utilisant votre programme de test sur 18 nœuds, j'ai reproduit vos résultats sur le même 3 que nous vivions des temps de clonage lents. Tous les nœuds ont été provisionnés de la même manière, mais avec du matériel légèrement différent. Nous avons vérifié le BIOS, VMSTAT, VM.OverCommit_Memory et remplacé la RAM sans aucune amélioration. Nous avons ensuite déplacé nos entraînements sur du matériel mis à jour et la question a été résolue.
Centos 5.9 2.6.18-348.1.1.EL5 # 1 SMP TUE 22 16:19:19 EST 2013 x86_64 x86_64 x86_64 x86_64 gnu / linux p>
"mauvais" et "bon" lspci: p>
$ diff ../bad_lspci_sort ../good_lspci_sort < Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 05) > Ethernet controller: Intel Corporation 82574L Gigabit Network Connection < Host bridge: Intel Corporation Xeon E3-1200 Processor Family DRAM Controller (rev 09) > Host bridge: Intel Corporation Xeon E3-1200 v2/Ivy Bridge DRAM Controller (rev 09) < ISA bridge: Intel Corporation C204 Chipset Family LPC Controller (rev 05) > ISA bridge: Intel Corporation C202 Chipset Family LPC Controller (rev 05) < PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 6 (rev b5) > PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 7 (rev b5) < VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200e [Pilot] ServerEngines (SEP1) (rev 04) > VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200eW WPCM450 (rev 0a)
Merci pour votre Modification suggérée ! Il a été rejeté mais je le trouve utile, alors je l'ai ajouté à Ma réponse .
Existe-t-il des messages étranges dans
dmesg (1) sortie?