Jeff Robertson nous montre[0] les résultats d'un benchmark entre FreeBSD 7 (encore en développement à l'heure actuelle, version CVS) et une Fedora Core 6, qui si je ne m'abuse dispose d'un noyau Linux 2.6.18.
Il utilise sysbench[1], un benchmark multithreadé pour MySQL[2] sur un processeur AMD64 a 8 coeurs.
Les performances (en transactions/seconde) sont semblables pour un nombre de threads travailleurs inférieur ou égal ç 4; de 4 à 8, Linux prend l'avantage jusqu'à 8 threads, mais ses performances s'effondrent dramatiquement au delà, donc quand le nombre de ces derniers dépasse le nombre de coeurs, alors que celles de FreeBSD restent remarquablement stables.
Quelqu'un dans la salle peut commenter les résultats, la pertinence ou l'impertinence de ce benchmark ? Les problèmes de scalabilité de Linux sont-ils liés au modèle d'implémentation des threads au sein du noyau (1-on-1 sous Linux[3], M-on-N pour FreeBSD[4]) ?
[0] : http://jeffr-tech.livejournal.com/5705.html
[1] : http://sysbench.sourceforge.net/
[2] : http://www-fr.mysql.com/
[3] : http://en.wikipedia.org/wiki/Native_POSIX_Thread_Library
[4] : http://en.wikipedia.org/wiki/Kernel_Scheduled_Entities
Journal Un benchmark FreeBSD 7 (CURRENT) et Fedora Core 6
24
fév.
2007
# rigolade
Posté par patrick_g (site web personnel) . Évalué à 2.
Je ne suis pas du tout un spécialiste mais ilme semble que même une tanche comme moi ne peut s'empêcher de rigoler quand il lit un truc comme ça :
Both are running mysql 5.0.x where x is within about 3 of each other
C'est du test équitable ça coco !
(PS : et je ne parle même pas du fait de comparer un kernel linux 2.6.18 qui retarde de deux versions par rapport au dernier 2.6.20 avec un FreeBSD-7 tellement bleeding edge qu'il n'est même pas encore sorti....)
[^] # Re: rigolade
Posté par Bapt (site web personnel) . Évalué à 10.
http://jeffr-tech.livejournal.com/6268.html#cutid1
Maintenant il est possible d'essayer de comparer.
[^] # Re: rigolade
Posté par B16F4RV4RD1N . Évalué à 2.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: rigolade
Posté par lurker . Évalué à 4.
Il y a bien le fameux http://bulk.fefe.de/scalability/ mais je pense qu'il est désormais un peu trop vieux pour être pertinent.
(Ce n'est probablement pas ce que tu voulais dire, mais les OpenBSD, NetBSD, FreeBSD et DragonFly BSD ont tous leurs noyaux différents)
[^] # Re: rigolade
Posté par B16F4RV4RD1N . Évalué à 2.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: rigolade
Posté par lurker . Évalué à 4.
Il me semble que c'est l'implémentation des threads et du SMP à partir de FreeBSD 5.x, le projet SMPng mentionné dans un autre des commentaires, qui a mené Matt Dillon à forker FreeBSD pour commencer DragonFly BSD qui utilise http://en.wikipedia.org/wiki/LWKT
Pour NetBSD, il me semble qu'ils utilisent cette technique : http://en.wikipedia.org/wiki/Scheduler_Activations
[^] # Re: rigolade
Posté par Joc M . Évalué à 7.
Si on peut remarquer une baisse des performances de linux lorsqu'il y a plus de threads que de processeurs alors qu'un autre système ne présente pas les même symptômes ce serait sûrement le cas quel que soit la sous-version de MySQL.
En ce qui concerne les nouveautés du noyau 2.6.20 c'est peut être un peu différent même si je ne me souviens pas avoir vu de révolution dans la dernière version concernant la gestion des threads.
Pour finir, tout benchmark ne peut être théoriquement parfait puisqu'il s'agit de la définition même de l'empirisme.
Même si il existe des tests plus poussés sur le sujet, je trouve que les conclusions sont pour le moins clairs et difficilement mettables en cause pour des problèmes de version.
# Re:
Posté par IsNotGood . Évalué à 10.
NB : Mysql a la réputation d'être très exigent en futex.
Petite intro sur les futex/spinlock.
Un futex est un verrou.
Imaginons :
étape 1- thread (a) obtient le futex F
étape 2- thread (b) demande le futex F et bloque
étape 3- thread (a) libère le futex F
étape 4- thread (b) obtient le futex F et continu
En première approche on peut se dire qu'à l'étape 2 le thread (b) est mis en sommeil. C'est obligatoire pour du mono-cpu. On a un changement de contexte (userland / kernel). Ce changement est cher, 1000 instructions machine voire plus. Sur les systèmes smp et s'il y a plus de cpu que de thread actif, le mieux est de faire tourner le thread (b) en boucle comme ça il continue dès que le futex est dispo.
Sans la pratique, il faut trouver un compromise entre les deux scénarios précédent (mise en sommeil et spinlock). Comme un changement de contexte est cher, on a un mix entre les deux. Lorsqu'un futex est demandé et qu'il est déjà utilisé, on boucle (spinlock) un petit moment (très court) au cas où le futex est libéré durant cette boucle. S'il n'est pas dispo, le thread passe en sommeil. C'est pertinant à faire si la boucle spinlock coûte moins cher qu'une mise en sommeil du thread puis réveille. Lorsque les futex sont pris un très court instant (ce que les développeurs essaient normalement de faire) et sur un système smp, les spinlock offrent un gain important.
J'imagine que durant le bench lorsque nombre de thread <= nombre coeur, lorsqu'un thread demande un futex il l'obtient de suite et s'il boucle dans un spinlock, c'est sans conséquence car sinon le cpu qui exécute le thread n'a rien à faire.
Les performances chutent lorsqu'il y a plus d'un thread par cpu et je pense que lorsqu'un thread demande un futex il ne l'obtient de suite. Le thread est dans le spinlock un très cours instant avant de passer en wait.
Les boucles spinlock sont extrèmement rapides. On a une dizaine d'instruction cpu par boucle. Mais si des options de DEBUG sont activés, ça peut être une tout autre histoire et on peut avoir une centaine d'instruction machine (en fait, j'en sais rien, mais c'est envisagable). On peut imagine que dans ce cas et pour ce bench, les cpu passent beaucoup de temps dans les spinlock.
Sous Fedora par défaut il y a d'activé CONFIG_DEBUG_SPINLOCK et CONFIG_DEBUG_SPINLOCK_SLEEP. Il faudrait un bench sans ses options.
[^] # Re: Re:
Posté par Charles-Victor DUCOLLET . Évalué à 2.
technique, beau et concis...
[^] # Re: Re:
Posté par Vador Dark (site web personnel) . Évalué à 1.
En revanche, certains n'ont pas pus s'empêcher de te moinser ;).
[^] # Re: Re:
Posté par IsNotGood . Évalué à 3.
J'ai vu que le test a été fait avec 2.6.18 (noyau d'origine de FC6), 2.6.19 (update FC6) et 2.6.20.1 vanilla. Le 2.6.20.1 n'est pas un noyau Fedora, mais s'il a été configuré sans précaution (make config && make), CONFIG_DEBUG_SPINLOCK reste actif. Lors d'un "make config" ou "make menuconfig", la configuration en cours est reprise.
[^] # Re: Re:
Posté par patrick_g (site web personnel) . Évalué à 5.
Pourquoi des options de debug sont-elles activées par défaut dans une distribution définitive qui est releasé auprès du public ?
Je comprends bien qu'on active le debug dans les versions de test ou les -RC mais pourquoi continuer dans la vraie version de prod puisque cela semble impacter les performances ?
Ne me dit pas que ce serait une manière d'utiliser Fedora comme une version beta de RHEL et ce au détriment des performances des utilisateurs de Fedora ! Non ce serait trop machiavélique.....
[^] # Re: Re:
Posté par IsNotGood . Évalué à 10.
Il y a toujours du subjectif dans ces choix.
Pourquoi conserver la sortie du kernel (dmesg) si la distribution est sensée marcher sans accro ? D'ailleur cette sortie n'est pas affichée.
Pourquoi fournir SeLinux alors que les programmes livrés ne doivent pas avoir de trou de sécurité et marcher de façon sûr sans SeLinux ?
Pourquoi Fedora détecte les mauvais free (). exemple : "*** glibc detected *** gedit: free(): invalid pointer: 0x0858cb08 ***" ?
etc...
Pour spécifiquement CONFIG_DEBUG_SPINLOCK d'activité, je n'en sais rien.
Pour info, voilà les options de debug du dernier noyau FC6 :
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_FS=y
CONFIG_DEBUG_HIGHMEM=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_LIST=y
CONFIG_DEBUG_RODATA=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_DEBUG_STACK_USAGE=y
Pour le noyau rawhide (développement) actuel :
CONFIG_DEBUG_DEVRES=y
CONFIG_DEBUG_FS=y
CONFIG_DEBUG_HIGHMEM=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_LIST=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_RODATA=y
CONFIG_DEBUG_RT_MUTEXES=y
CONFIG_DEBUG_RWSEMS=y
CONFIG_DEBUG_SHIRQ=y
CONFIG_DEBUG_SLAB_LEAK=y
CONFIG_DEBUG_SLAB=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_DEBUG_STACK_USAGE=y
CONFIG_DEBUG_VM=y
On voit déjà que la version de développement à plus de debug. Je ne crois pas 2 second que les CONFIG_DEBUG* de FC6 soit uniquement pour débuggeur le noyau (sauf cas particulier) si c'est au prix d'une perte de performance significatif connue. Et ce pour plusieurs raisons :
- Fedora est développé de façon ouverte et ça gueulerait sévère sur les mailing list.
- Fedora n'a aucun intérêt à fournir un noyau lent, bien au contraire.
- Fedora a la branche développement pour ça et la branche testing pour les mises à jour.
Donc, pourquoi CONFIG_DEBUG_SPINLOCK ?
Voilà mon interprétation (je ne connais pas l'avis de Fedora).
Il va de soit que Fedora est aussi utilisé pour développer des applications. Il est dans les objectifs de Fedora d'être une plateforme pour le développement d'application. Le développement d'appli multi-thread est compliqué et se planter avec les futex est très courrant. Je crois qu'avec CONFIG_DEBUG_SPINLOCK le développeur sait s'il fait un unlock sur un mutex qui n'est pas locké ou sur un mutex créé depuis un autre processus mais dont on n'a pas mis le flag pour l'utiliser en inter-processus, etc... (Je dis peut-être des conneries ici, je n'ai pas vérifié dans le détail).
Génial tout ça !
Le problème est d'évaluer la contre partie. Pour une utilisation de mysql comme dans le bench de ce journal, la contre partie est intolérable (en imaginant que le problème vient de DEBUG_SPINLOCK, je n'en ai pas la preuve, je me suis hazardé dans une explication). Mais si la contre partie est en général une perte de performance de 0,01 %, et que DEBUG_SPINLOCK permet aussi aux développeurs d'appli de développer plus vite, alors DEBUG_SPINLOCK est (peut-être) justifié.
Pour les quelques cas où la contre partie est intolérable, il suffit de recompiler le noyau (les sources c'est aussi fait pour ça).
Notes que FC6 est sorti depuis plusieurs mois et c'est la première fois que CONFIG_DEBUG_SPINLOCK fait parlé de lui.
Un mot sur ce bench. Linux/Fedora a de moins bon résultat que FreeBSD pour un bench et pour un système à 8 cpus (seulement 1 à ce jour).
Et si le bench n'était pas représentatif ?
Et si le bench (ou mysql) avait un bug spécifique pour Linux qui n'impacte pas FreeBSD ? Ce n'est pas exactement le même code (il y a des #ifdef Linux etc..).
Se sont aussi des hypothèses à creuser. Quoique personnellement je ne chercherai pas là en premier. Même si le test est buggé il faut comprendre pourquoi Linux/Fedora s'écroule en monté en charge.
> Ne me dit pas que ce serait une manière d'utiliser Fedora comme une version beta de RHEL et ce au détriment des performances des utilisateurs de Fedora ! Non ce serait trop machiavélique.....
Pour le troll fait en voulant nous faire croire que tu ne veux pas troller (alors que ce n'est pas la première fois que tu le fais...).
Les CONFIG_DEBUG de RHEL 4 (noyau 2.6.9, dernière mise à jour) :
CONFIG_DEBUG_HIGHMEM=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_DEBUG_STACK_USAGE=y
Pour info, RHEL 5 en cours de développement utilise et utilisera un 2.6.18 (compatibilité binaire/source de RHEL oblige). FC6 a actuellement un 2.6.19 (le 2.6.20 ne devrait pas tarder) et la branche de développement de Fedora est en 2.6.20.
> ce serait une manière d'utiliser Fedora comme une version beta de RHEL et ce au détriment des performances des utilisateurs de Fedora !
Comme tu pourrais dire ça pour Mandriva "classique" et Mandriva Corporate Server, etc...
Comme on pourrait dire qu'Ubuntu débuggue RHEL. Et oui, il y a des paquets dans Ubuntu qui seront dans RHEL. Tous les bug trouvés dans Ubuntu (idem pour Mandriva, Fedora, OpenSuSE, etc) profitent à RHEL (et aussi à Debian Etch :-))
Ta remarque est tout simplement ridicule, grotesque et il serait bon que t'arrêtes.
Et notes qu'en moyenne il n'y a qu'une Fedora sur 3 qui est utilisée comme base de RHEL :
RHEL 3 => RH9
RHEL 4 => FC3
RHEL 5 => FC6
Les bugs corrigés en phase de test de RHEL 5 sont repportés sur FC6 (et la branche développement) et aussi en upstream (Red Hat est très impliqué en upstream). Donc, ce n'est pas à sens unique. Ça profite à tout le monde.
Pourquoi RHEL 5 sort après FC6 tu vas demander. Excellente question.
FC6 n'a pas de partenaire. Pour sortir elle n'a pas besoin d'attendre que Dell ait vérifié que FC6 marche sur ses bécanes, elle n'a pas besoin d'attendre la certification d'Oracle, elle n'a pas besoin d'attendre que des formations pour l'administrer soient mise en place, etc...
FC6 n'est pas supportée (via de l'argent, un contrat entre un client et un fournisseur) et n'est pas destinée aux missions critiques où le moindre de bug est un scandale. Son contexte lui permet de sortir rapidement, ce qui fait le bonheur de beaucoup d'utilisateur qui veulent des trucs "flashy", et ce qui fait aussi le bonheur des développeurs qui peuvent se concentrer sur la version à venir au-lieu de buller car l'équipe de documentation n'a pas fini son taff (NB : la doc de RHEL est libre).
Tu trouves peut-être scandaleux le prix de RHEL ? RHEL étant un produit basé sur du libre et sur une distribution qui demande la contribution de la communauté.
Pas de problème, il y a Centos (et d'autres) pour toi : http://www.centos.org/
C'est un clone de RHEL (recompilation des sources de RHEL disponibles sur http://ftp.redhat.com/ et ses mirroirs), et je ne doute pas que Centos 5 va sortir au pire 2 semaines après la sortie de RHEL 5.
Donc Fedora (gratuite) donne RHEL (payante) qui donne Centos (gratuite). Pas de problème, la boucle est bouclée et l'argent de RHEL est utilisé pour développer Fedora (gratuite) et Centos (gratuite).
Notes que Red Hat ou Fedora n'a rien contre Centos. Par exemple le projet Extras Packages for Entreprise Linux :
http://fedoraproject.org/wiki/Extras/Schedule/EnterpriseExtr(...)
Suis les liens et tu verras que tout est fait pour que ça marche aussi pour Centos et autres clones d'RHEL.
La communauté du libre a déjà assez à faire pour combattre les FUD de MS contre le logiciel libre. Voir par exemple : http://showusthecode.com/ .
Moi, et la communauté du libre, on se passerait volontier des FUD qui viennent de supporter du libre contre RHEL/Fedora qui est du logiciel libre. RHEL finance Fedora pour développer des technologies qu'on retrouve par exemple dans Mandriva (voir le buzz qu'il y avait pour AIGLX développé principalement par Fedora). RHEL finance aussi Centos qui est gratuit.
A bon entendeur...
PS : je le répète, je ne sais pas si le problème vient de CONFIG_DEBUG_SPINLOCK. J'ai dit qu'il est probablement que l'essai qu'a fait FreeBSD avec un 2.6.20.1 vanilla (sans patch Fedora) soit fait avec CONFIG_DEBUG_SPINLOCK. Mais j'en ai pas la preuve. Donc pour l'instant on ne sait pas que ça vient de CONFIG_DEBUG_SPINLOCK. J'ai seulement émis cette hypothèse.
[^] # Re: Re:
Posté par patrick_g (site web personnel) . Évalué à 3.
Il suffisait que tu m'indiques (comme tu le fait au milieu de ton post) que même la RHEL avait les options de debug actives.
Ce simple fait invalide complètement mon raisonnement.
L'agressivité de ton post te dessert je pense alors qu'il te suffisait de me moucher en postant la CONFIG_DEBUG de RHEL.
Keep cool ;-)
[^] # Re: Re:
Posté par IsNotGood . Évalué à 5.
Mais ça flirt avec le coup de chance.
Tu as peut-être remarqué que FC6 a deux ou trois CONFIG_DEBUG de plus que RHEL. Il y a des CONFIG_DEBUG qui sont ajoutés effectivement pour débugguer car un bug n'a pas été corrigé. Ça arrive quand en phase de test l'existance d'un bug ne fait pas de doute mais que les développeurs Red Hat n'arrivent pas à savoir où il se cache et comment il se déclenche. Ce type de bug touche en général peu de bécane/configuration. Il est raisonnable compte tenu des objectifs de Fedora (le développement rapide de GNU/Linux) d'activer des options de debug, ainsi les développeurs récoltent plus d'information et peuvent corriger le bug.
L'autre cas est quand il faut faire le "grand saut". Par exemple lorsque Fedora est passé à ACPI. On sait que ça va merder car il y a un nombre considérable de configuration, mais corriger le tout uniquement en phase de test (donc avec une poingnée de testeur) peut prendre des plombes pour ne pas dire que c'est quasi impossible. Fedora n'a pas la base de testeurs de Windows par exemple (via les beta testeurs, les fabricants de hardware, etc...). Ce type de démarche reste exceptionnel et murement réfléchi. Par exemple par deux fois acl était activé en phase beta mais désactivé pour la version finale. Acl n'était pas assez mûr pour le "grand saut". Pour ACPI et SeLinux c'est arrivé une fois. Fedora n'a pas laissé les choses activés en espérant les débugguer avec les utilisateurs. Fedora le fait, mais c'est exceptionnel et mûrement réfléchi.
Alors oui, Fedora aura souvent plus de CONFIG_DEBUG d'activé que RHEL. Mais qui fait avancer le logiciel libre ? Fedora ou RHEL ? Ben c'est Fedora. RHEL fait le financement.
Maintenant prend le problème d'une autre façon. Considère qu'il n'y a pas RHEL (imagine qu'il y a un généreux milliardaire pour financer Fedora) et considère les objectifs de Fedora. Crois-tu que Fedora n'aurait jamais de bonne raison d'activer des CONFIG_DEBUG même pour la version finale ? Les raisons précédentes que j'ai donné sont toujours valides.
Autre façon de regarder le "problème". Considère qu'il n'y a que RHEL et pas de Fedora (pourquoi pas puisque Red Hat ne fait pas d'argent avec Fedora). Ta critique tombe définitivement à l'eau. Mais crois-tu que le logiciel libre y gagne ? Crois-tu que l'influence de la "communauté" du libre y gagne ?
Je ne vais pas nier la liaison entre RHEL et Fedora. Elle est affichée. Par exemple SeLinux a été mis dans Fedora non à l'initiative de Fedora ou de la communauté mais car Red Hat voulait SeLinux dans RHEL. Idem pour Xen. Le libre y a gagné. Mais je crois que Red Hat en a un peu rien à foutre d'avoir AIGLX dans RHEL, et RHEL ne serait pas passé à yum s'il n'y avait pas Fedora. Mais c'est Red Hat qui finance Fedora (et presque massivement) en plus d'être le plus gros contributeur. Donc il est normal que Red Hat ait son mot à dire. Et si Red Hat n'a pas son mot à dire, Red Hat ferme Fedora car il n'y gagne rien (ou trop peu) et le libre y perd.
Red Hat a trouvé un modèle sympa, gagnant-gagnant, entre le business et le libre. Tant mieux et je dois dire que ça m'énerve de le voir critiqué. Ce modèle est un compromis, et comme tout compromis perfectible lorsqu'on le regarde sans recul. Ce modèle a été repris par Sun (OpenSolaris/Solaris) et par Novell (OpenSuSE/Novell). Ce modèle n'est pas une révolution. Il couvait depuis un moment. Il est judicieux.
Certes Fedora et RHEL ont DEBUG_SPINLOCK. Mais avant tout un développeur Red Hat va regarder ce problème (qu'il existe ou non dans RHEL). Ce n'est peut-être pas dans son top10, mais les performances de Fedora ne sont pas négligées. Et lorsque le problème sera corrigé, la correction sera dans Fedora ET dans Linux (il y a aussi ce problème avec un noyau vanilla).
Fedora n'est pas un projet annexe de Red Hat. Red Hat communique sur Fedora (il y a un lien sur toutes les pages de http://www.redhat.com/ ) et il y a toujours au moins un article sur Fedora dans Red Hat Magazine. Un article récent et sympa :
http://www.redhatmagazine.com/2007/02/15/professional-audio-(...)
D'autres articles : http://www.redhatmagazine.com/category/fedora/
Si Red Hat communique sur Fedora, il est claire que Red Hat ne veut pas que Fedora soit un produit pourri même si Red Hat obtient de Fedora ce qu'ils veulent pour RHEL.
J'arrête mon verbiage insupportable.
[^] # Re: Re:
Posté par Laurent A. . Évalué à 1.
[^] # Re: Re:
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 3.
[^] # lui proposer ?
Posté par gasche . Évalué à 3.
Ta remarque paraît pertinente, et jusqu'à présent il s'est montré tout à fait prêt à tester d'autres configurations pour améliorer son benchmark. S'il n'est pas déjà au courant, ton hypothèse l'intéressera sûrement.
[^] # Re: lui proposer ?
Posté par IsNotGood . Évalué à 2.
Je ne suis pas de son niveau (vraiment pas) et je préfère m'effacer. On ne boxe pas dans la même catégorie :-)
[^] # Re: lui proposer ?
Posté par Thomas Douillard . Évalué à 2.
[^] # Re: lui proposer ?
Posté par lasher . Évalué à 5.
Par contre, si Red Hat reconnaît qu'effectivement il a levé un lièvre, il n'y a plus qu'à s'écraser, non ?
[^] # Re: Re:
Posté par Matthieu Lemerre . Évalué à 3.
Pour donner un exemple, imaginons qu'un thread (a) prenne un mutex et que son timeslice se termine avant qu'il le deverouille; sous Linux (on me corrigera) mais a priori tout le monde est bloque tant qu'il est pas reveille.
Avec les scheduler activations, il est possible qu'un autre kernel thread (b) qui attendait pour le mem lock reprenne l'execution du thread (a) la ou elle en etait, jusqu'a ce qu'il sorte du lock; et la continue l'execution normale du thread (b). D'ou des excellents temps de latence a attendre le lock.
Attention, ce mecanisme de scheduler activation est tres judicieux pour un programme multithread au sein d'un meme espace d'adressage; on ne peut pas faire ca pour des threads situes dans des processus differents.
# Progress on scaling of FreeBSD on 8 CPU systems
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 4.
http://people.freebsd.org/~kris/scaling/mysql.html
# Mauvaises conclusions
Posté par herodiade . Évalué à 10.
N'oubliez pas que ce test est mené par un développeur noyau de FreeBSD pour qui le plus important est de valider la pertinence de ses patches/améliorations : à mon avis, il exécute aussi ce test sur Linux pour donner une référence. Après tout, c'est logique : Linux est connu pour être la plateforme dont mysql tire le meilleur profit : si on se comporte aussi bien que lui, c'est qu'on est au point. L'auteur a conscience que l'optim de Linux n'est pas son domaine de compétences : et que le test n'est pas suffisamment « fair » pour établir une telle comparaison définitive entre OSes (différentes versions de mysqld), mais ce n'est pas son objet.
Bref, ce test a seulement pour vocation de vérifier que FreeBSD + ses patches se comporte suffisamment bien, et c'est d'ailleurs tout ce que conclus jeffr, loin des trolls évoqués dans ce journal : .
Ce que l'on devrai conclure de ce benchmark, c'est que FreeBSD 7 supporte bien les montées en charge (au moins celle produite par MySQL), même lorsqu'on le compare a une excellente plateforme. Et c'est seulement ce que l'auteur cherchait à savoir.
[^] # Re: Mauvaises conclusions
Posté par IsNotGood . Évalué à 10.
Je pense que le testeur est « fair » . Ce qui n'est pas juste est qu'il connait moins bien Linux que FreeBSD. Mais on ne peut pas tout connaitre.
Il lui a été demandé de tester avec la dernière mise à jour de Fedora, il l'a fait. De tester avec un 2.6.20.1, il l'a fait. De tester avec la même version de Mysql pour FreeBSD et Linux, il l'a fait aussi. Il a été très coopératif pour quelqu'un qui ne travail pas pour Linux.
Sans plus d'élément, la conclusion est : Linux/Fedora c'est pris une branlée par FreeBSD. Ce sont des choses qui arrivent.
Maintenant c'est à Linux de chercher ce qui sucks et de remercier jeffr_tech d'avoir trouvé un lièvre.
On peut relativer et dire que ce n'est qu'un bench sur une bécane, mais le fait est là.
[^] # Re: Mauvaises conclusions
Posté par herodiade . Évalué à 10.
Je crois d'aileurs que le post suivant dans son blog confirme mon interprétation anti-trollistique (http://jeffr-tech.livejournal.com/ ) :
Ce que je résumerai par : « soyons constructifs ».
[^] # Re: Mauvaises conclusions
Posté par Bapt (site web personnel) . Évalué à 5.
http://jeffr-tech.livejournal.com/6602.html
[^] # Re: Mauvaises conclusions
Posté par IsNotGood . Évalué à 3.
http://marc.theaimsgroup.com/?t=117242608500003&r=1&(...)
C'est "fun". Il semble que Mysql a aussi quelques bugs. Il y a un développeur Novell et un développeur Red Hat sur l'affaire.
# matos
Posté par bandedepinpins2 . Évalué à 0.
# Problème trouvé
Posté par IsNotGood . Évalué à 5.
http://ozlabs.org/~anton/linux/sysbench/
Le résultat est quasi parfait maintenant.
Un patch pour glibc qui résoud peut-être ce problème existe mais n'a pas encore été testé :
http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/malloc/mal(...)
Notons que MySQL n'est pas très "clean". Il fait des malloc() free() dans des sections critiques. M'enfin, Linux n'était pas bon par rapport à FreeBSD dans ce cas il y fallait une correction. C'est en bon voix maintenant.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.