Optimisation Bdd ?..

[Roworll]

Il est à combien actuellement ton Handler_read_rnd_next ?
As-tu la possibilité sur ton serveur SQL de réinitialiser la valeur à 0 histoire de voir si sa progression est rapide ou lente ?

Au pire, si cela progresse lentement, le problème peut être considéré comme mineur.

[Unkof]

Christouphe:lol ... la définition vient du même site, et de la même doc, mais pas du même sujet ... mdr.

Roworll:Environ 70 M / heure maintenant, mais je pourrai le dire plus précisément demain, j'ai déjà revu quelques index ce matin, ceux des tdd sur lesquelles je bosse actuellement. Mais bon ... 70 M, c'est déjà énorme.

[Roworll]

Mais bon ... 70 M, c'est déjà énorme.

Oui et non.
Sauf erreur, les handlers (handler_delete, handler_read_key, etc) sont des compteurs qui sont réinitialisés lorsque le moteur MySQL est redémarré ou lorsque l'on fait un flush status.
Donc 70M peut paraître énorme mais si tu as 8 sites, autant de DB et que ton service MySQL est up depuis plusieurs mois, ça devient déjà moins préoccupant.

[Unkof]

Ouais ... mis à part que c'est en gros 70 M, mais par heure. Là au moment ou je poste, je suis à 1815 M.

Elle se réinitialise comment cette variable ? Hier sans rien faire, elle était à 615 M, et y a 3 jours, avant que je modifie une grosse Tdd qui elle était mal indexée, j'étais à 3905 M.

C'est en redémarrant le serveur qu'elle se réinitialise ? Quand on utilise la fonction Réinitialiser de Phpmyadmin dans les informations serveur, cette variable n'est pas touchée.

Mis à part les histoires d'index, y a autre chose qui pourrait augmenter cette valeur ?

J'ai du mal à trouver des infos sur google pour ca ... .. tout ce que je trouve est relativement vague ...

[Roworll]

Ce compteur est remis à 0 lorsque tu arrêtes le service MySQL et que tu le redémarres.

Un point amusant : J'ai testé sur mon serveur MySQL local en utilisant la page d'état de PhpMyAdmin comme référence pour avoir les infos des compteurs.
Je me suis mis sur la page d'état, j'ai redémarré le service MySQL et j'ai réactualisé toute la page (F5). Le compteur avait déjà atteint les 800. Deuxième actualisation par F5, j'étais à plus de 1700.
Je précise encore une fois que j'étais sur mon serveur, en local, sans aucune autre activité que celle de PhpMyAdmin.

Bref, les valeurs de ce compteur me semblent parfois bien trop ésotériques pour y prêter une véritable attention. C'est un indicateur, bien sur, mais c'est loin d'être l'élément essentiel à surveiller pour détecter tous les problèmes d'optimisation.

Je suppose que MySQL fonctionne comme la plupart des bases de données. Les index se doivent d'être placés sur les valeurs les plus spécifiques possibles (GUID, Auto increment). Mettre un index sur une colonne ne contenant qu'une poignée de valeurs réparties sur des milliers de lignes est inutile car il est possible que, pour des raisons de répartition et de performances, le moteur choisisse de lire toute la table au lieu d'utiliser l'index.

[Unkof]

Oui, je suis d'accord avec toi sur le fait qu'il ne faut pas non plus en faire une fixation, mais c'est malgré tout un indicateur.

T'es à 1700, d'accord, mais t'es pas à 1700 K, et encore moins à 1700 M. Et là, y a quand même un sacré écart .... ^^

On va dire que je serais à 1 ou 2 M / heure, ca ne m'inquieterai pas plus que ca, mais là je suis en gros à 70 M / Heure, pour grosso modo 15 connexions par heure. Si je passe par exemple à 200 connexions par heure, je passe (en théorie bien sûr ...) à 900 M / heure.

Et là très franchement, je me pose des questions sur le fait de savoir si le serveur tiendra ce rythme ou si il tombera lamentablement ?...

[Roworll]

Regarde plutôt les indicateurs de performance de ton serveur. Dans quelle mesure le CPU et la mémoire sont utilisés ? Est-ce que tu as beaucoup d'IO ? Ce sont des accès disque ou mémoire ? As-tu des procédures de maintenance sur ta base pour reconstruire/défragmenter tes index ?

Au niveau de ta base, si tu as beaucoup de petites tables (ou des petites tables utilisées fréquemment), les compteurs peuvent s'envoler car MySQL peut ne pas utiliser l'index sur de petits volumes

Tu peux aussi regarder ton ratio entre Handler_read_rnd_next, Handler_read_next, Handler_read_key, etc. Cela peut indiquer quel pourcentage de "table scan" sont effectués par rapport aux "index seek"

[Unkof]

Alors... les infos que j'ai rassemblé :

Cpu:Charge user 0,2%, charge système 0,3%
Ram:1 Go de Ram, 848 Mo de pris, 176 Mo de libre.
Swap:1 Go, 0 utilisé.

Comment tu fais pour voir l'activité IO en temps réel et si ce sont des accès disques ou mémoire ? ...

Niveau tables, il y a quelques petites tables qui peuvent effectivement être appelées fréquement

Pour les autres variables du serveur :

Handler_read_key:6798 K
Handler_read_key_next:210 M
Handler_read_key_prev:6491
Handler_read_rnd:6696 K
Hanlder_read_rnd_next: 3104,92 M

A premiere vu, le Handler_read_rnd et le Handler_read_rnd_next confirment le problème d'index ...

Je vais chercher au niveau du serveur, vu que ses infos sont relevées, il y a forcément un moyen de trouver quelles sont les tables qui posent problème ..

[Anthor]

Installe MUNIN, tu auras toutes les infos nécessaire.

Question tu as quoi comme processus pour utiliser autant de mémoire ?!