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 ?
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 Jerome Herman . En réponse au journal La guerre des OS. É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.