[gull] nombre instance max avec find
Daniel Cordey
dc at mjt.ch
Tue Aug 23 18:33:33 CEST 2005
On Tuesday 23 August 2005 17:39, Cedric BRINER wrote:
> Qu'entends-tu par: ``disk bound''
CAD que find est avant tout "bloque" par les performances du disque. De plus,
un disque a deux limitations. Sont taux de transfert maximal (quand les blocs
se suivent bien...) et le nombre de mouvement des tetes par seconde (assez
lie a la vitesse de rotation, quoique ca depend du genre de mouvement). Or,
find n'a pas besoin de lire les data de chaque fichier, mais simplement les
informations relatives a ceux-ci et contenu dans les "directory". Ce qui fait
que find doit lire plein de blocs relativement petits et non contigus. Il est
donc tres limite par la performance du disque. En dehors de ca, et a part les
transferts de data entre le kernel et la "data user space" du programme, find
a bien peu de travail a effectue si ce n'est de "balayer" des structures et
de comparer leurs valeurs. find n'est donc pas un tueur de CPU... Sur mon
systeme, lancer un 'find / -print' m'utilise entre 1.0 et 1.5 % de CPU...
alors que le disque est sur le genoux en train de "savonner" entre 150 et 500
tps (tracks / second) !!! C'est donc la qu'est le goulet d'etranglement...
> *) Imaginons que chaque tache prenne environ de 30min a 1h30 de calcul et
> 1/4 de la memoire. Que de trouver un nouveau fichier prenne 4 min. Alors
> executer autant de ``mon_programme'' que de processeurs me semble etre une
> bonne politique.
Oui et non... ca depend :-) Il faut separer les deux choses. Tu parles d'un
programme de calcul qui prend 1h (en moyenne), puis de recherche de fichier
qui ne prend que 6.7% de ce temps... Si tu as besoin de rechercher des
fichiers dans ton systeme de maniere reguliere, ne peux-tu as envisager de
faire un find de temps en temps (find / -print), dont le contenu sera mis
dans un seul fichier, puis de faire un grep sur ce contenu ? C'est ce que je
fais depuis des annees. Actuellement, mon find me prend 305 secondes, genere
un fichier de 45 MB contenant 803'000 fichiers. Un 'grep toto' me prend 0.5
secondes... soit 610 fois plus rapide que de faire un find. Bien sur, le
fichier pourait aussi contenir la taille, le UID, etc. Mais, meme si le
fichier devient plus gros, le grep sur celui-ci restera massivement plsu
rapide que le find.
Si maintenant, tes programmes qui durent 1 heure, generent des tonnes de
fichiers aux noms aleatoires, le problemen est different. Mais malgre cela,
find reste peut-etre la moins bonne solution. A moins qu'en plus les fichiers
ne soient crees a des endroits aleatoires dans le systeme :-)
> Si au lieu de ca, on lance les 100 mon_programme en parallele, alors j'en
> aurais que le_nombre_de_processeur en un instant donne qui tourneront alors
> que les autres seront en ``sleep''. Ce qui se rapproche de (*) a la
> diffrence pres que cette methode sera bcp plus couteuse question swap !
Pour benefichier au maximum de l'effet 'N', il faut que le programme soit tres
petit (au niveau code) et qu'il utilise exclusivement des 'shared libraries'.
Sinon, chaque libraririe (ou portion de code) statique sera dupliquee dans la
memoire !!! Toutefois, il faut encore que le programme soit fortement oriente
"boucle de calcul", ainsi les portions de code a execute auront plus de
chance de rester dans la memoire cache... mais... il y a uassi un
desavantage. Il se peut que la version 1 du programme tourne un moment sur le
CPU A. Donc, c'est la cache (text) du CPU qui sera utilisee... puis, ce
process va ceder sa place a un autre et il y a pas mal de chances qu'il se
retrouve a devoir tourner sur un autre CPU... alors la cache du CPU A doit
etre invalidee (facile et peu couteux) et le 'code' a execute doi etre
recharge dans la cache du nouveau CPU (tres couteux). Et encore, nous ne
parlons que du caching du code executable... C'est quand on commence a
envidager le probleme des data que ca se corse vraiment. En effet, dans le
cas des data, rien n'est partage entre les process. Ce qui fait que plus on a
de CPU, plus on a de chances d'etre "reschedule" sur un autre CPU avec le
probleme de la cache directement lie. Ceci engendre une charge importante sur
la cache des CPU et, de fait, sur le bus memoire. La saturation peut donc
etre tres vite atteinte si les programmes manipulent de grosses sections de
donnees. C'est la raison pour laquelle les systemes destines a etre utilises
comme serveur de calcul // ont des fonctionalites dans le kernel permettant
de bloquer un process sur un CPU en particulier (entre autre). Cette fonction
est disponible sous Linux mais elle n[est pas en standard dans le kernel. En
plus, il est important d'avoir un bus memoire consequent, ainsi que des
chipsets et MMUs un peu plus exotique que ceux que l'on trouve dans les PC.
Aussi, ces systems groupent les CPUs par paquet de 2 ou 4 sur une meme carte
avec un chipset particulier destine a emeliorer la coherence des caches entre
les N CPUs de la carte. Les MMUs sont concus pour permettre la serialisation
des requetes a la memoire, ainsi que l'independances des acces DMA.
En plus, il vaut mieux utiliser des CPUs dont l'architecture est specialement
etudiee pour optimiser le pipeline et la cache... c'est-a-dire concu pour
etre mis en // avec d'autres CPUs. Meme si les Pentium/Xeon/AMD sont
optimises au maximum, ils n'ont pas ete concus pour ce genre d'usage et il
engendres une saturation plus rapidement que des architectures Power &
Itanium. Ce qui fait aussi que l'on ne trouve pas vraiment de chipset concus
pour supporter 64 ou 128 Pentium (en vrai partage de memoire !!!).
> > A moins d'avoir N disques, auquel cas il est cense de lancer un find par
> > disque (voir deux...).
>
> Je ne comprends pas cette phrase. On doit avoir un petit probleme de
> comprehension.
Sachant que le disque EST le goulet d'etranglement, il est parfaitement
logique de lancer un find par disque.
More information about the gull
mailing list