Greg a écrit 168 commentaires

Serait-ce le début de l'évolution de l'esprit Unix ?

On est en train de regrouper les 2 points de cette esprit:
- "Tout est fichier"
- "Un programme fait une chose unique et le fait bien."

par un truc du genre: "Tout est évènement" ?

Ils sont déjà dispo sur dotdeb http://www.dotdeb.org/2012/03/01/php-5-4-0-preview-packages/

Avant les extensions pouvaient être compatible pour une version 3.*, ce qui fait qu'elles fonctionnaient toujours de la 3.5 à 3.6.

Maintenant, il faut absolument qu'elles soient suivies. Ca demande plus de travail aux mainteneurs.

La difficulté avec ce changement de numérotation, ce sont pour les extensions. C'est pourtant en partie grâce à elles que Firefox a autant de succès.

J'aimerai bien voir le résultat sur un serveur qui fait énormément d'IO, type backup. Si plusieurs process sont utilisés pour le faire...

Après cette mauvaise expérience, je me suis rabattu sur une toute autre config à base de SAN et de NFSv4 ... Oui, l'expérience a été mauvaise à ce point là. N'empêche qu'avec cette nouvelle config, je n'ai eu jusqu'à présent aucun problème ni de perf ni de stabilité...

J'ai eu moi aussi de très mauvaises expériences avec GlusterFS, et je peux constater avec cette dépêche que les priorités de Gluster n'ont pas changés : toujours plus de fonctionnalités, mais aucune amélioration sur la stabilité !
Stabilité en terme de bugs, oui, mais aussi en termes de performances: on a parfois des comportements bizarres et inexpliqués au niveau applicatif ! (Ces problèmes pouvant peut-être à cause de FUSE)

Ce projet est excellent pour donner de bonnes idées aux autres (MooseFS et Ceph), mais n'est tout simplement pas exploitable en prod.

Ceph a une vision contraire à Gluster: pas de FUSE, d'abord la stabilité avant les fonctionnalités. D'ailleurs sur leur site il est écrit en rouge "Ceph is under heavy development, and is not yet suitable for any uses other than benchmarking and review." et pourtant je pense que leur version même-pas-alpha est déjà bien plus stable que Gluster.

L'option -P8 indique que xargs aussi parallélisé, à hauteur de 8 threads en // .

Voir tests ci-dessus avec des "true" plutot que des "echo | wc".

Et en supprimant les IO :

$ time for i in {1..100000} ; do echo $i; done | xargs -P8 true
real 0m1.098s
user 0m0.908s
sys 0m0.368s

$ time for i in {1..100000} ; do echo $i; done | ~/tests/parallel-20101222/src/parallel -j8 true
real 2m49.153s
user 6m12.215s
sys 3m10.644s

# en non groupé :
$ time for i in {1..100000} ; do echo $i; done | ~/tests/parallel-20101222/src/parallel -u -j8 true
real 2m32.511s
user 5m51.850s
sys 3m18.548s

euh non, je ne "echo" pas le contenu des fichiers, juste leurs noms.

Le wc n'est pas parallélisé, son but est uniquement de comparer les résultats. Mais toute la partie avant le wc est parallélisé, et permet de voir que les "echo" sont lancés plus rapidement avec xargs.

Pour te faire plaisir, j'ai refais le même test avec une commande qui ne fait rien: true

$ time find . -xdev -type f -print0 | xargs -0 -n1 -P8 true
real 0m7.696s
user 0m0.300s
sys 0m3.580s

$ time find . -xdev -type f -print0 | ~/tests/parallel-20101222/src/parallel -0 -j8 true
real 1m38.532s
user 3m21.281s
sys 1m53.623s

Effectivement, et puis en lisant la doc on s'aperçoit qu'il y a plein de choses sympa, comme les job queues, les semaphores ...

Il sait faire bien plus de choses que xargs, mais pour une utilisation simple et performante, xargs semble plus approprié.

Tests effectués plusieurs fois, parce que le find est dépendant des IOs disques. Mais faites le test vous même, c'est sans appel ! ;)

parallel :
$ time find . -xdev -type f -print0 | ~/tests/parallel-20101222/src/parallel -0 -j8 echo | wc -l
54273
real 1m42.335s
user 3m14.536s
sys 2m4.012s

xargs:
$ time find . -xdev -type f -print0 | xargs -0 -n1 -P8 echo | wc -l
54273
real 0m7.914s
user 0m0.356s
sys 0m3.672s

Quel différence avec l'option -P de xargs ?
L'option --load me parait un peu de la bidouille, je lui préfèrerais ionice qui modifie le scheduler (CFQ uniquement) du kernel linux, ou nice si on est plutôt CPU bound ...

$ ionice -c3 -p$$ && locate -r '\.log$' | xargs -P4 wc -l

De plus, xargs calcul le nombre maximum d'arguments transmissible à la commande, mais on peut aussi le spécifier avec -n.

Last but not least xargs est installé d'office sur la plupart des OS, alors que parallel n'existe pas encore en package Debian !

Quel est le réel intérêt de parallel ?

sur certaines cartes je vois juste une ligne par interface, sur d'autres je vois un ethN-M avec M de 0 à <nombre de cores>.
Mais pas de rx ni de tx.

Ca veut dire que dans le 1er cas, c'est une mono-queue, dans le second, une vrai multi-queue, et si j'avais des tx rx ce serait des multi-queue émulé par RPS RFS ?

Une autre question que je me pose: comment savoir si on a une carte réseau mono ou multi queue ?

T'as fais un bench ?

Perl explose Python, Ruby et Java en terme de performances ! Tant CPU que consommation mémoire, tout en étant bien plus accessible que le C.

Après, c'est sûr, si on veut un programme vraiment performant, ya que le C (et ASM).

Excellentissime cette année, je me marre bien sur ce cru :)

sinon on peut utiliser xargs, par exemple pour restaurer un dump de 1 fichier par table, 4 en // :

ls *.gz | xargs -n 1 -P 4 -I {} sh -c 'zcat {} | mysql restore'


Bonsoir,

une autre solution: provoque des pannes qui de toute façon vont arrivés dans les mois à venir, et tu l'auras ton budget ;)

Autre solution: j'ai 2-3 serveurs qui sont en fait des PC assemblés, coute seulement 167€HT, et niveau fiabilité c'est pas si mal... Yen a un
ça fait 2 ans qui tourne 24/7 et je n'ai eu aucun problème !

pour info le kernel Debian 2.6.26-17lenny2 pour lenny, a le patch de Linus.

sur un poste de travail je ne me poserais pas tant de questions, mais sur des serveurs fortement chargés ?

Ca me gène un peu de modifier un paramètre kernel sans réellement savoir ce qu'il fait, surtout si, d'après le peu d'infos que j'ai trouvé et compris, ce paramètre peut jouer sur la stabilité des programmes/services... :-/

et quels sont les conséquences ?

Plus sérieusement: ya t-il moyen de protéger un serveur contre cette faille, sans mise à jour du kernel ? (sur un serveur qui n'a pas pulseaudio).