[gull] ralentissement

cedric briner briner at infomaniak.ch
Wed Dec 20 16:07:55 CET 2006


je publie ici, les echanges avec Daniel Cordey, la suite a venir...

 > > j'imagine que ce que tu me demandes est
 > > quel est la commande que j'ai lancee pour ca:
 > >
 > > vmstat 5 100 > vmstat.out & iostat 5 100 >iostat.out
 > >
 > > donc l'interval est de 5 sec !

OK, j'ai examine et une chose me semble bizarre. Explications :

iostat : Tout est normal, quasi aucune activite disque. Impact absolument
invisible !!!

vmstat :

	- Le CPU est utilise a 100% (- 2/3 % de temps en temps). Un CPU plus rapide
	aiderait

	- 2 a trois process se partagent le CPU en permanence. Le minimum etant 2

	- Memoire... suffisante, pas de swapping, assez de buffer-cache, etc.

	- bo/bi tres faible, donc pas d'activite de paging significative. C'est 
meme
	bas.

	- Niveau d'interruption tres tres normal...
	
	- Context-switch... anormlement eleve ! Pourquoi ? Parcequ'il n'y a pas
	d'activite I/O... seulement du CPU. Or, un activite I/O impliquerait un
	nombre d'interruptions beaucoup plus eleve. Donc, il y a des CS
	alors que les process sont CPU bon, et sans paging...

Mon vieux, je crois que tu es dans une situation de cache-trashing ! Le
process 1 effectue ses operations et load des lignes de cache CPU,
rapidement, il arrive au bout de la cache... Il genere donc un cache-miss,
puis un autre, puis un autre... il se trouve rapidement mis de cote par le
scheduler, un autre process arrive, cherche a remplir la cache avec ses
donnees, genere des cache-miss... effectue une operation I/O, engendrant un
CS... autre process, meme chose... puis re-procees 1, qui continue son
calcul, genere des cache-miss, etc.

Ce qui fait que les CPUs passent leur temps a avoir des cache-miss et ne
beneficient donc pas de l'avantage du cache du CPU. Les process en 
cache-miss
comptabilisent quand meme leur temp d'acces memoire comme 'user time' et 
non
comme systeme lorsque des donnees sont lues du buffer-cache du file system.
Les process sont donc interrompus toutes les 300 musec a 1 ms. C'est une
valeur beaucoup trop elevee pour un environementg CPU bound.

Comment s'en sortit ? D'abord, ne pas jouer avec nice... je trouve que 
ca ne
sert a rien, si ce n'est rendre les choses plus compliquees. Ne surtout 
rien
faire pour augmenter le niveau de context switch; ne pas reduire la 
valeur de
10ms pour le scheduling... ca ne fait qu'amlifier le probleme.

Le probleme du cache-thrashing est insoluble et ingerable. D'abord, il te
suffit d'une cacahouette pour passer de 'tout-va-bien' a 'c;est l'horreur'.
C'est un 'coude' et il n'ya pas de degradation lente. Le seul moyen 
etant de
separer les process sur des CPUs differents. Peut-etre qu'un systeme 
dual-cpu
apporterait une bouffe d'air, mais on aurait toujours l'epee de Damocles
concernant le probleme de cache-synchronisation entre les deux CPUs. 
Surtout
pas de dual-core... inutile... amoins d'avour une augmentation massive de
cache CPU par rappport a l'existant... Autre solution, un CPU avec le
double/triple/quadruple de CPU cache... Mais, le mieux est de mettre les
process sur des machines separees...

dc




More information about the gull mailing list