[gull] nombre instance max avec find

[Daniel Cordey]

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.