Deux articles dignes d'intérêt qui tentent de comparer les performances de MySQL sous divers OS (Linux 2.4; Linux 2.6; FreeBSD 5.3; FreeBSD 4.11; NetBSD 2.0; OpenBSD 3.6; Solaris 10).
L'auteur a l'air particulièrement sérieux et compétent (le premier article décrit uniquement les préparatifs et le protocole de test et le second présente les résultats).
http://software.newsforge.com/article.pl?sid=04/12/27/1238216&t(...)
http://software.newsforge.com/article.pl?sid=04/12/27/1243207&t(...)
Conclusions à la louche pour les non-anglophones et les décideurs pressés =>
1) Linux roxor et écrase tout sur son passage.
2) Le kernel 2.4 n'est pas si loin du 2.6.
3) Solaris est bon aussi mais il faut savoir tuner.
4) NetBSD est le meilleur des BSD mais il est mauvais en SMP.
5) Les BSD avec la bibliothèque de thread de Linux sont meilleurs qu'avec la lib native.
6) Confirmation des problèmes de FreeBSD qui est encore un OS en chantier.
Journal La guerre des OS
11
fév.
2005
# Précisions
Posté par scand1sk (site web personnel) . Évalué à 10.
Ces benchmarks ont été réalisés uniquement sur MySQL. Il est tout à fait possible qu'en utilisation autre (serveurs de fichiers, multimedia...) les résultats soient tout autres.
[^] # Re: Précisions
Posté par jerome (site web personnel) . Évalué à 10.
Bref, ya vraiment pas mal de facteurs de variabilité.
Ya quand même des lâchage de tr^W^W^W^W^Wconclusions sympathiques auxquel(le)s je ne peux résister :
. les Unix libres tiennent bien la dragée haute à Solaris (bon, c'est ptet presque libre de nos jours mais quand même),
. FreeBSD, c'était mieux à vent,
. NetBSD 2.0, ça ownzor FreeBSD avec une main dans le dos,
. OpenBSD, comme les autres BSD, ça sait pas se servir d'un biproc,
. Linux, ben comme d'hab, ça "just works".
Bonne lecture, mais vous êtes invités à troller direct.
(PS: merci patrick_g de lâcher ça avant midi histoire de pouvoir en profiter pleinement au retour du déjeuner).
[^] # Re: Précisions
Posté par scand1sk (site web personnel) . Évalué à 6.
[^] # Re: Précisions
Posté par jerome (site web personnel) . Évalué à 1.
Je pense que dans le cadre du benchmark, le chooix du FS peut quand même avoir une importance non négligeable, mais en effet cela sera particulièrement sensible au moment de faire des vacuum, d'écrire beaucoup de données d'un seul coup, un gros BLOB, ou plein de petites entrées en grand nombre, bref ...
[^] # Re: Précisions
Posté par Volnai . Évalué à 1.
Si quand même. Et beaucoup, une base de donné avec la meme taille de block que le filesystem sous-jacent, ca change enormément de chose.
[^] # Re: Précisions
Posté par fabb . Évalué à 2.
Ça dépend. Pour l'écriture certaines opérations requièrent un flush pour l'intégrité des donnée et donc attente de l'écriture sur le disque (on est donc dépendant du FS).
Certains FS sont un peu "léger" et ne garantissent pas l'ordre d'écriture lors d'un flush. C'est plus rapide mais il y a des risques de corruptions potentiels.
La capacité du FS à ne pas fragmenter est importante pour les performances. Sur Linux 2.6.10 est apparue ext3-reservation pour améliorer ext3 sur ce point (gain très significatif sous forte charge avec plusieurs opérations d'écriture à la foi).
[^] # Re: Précisions
Posté par patrick_g (site web personnel) . Évalué à 3.
Sinon pour les Linuxthreads sous FreeBSD il le teste aussi avec KSE. (effarant quand même de voir cet OS se faire démolir par tout ses concurents alors que la nouvelle version est en chantier depuis des années et qu'elle avait été annoncée comme THE THING !)
Enfin (même si on est bien d'accord que c'est juste un test de MySQL et que les conclusions sont certainement différentes pour d'autres applis) je suis un poil déçu du peu d'écart entre le kernel Linux 2.4 et le 2.6.
A mon avis la différence doit être beaucoup plus évidente avec 4 CPUs ou sur des applis multimédias.
# windows...
Posté par Nicolas Boulay (site web personnel) . Évalué à 10.
"La première sécurité est la liberté"
[^] # Re: windows...
Posté par Christophe Morvan (site web personnel) . Évalué à 4.
Mais puisque le monsieur te dit qu'il parle d'OS... essaie de suivre un peu.
;o))
[^] # Re: windows...
Posté par gc (site web personnel) . Évalué à 10.
[^] # Re: windows...
Posté par Psychofox (Mastodon) . Évalué à 8.
l'humour n'a plus droit d'être évalué sur linuxfr ?
[^] # Re: windows...
Posté par _Mekare_ . Évalué à 2.
# Désolé pour les trolls
Posté par Jerome Herman . Évalué à 10.
While some of the operating systems had precompiled or ready-to-compile BSD ports of MySQL available, many were slightly older versions of MySQL (4.0.20 for example) and compiled with a variety of different options which presented problems with consistency. After all, I'm testing the operating systems, not their pre-packaged MySQL distributions or source builds.
Traduction : alors que certains OS ont des ports BSDs précompilées our prètes à compiler de MySQL disponibles, beaucoup étaient légèrement plus anciennes (4.0.20 par exemple) et compilées avec une variété d'options différentes ce qui posait un problème de cohérence. Après tout je teste les OS et non leurs sources préparées ou leurs paquets MySQL.
En clair ca donne :
J'ai laissé la gestion des threads, des priorités et de la mémoire de base, parceque je trouve çà plus juste et plus cohérent pour un benchmark d'OS.
Au final on se retrouve avec un OS qui a une gestion des threads et de la mémoire adaptée a son fonctionnement (Linux) et les autres qui sont obligés de batailler avec des modes de compatibilté, des couches d'émulation et tutti quanti.
Le simple fait que l'émulation de threads Linux tourne plus vite sous FreeBSD que les threads natifs auraient du mettre la puce à l'orreille.
MySQL est un des ports les plus patchés sous les *BSD. Généralement il y a au moins les MIT-Pthreads sinon l'OS en prend plein la tête au niveau synchronisation des threads.
il y a aussi beaucoup à dire au niveau de la gestion des fichiers partagés en mémoire (mmap et consors) .
Au final la conclusion que l'on peut tirer de ce benchmark est que MySQL via les APIs système "façon Linux" est beaucoup plus rapide sur Linux que sur *BSD. Le contraire eut été surprenant.
[^] # Re: Désolé pour les trolls
Posté par patrick_g (site web personnel) . Évalué à 3.
Pourquoi Linux peut-il bien gérer un MySQL fraichement downloadé et compilé alors que les BSD en sont incapables ?
Est-ce parceque MySQL n'est que très peu portable et est conçu spécifiquement pour Linux ?
Bon même si le bench est foireux par rapport à Linux (j'attends quand même d'autres avis éclairés) on peut comparer les BSD entre eux.
[^] # Re: Désolé pour les trolls
Posté par nigaiden . Évalué à 8.
Sinon moi aussi je peux faire ce genre de tests (OpenOffice.org, Mozilla et Java tournent mieux sous Windows que sous Linux) et arriver à des conclusions trollesques (Windows roxor, Linux à la poubelle).
[^] # Re: Désolé pour les trolls
Posté par Jerome Herman . Évalué à 8.
Est-ce parceque MySQL n'est que très peu portable et est conçu spécifiquement pour Linux ?
Sans aller jusqu'à dire que MySQL est "optimisé" Linux, on peut dire que les versions de MySQL 1 à 4 ont été concues avec Linux en tête. Lors de la configuration de la compilation MySQL vérifie et éventuellement active tout un tas d'options qui n'existent ou ne sont vraiment efficaces que sous Linux. Celà ne veut en aucun cas dire qu'il n'est pas portable, cleà veut juste dire que si le configure par défaut ne se trouve pas face à un Linux il va se rabattre sur des programmes et des bibliothèques moins efficaces alors que des alternatives BSD existent. Une des exemples les plus flagrants est la gestion des mutexs pour les locks, MySQL génére un grand nombre de locks et de retraits de locks, sous Linux l'impact est quasi-nul car les mutexs créés apr défauts sont en mode "fast" mais sous BSD la méthode employée par défaut oblige le système à rescanner tout le contexte. C'est aussi pour çà que l'on perd des performances lors du passage en multiprocesseur, une partie du contexte est doublé pour que l'on puisse passer le thread d'un CPU à l'autre, mais si il y a un lock sur le thread un seul des deux CPUs peut faire le check du contexte. Moralité chaque "unlock" coute (nombre de CPU)*(overhead du contexte par CPU) en plus. Vu les rafales que balance MySQL ca chiffre très vite.
Il semble cependant que la version 5 cherche à corriger le tir.
Bon même si le bench est foireux par rapport à Linux (j'attends quand même d'autres avis éclairés) on peut comparer les BSD entre eux.
Si tous les mutex par défauts étaient égaux oui. Mais poru avoir uen idée précise il vaudrait quand même mieux remplacer toutes les demandes de créatiosn de mutex par défaut par des demandes de création de mutex "le plus rapide possible" en fonction de l'OS.
[^] # Re: Désolé pour les trolls
Posté par gc (site web personnel) . Évalué à 2.
Un idiot te répondrait : "ben pourquoi les mutex sont "rapides" par défaut sous Linux et lents par défaut sous BSD ? après tout c'est aussi ce qu'un bench est censé montrer : les performances pour effectuer des opérations ; si les gens de BSD s'amusent à utiliser des mutex lents ils ont des mauvais résultats au bench et c'est normal".
Et vue que je suis un idiot sur ce sujet, hop c'est ce que je te réponds. Peut-être tu peux nous donner plus d'informations sur ces mutex "rapides" et "lents". Le problème vient-il du fait qu'il n'y a pas d'appel standardisé Unix pour manipuler les mutex efficacement, et que mysql en utilise un qui est performant sous Linux mais pas sous BSD (il en aurait choisi un autre ça aurait pu être le contraire) ? Si tel est le cas, on peut aussi se demander pourquoi un logiciel aussi utilisé et qui n'est plus tout jeune n'utilise toujours pas un appel plus performant lorsqu'il est compilé pour BSD ?
[^] # Re: Désolé pour les trolls
Posté par Jerome Herman . Évalué à 9.
Les mutexs "rapides" sont une spécificité non portabl des linux threads. C'est une façon de faire qui n'ets pas conforme au standard Posix.
Une façon courte d ete répondre serait la suivante : Sous Linux il n'y a pas 36 façons d'intialiser un mutex et le lier aux fonctions de lock d'un ou plusieurs threads, sous BSD il y en a des quintaux.
Au final sous linux la méthode par défaut est pas très optimisée coté thread masi elle s'appuie sur des spécifité du système Linux qui la rende rapide au final (mais impossible à porter). Sous BSD on a toute la panoplie et on peut régler les Pthreads et les mutexs au millimètre, par contre si on ne fait pas les réglages soit même le système préfère ne pas prendre de risque et utilise des valeurs "passe partout" qui ne sont pas d'une éfficacité redoutable.
Au final MySQL a un comportement très attypique (des locks et des unlocks en rafales en 50) . La politique "safe" de BSD lui retombe donc sur le nez. L'équipe MySQL AB aurait du passer plsu de temps à peaufiner l'utilisation des threads natifs des différents BSD...
[^] # Re: Désolé pour les trolls
Posté par patrick_g (site web personnel) . Évalué à 6.
c'est toujours : "oui mais vous avez pas pris la dernière version"
ou encore : "oui mais vous avez pas optimisé le schmilblick"
ou bien : "cette appli de test que vous utilisez est atypique"
Ca commence a me brouter cette impossibilité absolue de tester quoi que ce soit dans le monde des OS !
On a eu droit aux mêmes plaintes lors du test lors de la sortie de NetBSD => les mecs de FreeBSD (qui se faisait éclater par NetBSD) ont raconté que le bench était juste un ensemble de routines de bas niveau alors que leur OS était optimisé pour le travail réel sur des applis réelles.
On croirait se retrouver dans le monde des opérateurs de téléphone portable : les formules d'abonnement sont concus pour empêcher toute comparaison tarifaire entre Orange ou SFR ou Bouygues.
Putain on teste des OS ici ! c'est pas comme si on sondait l'âme immatérielle des anges ! c'est un domaine technique et il doit bien exister des tests techniques pour les différencier objectivement non ?
[^] # non
Posté par Antoine Reilles (site web personnel) . Évalué à 3.
Tu fais un protocole de tests, tu le valides, tu fais le bench, mais au final, tu as seulement montre que pour *ce* bench, untel est meilleur que untelautre. Et encore, l'interpretation des resultats peut encore donner lieu a debat, meme si tu as bien paufine ton protocole te tests.
ca serait trop facile sinon
[^] # Re: non
Posté par gnujsa . Évalué à 2.
$ ( xterm -e emacs -nw & ); ( xterm -e vim --noplugin -u /dev/null & ); sleep 5; ps -eo 'fname rss' | tail -4
emacs 5428
vim 3704
ps 684
bash 1720
;-)
[^] # Re: Désolé pour les trolls
Posté par Volnai . Évalué à 2.
Bienvenu dans le monde réel.
c'est un domaine technique et il doit bien exister des tests techniques pour les différencier objectivement non ?
Pour les differencier, oui (ce becnhmark par exemple). Par contre il n'y en a pas pour dire lequel est le meilleur "partout et tout le temps"
[^] # Re: Désolé pour les trolls
Posté par kesako . Évalué à 4.
non
parcequ'un OS est affaire de compromis.
exemple : les compromis que l'os doit faire sur :
le scheduler
la memoire virtuelle
le systeme de fichier
les threads et les process
la portabilité
meme chose pour les cartes graphiques et leur drivers.
Pour tout systeme complexe c'est la meme chose. Ex les moteurs a pistons : les compromis ne sont pas les memes pour le moteur d'une voiture, d'un camion et d'un avion de tourisme.
Les comparaisons ne sont donc jamais objectives. Pour la plus grande joie des commerciaux.
[^] # Re: Désolé pour les trolls
Posté par Jerome Herman . Évalué à 6.
Et bien réjouis toi, il est possible de tout tester dans le monde des OS. A part l'OS.
Tenter de comparer deux OS revient à peu de choses près à tenter de comparer deux boites à outils. A la question "Quelle est la meilleure boite à outils, celle du maçon ou celle du vitrier ?" la seule réponse possible est "Ca dépend, vous voulez poser des vitres ou ravaler une façade ?"
La première question à se poser quand on veut créer un test est de définir très clairement ce que l'on veut mesurer. La dernière question à s epsoer quand on a fini un test est de comprendre précisément ce que l'on a mesuré.
L'auteur de ce bench part avec l'idée de comparer globalement des OS entre eux (ce qui pour les raisons vus plus haut n'est pas particulièrement pertinent) et fini par comparer les performances ) et fini en comparant le sperformances de MySQL sous différents OS. Au final la question auquel on répond est donc : Quel est l'OS le plus adapté pour faire tourner MySQL sur la config matérielle du testeur'. Et la réponse que l'on obtient n'est pas valable parcequ'une personne qui ferait ces tests dans le but d'utiliser MySQL (typiquement un responsable informatique qui doit prendre une décision système) prendrait probablement des versions compilées/patchées pour tirer parti au maximum du matériel et de l'OS . Ici le testeur prend la version générique qui, pour les raisons vues plus haut, favorise grandement les OS Linux.
Donc a moins d'avoir une bonne raison pour garder la version 'vanilla' (et je n'en vois pas vraiment) le bench n'apporte donc pas grand chose au final.
[^] # Re: Désolé pour les trolls
Posté par fabb . Évalué à 0.
Là c'est pour mysql uniquement et pour une version spécifique. Ce n'est pas une comparaison :
- *BSD/Mysql
- Win/SQLServer
qui conclus que Win (ou *BSD) est plus rapide.
> Quel est l'OS le plus adapté pour faire tourner MySQL
Ou : quel est le meilleur OS pour utiliser MySQL (en terme de performance).
> favorise grandement les OS Linux.
J'ai regardé les sources, ça ne va pas bien loin (sauf pour les mutex). Normal.
Je doute que ça justifie un tel écart de performance.
Ce n'est pas la première foi que les *BSD se font "bouffés" par Linux :-)
[^] # Re: Désolé pour les trolls
Posté par Jerome Herman . Évalué à 4.
Oui mais quand on voit le nombre d'accés en lock et unlock sur les mutexs, ca suffit très largement.
Ce n'est pas la première foi que les *BSD se font "bouffés" par Linux :-)
Certes, mais comme Linux se fait bouffer par MS-DOS c'est pas grave.
[^] # Re: Désolé pour les trolls
Posté par fabb . Évalué à -1.
T'es sûr ?
Avec Linux 2.6 et glibc > 2.3.? c'est nptl par défaut. Et nptl veut dire Native POSIX Thread Linux. Ça suit le norme Posix :
http://people.redhat.com/drepper/(...)
NB : linuxthread (pour les sources et être portable) suit aussi la norme Posix.
Ceci dit, j'ignore si durant le test c'est nptl ou linuxthread qui a été utilisé. Même s'il y a Linux 2.4 (non-nptl) et Linux 2.6, normalement si l'appli est compilé pour nptl (auto-détection), elle switche automatiquement vers linuxthread si c'est linux 2.4 qui est utilisé.
En gros, le test montre qu'il n'y a pas de différence entre linuxthread et nptl pour ce test :-)
[^] # Re: Désolé pour les trolls
Posté par Jerome Herman . Évalué à 2.
MySQL 4.x utilisera systématiquement LinuxThreads sous Linux, et fera appel aux fonction non portables sur les fasts mutexs .
MySQL 5.x par contre a corrigé le tir comme je le disais, et utilisera bien le NTPL
NB : linuxthread (pour les sources et être portable) suit aussi la norme Posix.
Il suffit de regarder le nombre de signaux en _NP (non portable) pour se rendre compte que la norme n'est pas suivi de très très près. Généralement ce sont des ajouts en plsu de la norme, mais dnas le cas des mutexs (pour l'init notamment) il y a des manques.
normalement si l'appli est compilé pour nptl (auto-détection), elle switche automatiquement vers linuxthread si c'est linux 2.4 qui est utilisé.
Certes mais là l'appli est écrite pour linuxthreads à la base. Sinon il n'y aurait aucun problème. Les NTPL Linux sont quasi identiques aux Pthreads natifs BSD (avec quand même un ou deux gags sur l'ordre des bits et les pids parfois).
[^] # Re: Désolé pour les trolls
Posté par fabb . Évalué à -1.
Il y n'a aucun doute que MySQL utilise nptl ici. Linké avec -lpthread, reconnu lors du "./configure", HAVE_LIBPTHREAD est défini mais aussi HAVE_LINUXTHREAD.
Les includes systèmes sont des includes qui donnent aussi les fonctionnalités spécifiques de linuxthread et il y a sûrement un minimum de compatibilité fournit par nptl et on peut peut-être (sûrement?) utiliser certaines (toutes?) caratéristiques de linuxthread avec nptl.
> MySQL 5.x par contre a corrigé le tir comme je le disais, et utilisera bien le NTPL
Je ne doute pas que mysql 4.1.9 utilise nptl (au moins ici). Mais en regardant les sources il y a effectivement utilisation de fonctionnalités spécifiques à linuxthread.
De "loin" (car je n'ai pas assez de compétence), mysql est codé pour linuxthread (pour la cible linux) mais utilise nptl car nptl est compatible linuxthread.
Bref, j'ai la vive sensation que tu as raison (dépence de Mysql à linuxthread actuellement). Désolé pour la confusion.
[^] # Re: Désolé pour les trolls
Posté par Jerome Herman . Évalué à 1.
NTPL et LinuxThreads sont mutuellement exclusifs. On ne peut utiliser qu'un des deux à la fois (notament pour des raisons de gestions des PIDs). Les deux optiosn qui défilent ne font que signifier que le configure a trouvé que le système supportait les PThreads et qu'il a trouvé la bibliothèque LinuxThread.
NTPL n'est jamais utilisé.
[^] # Re: Désolé pour les trolls
Posté par fabb . Évalué à 1.
Pas d'accord et au moins pour ça :
http://people.redhat.com/drepper/assumekernel.html(...)
The code in /lib/tls is the new NPTL POSIX thread library.
$ ldd /usr/libexec/mysqld | grep thread
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00cf4000)
$ LD_ASSUME_KERNEL=2.4.1 ldd /usr/libexec/mysqld | grep thread
libpthread.so.0 => /lib/i686/libpthread.so.0 (0x00c76000)
[^] # Re: Désolé pour les trolls
Posté par Jerome Herman . Évalué à 3.
Au 16 juin 2004
We only support Linux glibcs with LinuxThreads for now
as we have experienced server lockups with NPTL.
That's why we check for the string "Linuxthrads" being
present in the header file.
A warning from configure about NPTL not being support
might be better though in this case instead of just
insisting on Linuxthreads.
source : http://bugs.mysql.com/bug.php?id=2173(...)
Sur la version 4.1.7 de MySQL, le bug est toujours actif.
On retrouve pas mal de rapprots de bugs sur NPTL, notamment dans les forums Debian, avec des patches qui ont été inclus dans les paquets standards Debian.
Je ne vois aucune trace de correction de la gestion des threads par defaut dans les changelogs de MySQL (qui sont très succint ). Peut-être que MySQL 4.1.8 et 4.1.9 peuvent linker de façon fiable sur NPTL ....
[^] # Re: Désolé pour les trolls
Posté par fabb . Évalué à 0.
Ici j'ai :
/usr/include/pthread.h (linuxthread)
/usr/include/nptl/pthread.h (nptl)
Dans 99 % des cas, c'est /usr/include/pthread.h qui est utilisé.
linuxthread est une implémentation de la norme Posix 1003.1c :
http://pauillac.inria.fr/~xleroy/linuxthreads/(...)
et jouer avec ce qui est spécifique à linuxthread ou nptl est rare.
> On retrouve pas mal de rapprots de bugs sur NPTL, notamment dans les forums Debian,
Sous Red Hat/Fedora et depuis RH9 nptl est utilisé par défaut :
http://fr2.rpmfind.net/linux/redhat/9/en/os/i386/RELEASE-NOTES.html(...)
This thread library is designed to be binary compatible with the old LinuxThreads implementation; however, applications that rely on the places where the LinuxThreads implementation deviates from the POSIX standard will need to be fixed
Donc, comme je le supposais plus haut, nptl est compatible linuxthread.
Il n'y a que deux façon d'utiliser linuxthread avec RH9 ou > :
- linker directement (en dure) avec /lib/i686/ ou /lib (par défaut c'est linké avec /lib/tls).
- utiliser la variable d'environnement LD_ASSUME_KERNEL
En pratique toutes les applis (à 99%) et depuis RH9 utilisent nptl. Depuis RH9, il n'y a qu'une appli que j'ai utilisé avec linuxthread : realplay (à lancer en fixant LD_ASSUME_KERNEL).
Le seul problème que je connais avec nptl est qu'il nécessite des instructions i686 pour marcher "nickel". Entre autre berkeley db est connu pour sucker sur arch < i686. Il n'y aura pas de correctif pour ce "bug" (c'est la conséquence du design de nptl).
J'ai vérifié, mysql sous RH9 (noyau 2.4.20 patché nptl), sans le moindre patch ou options à ./configure utilise nptl (la librairie, pas l'entête).
Pour "réellement" utiliser nptl, c'est-à-dire ne pas utiliser l'entête linuxthread et être le plus proche possible du standard posix, Le "standard" maintenant est d'utiliser "-pthread" avec gcc (compilation et link) et de ne pas "réfléchir" (sous FC3, /usr/include/nptl/pthread.h sera utilisé lors d'un "#include <pthread.h>").
Pour revenir plus ou moins à l'origine du thread, il me semble que gentoo n'a pas nptl par défaut (par défaut c'est aussi linux 2.4). Donc le test a utilisé linuxthread (entête et librairie) sous Linux alors que nptl est plus rapide que linuxthread.
Donc ce test n'a pas "honteusement" favorisé linux comme sous-entendu ici.
De plus le "testeur" c'est fait chié avec freeBSD pour avoir linuxthread (qui est plus rapide que la version native). S'il n'avait pas installé linuxthread les résultats seraient pires.
[^] # Re: Désolé pour les trolls
Posté par Jerome Herman . Évalué à 3.
MySQL le fait( faisait) avec les mutexs pour des raisons de rapidité d'éxecution.
Sous Red Hat/Fedora et depuis RH9 nptl est utilisé par défaut :
Sur toutes les distribution en 2.6 aussi d'ailleurs. mais rien n'empèche de réclamer spécifiquement les LinuxThreads.
Donc, comme je le supposais plus haut, nptl est compatible linuxthread.
Sur les fonctions posix standards oui, sur les autres non. Toutes les initialisation de Mutex en code finnissant par _NP dans LinuxThreads ne sont pas compatibles avec NPTL.
De plus les linuxthreads créent des threads avec chacun leur PID (chaque thread apparait comme un proces), NPTL n'a pas ce défaut.
- linker directement (en dure) avec /lib/i686/ ou /lib (par défaut c'est linké avec /lib/tls).
J'ai dit que l'ensemble des MYSQL 4.x "vanilla" nécessitaient LinuxThreads pour tourner correctement. Apparament depuis la 4.1.8 ce n'est plus le cas. Cependant la 4.0.22 (utilisé dans le test) requiert absolument les Linuxthreads (0.71+). Apparament ce n'est plus le cas pour la 4.0.23 (Test fait sur ma gentoo, noyeau 2.6.9) mais la stabilité n'est pas au rendez-vous. Le manuel d'installation de la 4.0.23 précise d'ailleurs qu'il faut utiliser LinuxThreads cf
http://dev.mysql.com/doc/mysql/en/source-notes-linux.html(...)
MySQL uses LinuxThreads on Linux. If you are using an old Linux version that doesn't have glibc2, you must install LinuxThreads before trying to compile MySQL.
A noter que ceci prouve que
a) NTPL n'est pas 100% retro compatible avec LinuxThreads (4.022 ne passe pas, 4.023 est instable)
b) Les libs linuxthreads sont bien linkées spécifiquement (MySQL 4.0.23 vanilla utilise préférentiellement LinuxThreads)
Donc le test a utilisé linuxthread (entête et librairie) sous Linux alors que nptl est plus rapide que linuxthread.
Pour les locks et unlocks de mutexs (ce qui nous interesse ici) c'est LinuxThreads en mode Mutex rapide qui est le plus rapide. Même si NPTL ets globalement plus performante, il existe encor eun poitn ou deux ou LinuxThreads est plus rapide.
Donc ce test n'a pas "honteusement" favorisé linux comme sous-entendu ici.
C'est pas sous-entendu. C'est affirmé, ave cdémonstration à l'appui. Et il n'y a pas de guillemets autour de honteusement non plus.
De plus le "testeur" c'est fait chié avec freeBSD pour avoir linuxthread (qui est plus rapide que la version native)
Ah bon ? Chez moi c'est installé de base et c'est une option à passer à la compil. Mais bon.
Mais pour en revenir à ta remarque très juste, le testeur démontre avec brio que MySQL->NativeBSD threading est beaucoup plus lent que MySQL->LinuxThreads->Linux-To-PosixMapping->PosixThreads->Native BSD Threading.
Oui parcequ'au final sous BSD, ce sont quand même des threads BSD qui vont être créés.
La première idée qui vient quand on obtient ce genre de résultats est "tiens ils ont codés les threads natifs BSD avec les pieds", celle qui ne devrait jamais venir est "Mon Dieu LinuxThreads et tellement bien que quand on l'utilise en surcouche de surcouche de surcouche de BSD Threadings on gagne des perfs par rapport au natif".
Enfin bon moi je dis çà...
[^] # Re: Désolé pour les trolls
Posté par fabb . Évalué à 1.
> MySQL uses LinuxThreads on Linux. If you are using an old Linux version that doesn't have glibc2, you must install LinuxThreads before trying to compile MySQL.
Car il n'y a pas de thread du tout pour glibc < 2 et que d'ailleur il n'y a que Linux 2.6 qui fourni des fonctionnalités pour les threads. Les linux plus anciens s'appuient sur clone() et le reste est fait en userland.
> le testeur démontre avec brio que
Que MySQL sous *BSD est plus lent que MySQL sous Linux.
Pourquoi ?
Certains pensent car c'est à cause de *BSD et d'autres (toi ?) pensent que MySQL est codé avec les pieds pour le port BSD.
[^] # Re: Désolé pour les trolls
Posté par Jerome Herman . Évalué à 2.
Moi non plus je ne vais pas y passer des plombes.
TOUS les MySQL 4.0.X et les MySQL 4.1.Y avec Y < 8 utiliseront Linuxthreads par défaut si il est disponible.
Pour X<23 MySQL 4.0.X ne compilera même pas. Je parle des MySQL vanilla, à savoir le code source tel qui est fourni par MySQL sur le site MySQL.
Car il n'y a pas de thread du tout pour glibc < 2 et que d'ailleur il n'y a que Linux 2.6 qui fourni des fonctionnalités pour les threads. Les linux plus anciens s'appuient sur clone() et le reste est fait en userland.
J'ai cité la phrase en entier car je n'aime pas les citations partielles à quoi on peut faire dire tout et n'importe quoi. Je la refais plus brutal : Dans le manuel MySQL concernant MySQL 4.0.23 concernant la section "installation Linux à partir des sources" il est écrit :
MySQL uses LinuxThreads on Linux.
Que MySQL sous *BSD est plus lent que MySQL sous Linux.
Donne moi une raison valable, une seule ça me suffit, pour que MySQL sur une émulation de thread Linuxthread sur les threads posix sur les threads Natifs BSD soit plus rapide que MySQL directement sur les threads natifs BSD. Bonne chance. Hint : Les locks et les unlocks de mutexs sont des appels système qui se font forcément en natif.
[^] # Re: Désolé pour les trolls
Posté par fabb . Évalué à 1.
> TOUS les MySQL 4.0.X et les MySQL 4.1.Y avec Y < 8 utiliseront Linuxthreads par défaut si il est disponible.
Sous RH et FC il y a nptl *ET* linuxthread. L'appli qui veut linuxthread doit être linké à /lib/i686 (ou autre) mais pas à /lib/tls/libpthread.so. MySQL fait de lui même le choix d'utiliser nptl s'il est présent.
Ce que tu ne veux pas comprendre, est que nptl est compatible linuxthread (sauf quelques cas particulier) et donc ont peut avoir un code fait pour linuxthread qui marche avec nptl. C'est ce qui se passe avec *plein* *plein* *plein* d'applis et aussi avec mysql.
Je répète, mysql est codé ala linuxthread mais utilise nptl.
> Pour X<23 MySQL 4.0.X ne compilera même pas.
Je n'ai jamais dit le contraire. Relis le thread. Je dis qu'il est codé en utilisant les entêtes linuxthread mais qu'il utilise l'implémentation des thread nptl.
C'est comme Gtk. Ton applis peut nécessiter les entêtes Gtk+ 2.0 et ne pas compiler avec Gtk+ 2.6 mais elle peut utiliser gtk+ 2.6 (la librairie binaire, avec un file selector "mignon", etc) et dans ce cas, je dis que l'applis utilise gtk+ 2.6 pour la simple raison qu'elle utilise gtk+ 2.6.
Si tu ne comprends pas ça, je n'y peux rien.
> Je parle des MySQL vanilla, à savoir le code source tel qui est fourni par MySQL sur le site MySQL.
Moi aussi (et ./configure n'utilise pas "--with-pthread"). Ici, mysql utilise nptl et est compilé avec les entêtes de linuxthread.
> Donne moi une raison valable, une seule ça me suffit, pour que MySQL sur une émulation de thread Linuxthread sur les threads posix sur les threads Natifs BSD soit plus rapide que MySQL directement sur les threads natifs BSD. Bonne chance.
J'ai aucune raison à donner. Mais ce n'est pas une émulation de linuxthread, c'est linuxthread. C'est différent.
Le bench, même s'il ne donne pas de raison, montre que Mysql est plus lent avec l'implémentation native qu'avec linuxthread. Point final.
Maintenant soit tu remets en cause l'intégrité du test en refaisant les tests, soit tu considères que MySQL est mal codé lorsqu'il utilise l'implémentation native, soit tu considères que l'implémentation *BSD est plus lente que linuxthread.
> Hint : Les locks et les unlocks de mutexs sont des appels système qui se font forcément en natif.
Et alors ?
C'est toi qui dit que le problême est autour des mutex. Moi, je n'en sais rien. Je constate seulement que c'est plus rapide avec linuxthread.
[^] # Re: Désolé pour les trolls
Posté par Jerome Herman . Évalué à 3.
Sous beaucoup d'autres distribs aussi. Sous ma gentoo j'ai mis les deux.
Ce que tu ne veux pas comprendre, est que nptl est compatible linuxthread (sauf quelques cas particulier)
Je l'ai compris il y a bien longtemps. ce que toi tu ne veux pas comprendre est que MySQL utilsie des inits de mutex en _NP qui justement font partis desdits cas particuliers
Je répète, mysql est codé ala linuxthread mais utilise nptl.
C'est faux. L'init de mutex de MySQL force LinuxThread en config standard (ie la config utilisé pour les tests)
Je n'ai jamais dit le contraire. Relis le thread. Je dis qu'il est codé en utilisant les entêtes linuxthread mais qu'il utilise l'implémentation des thread nptl.
Non. Le code d'initialisation des mutex, oblige l'utilisation des bibliothèques linuxthreads. La façon la plus simpel de savori si MySQL utilise LinuxThreads ou NPTL est de compter les process MySQL après lancement du démon. Si il y en a un c'est que les trois threads utilisent le même PID. C'est donc que NPTL a été utilisé, si il y en a trois c'est que LinuxThreads a été utilisé.
C'est comme Gtk. Ton applis peut nécessiter les entêtes Gtk+ 2.0 et ne pas compiler avec Gtk+ 2.6 mais elle peut utiliser gtk+ 2.6 (la librairie binaire, avec un file selector "mignon", etc) et dans ce cas, je dis que l'applis utilise gtk+ 2.6 pour la simple raison qu'elle utilise gtk+ 2.6.
Si tu ne comprends pas ça, je n'y peux rien.
Je ne parle pas des entêtes mais des bibliothèques systèmes. MySQL utilisant des fonctions non portables (ie non présente dans la norme Posix) doit être linké avec linuxthreads pour les versions citées plus haut. MySQL, dans son configure par défaut, a un besoin vital d'uen fonction non posix LinuxThreads qui n'existe pas dans NPTL (ni en réel, ni en interface mappée).
Ici, mysql utilise nptl et est compilé avec les entêtes de linuxthread.
Ca me parait très étonnant. Je veux bien croire que MySQL "Linke" NPTL pour une raison qui m'échappe, mais je ne pense pas qu'il s'en serve (du moins pas MySQL 4.0.22). Au niveau execution LinuxThreads et NPTL sont totalement incompatible et on ne peut donc pas les utiliser simultanément dans un même programme. A mon sens ilf aut compter les process. Si en compilant MySQL 4.0.22 avec un simple ./configure tu arrives à n'avoir qu'un seul process MySQL qui tourne c'est que tu as raison, ton MySQL utilise NPTL. Mais dans ce cas j'aimerais vraiment jeter un oeuil à ta config, parceque c'est théoriquement impossible.
J'ai aucune raison à donner. Mais ce n'est pas une émulation de linuxthread, c'est linuxthread. C'est différent.
Les threads sont créés avec la fonction 'clone' et ca s'arrête là. Tous les signaux systèmes passent quand même par le système natif et doivent être convertis. Le terme d'émulation n'est peut-être pas le bon, on devrait plutot parler d'enrobage (wrapping). Ceci étant les locks de mutex (par exemple, car ce n'est qu'un des quatre ou cinq points qui posent porblème, mais autant garder le même de bout en bout) doivent remonter jusqu'en userspace et redescendre à chaque fois...
soit tu considères que l'implémentation *BSD est plus lente que linuxthread.
Plus lente non, plus problématique oui. Les threads dans FreeBSD sont assez pathétiques. Au final un MySQL compilé avec les options de base met à genoux un FreeBSD très facilement. Le threading sous FreeBSD est faiblard parfois, mais ça n'est pas la question.
Et alors ? C'est toi qui dit que le problême est autour des mutex.
Une fois de plus les mutexs ne sont qu'un exemple. C'est un des mainteneur des ports FreeBSD qui a évoqué que ca pourrait venir de là. Pour une liste de tous les problèmes liés à FreeBSD et la solution :
http://jeremy.zawodny.com/blog/archives/000203.html(...)
http://jeremy.zawodny.com/blog/archives/000264.html(...)
http://jeremy.zawodny.com/blog/archives/000697.html(...)
Je dis juste que le réalisateur du test aurait pu prendre des versions patchées de MySQL pour FreeBSD et que celà aurait rendu le test plus juste. Je ne prétend pas :
- Ni que FreeBSD est meilleur que Linux
- Ni que MySQL Tuné pour FreeBSD est meilleur que le MySQL tuné pour lInux
- Ni que le système de threading FreeBSD est meilleur que LinuxThreads.
Je dis juste que le test n'est pas juste en l'état.
[^] # Re: Désolé pour les trolls
Posté par fabb . Évalué à 1.
Il y a des "_NP" dans les includes de nptl.
[^] # Re: Désolé pour les trolls
Posté par Jerome Herman . Évalué à 2.
Il y a donc des _NP à peu près partout, celà signifie juste que la fonction n'est pas standard, et donc qu'elle risque de ne pas se retrouver dans une bibliothèque standard. Typiquement rien ne garantie que l'init de Mutex MUTEX_INIT_RECCURSIVE_NP sera présente dans toutes les bibliothèques Posix Threads, ni même qu'elle aura un comportement similaire si elle est présente.
[^] # Re: Désolé pour les trolls
Posté par fabb . Évalué à 1.
Bizarre ton raisonnement. Les BSD ne remonte pas leur patch en upstream ?
Tu préfères que le testeur compare avec des versions différente de MySQL ?
Tu sembles remettre en cause la configuration automatique (détection) faite par MySQL ? Qu'es-ce qui ne va pas dans le boulot fait par Mysql ?
> MySQL est un des ports les plus patchés sous les *BSD.
Où on peut les voirs ces patchs ?
# Le paradoxe du benchmark ?
Posté par RuleZ . Évalué à -1.
Les données, ne seraient-elles pas censés être garanties : d'intégrité, de disponibilité, de confidentialité, et de plein d'autres truc en rapport à leur nature, avant même la performance ?
C'est en principe ce qu'on recherche dès qu'on parle de base de données.
La performance en devient bien souvent secondaire ... allez dire à une banque que Machin va 100 fois plus vite que Truc, mais qu'à la moindre défaillance, 0.001% des données sont corrompus avec Truc (ce qui est ENORME !)
Je sais bien que ce n'est pas MySQL qui est benchmarké et que ce sont ses caractéristiques propres qui servent de *moyens* pour arriver à une fin ! ... MAIS, la seule façon viable d'interpréter un tel benchmark, c'est de l'intitulé "Performance de MySQL sur les différents Linux/Unix", ce qui est une absurdité totale en soi ! On préfererai voir Stabilité/Sécurité/Intégrité/ ou je ne sais quoi, plutot que performance, quelque chose qui ait au moins un rapport avec les données en tout cas !
Pour mesurer une performance qui soit utile, la moindre des politesses serait d'utilisé un "moyen" qui ait pour vocation *première* d'être performant !
Pour résumé : C'est absurde d'utiliser un moyen (MySQL) de benchmark dont les caractéristiques *secondaires* (la performance) seront celles utilisées pour établir une mesure qui soit la vocation *premiére* du benchmark.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.