dbnewz

Modifier une petite ligne dans le fichier de configuration de son SGBD et obtenir les performances souhaitées, c’est possible… si vous êtes chanceux. La performance globale d’un SGBD repose en effet sur un ensemble de briques, logicielles ou matérielles, qui une fois empilées correctement forment un ensemble cohérent (et performant) : la seule étape du fichier de configuration ne suffit pas.

Dans un de ses récents billets, Matt Yonkovit a déclenché une série de réflexions intéressantes à propos de l’impact des performances des disques durs sur l’ensemble du SGBD.

Selon lui, les problèmes de performance au sein d’un SGBD sont la plupart du temps relatifs aux disques durs et notamment au nombre d’I/O (Entrées/Sorties) qu’ils sont capables de traiter par seconde (IOPS).

Comparés aux processeurs actuels capables de prendre plusieurs milliards de décisions par seconde (Ghz) et aux mémoires vives dont les temps d’accès se mesurent en nanosecondes, le temps d’accès d’un disque dur se compte encore en millisecondes… Difficile de lutter contre des éléments purement électroniques quand on est constitué d’éléments mécaniques en mouvement (têtes de lecture, plateaux…).

(more…)

Qui n’a jamais utilisé MySQL sans la réplication? La réplication permet à votre application de supporter un nombre de lecture beaucoup plus important. Les updates se font sur une base de donnée “maître” (master) et sont ensuite répliquées sur plusieurs “esclaves” (slaves). Le maître n’a pas à supporter les requêtes venant de clients qui sont gérées par les esclaves. Un autre jour je rentrerai plus en détails la dessus mais en résumé, le maître écrit dans des fichiers toutes les requêtes qui ont modifié ses informations (insert, update et delete). Les slaves viennent à leur tour récupérer ces fichiers (binary logs) et les “copie” localement (relay logs) avant de les rejouer.

Il est conseillé en général de dédier un disque pour ces fichiers car beaucoup d’écriture entraîne une baisse de vos performances. Dans le cas qui nous intéresse, l’activité du CPU m’a très étonné. En effet jusqu’à 60% du temps CPU étaient utilisé par ‘USER’ juste en activant la réplication.
(more…)