[a-h-aide] Optimisation Mysqld
Bonjour Je fais suite à la discussion que j'ai commencée en juillet dernier : http://listes.auto-hebergement.fr/pipermail/auto-hebergement-aide/2013-July/... Je cherche à optimiser l'occupation en RAM de Mysqld (actuellement : VIRT : 472 Mo RES : 175 Mo) J'ai essayé de bricoler en fonction de ce que me disent tuning-primer.sh & mysqltuner.pl mais sans bouleversements significatifs... En gros ma SWAP se rempli dans l'heure d'uptime et j'ai (l'impression ?) d'être à l'étroit. Mysql étant la plus grosse occupation mémoire je cherche à l'optimiser Je re-précise que je suis sur un VPS OVH (anciennement vKS) et qu'il est donc impossible de tripoter les paramètres de SWAP. Plus de détails sur ma configuration / résultat des scripts de tuning par ici : http://pastebin.com/0ekvbkxV http://dl.zici.fr/files/get/rf_hOgnINm/memory-week.png Si vous avez des pistes pour m'aider, D'avance merci, David Note : j'ai déjà entamé la discussion avec tranxene50 en privé, mais nous continuons sur la liste
Afficher les réponses par date
Plop !
Je cherche à optimiser l'occupation en RAM de Mysqld (actuellement :
Ta conf est "bizarre" : MySQL est complètement bridé... (on verra ça après) Pour visualiser ce qui est stocké en SWAP : check-swap. Au final c'est quoi l'objectif ? Avoir un MySQL qui consomme rien en mémoire (possible) ou obtenir de bonnes perfs ? A+ -- tranxene50 tranxene50@developpeur-neurasthenique.fr
tranxene50 <tranxene50@developpeur-neurasthenique.fr> a écrit :
Plop !
Je cherche à optimiser l'occupation en RAM de Mysqld (actuellement :
Ta conf est "bizarre" : MySQL est complètement bridé... (on verra ça après)
ça c'est très possible, j'ai télexent bidouillé (sans approfondir j'avoue) que c'est très certainement n’importe quoi !
Pour visualiser ce qui est stocké en SWAP : check-swap.
Alors là je connaissais pas cette commande et mon système non plus (Debian 7 top upgrade). Rien dans apté qui s'en approcherai. Rien non plus avec "Canard Canard aller"... Tu as un lien pour téléchargé l'outil ?
Au final c'est quoi l'objectif ? Avoir un MySQL qui consomme rien en mémoire (possible) ou obtenir de bonnes perfs ?
C'est de minimiser tant que faire se peut, l'occupation RAM sans trop pourrir les perfs forcément même si je peux en conséder. Je veux que Mysqld utilise la mémoire en "bon père de famille" - expression très adéquate -
A+
-- tranxene50 tranxene50@developpeur-neurasthenique.fr
Merci
tranxene50 <tranxene50@developpeur-neurasthenique.fr> a écrit :
Plop !
Je cherche à optimiser l'occupation en RAM de Mysqld (actuellement :
Ta conf est "bizarre" : MySQL est complètement bridé... (on verra ça après)
ça c'est très possible, j'ai télexent bidouillé (sans approfondir j'avoue) que c'est très certainement n’importe quoi !
Pour visualiser ce qui est stocké en SWAP : check-swap.
<parano>Je te l'envoi en privé ça par contre... c'est délicat à balancer en public </parano>
Au final c'est quoi l'objectif ? Avoir un MySQL qui consomme rien en mémoire (possible) ou obtenir de bonnes perfs ?
C'est de minimiser tant que faire se peut, l'occupation RAM sans trop pourrir les perfs forcément même si je peux en conséder. Je veux que Mysqld utilise la mémoire en "bon père de famille" - expression très adéquate -
A+
-- tranxene50 tranxene50@developpeur-neurasthenique.fr
Merci
Suite !
Au final c'est quoi l'objectif ? Avoir un MySQL qui consomme rien en mémoire (possible) ou obtenir de bonnes perfs ?
C'est de minimiser tant que faire se peut, l'occupation RAM sans trop pourrir les perfs forcément même si je peux en conséder. Je veux que Mysqld utilise la mémoire en "bon père de famille" - expression très adéquate -
Voici une première conf : la consommation mémoire ne devrait pas diminuer mais les perfs seront sûrement meilleures. Laisse tourner 24 heures et rebelote : mysqltuner.pl & tuning-primer.sh. A+ -- tranxene50 tranxene50@developpeur-neurasthenique.fr
Voilà après ~24H http://dl.zici.fr/files/get/ep30fzmUUk/memory-day.png http://pastebin.com/SfYAp4FL VIRT : 559M RES : 283M Au ressenti ça semble effectivement plus réactif par contre l’occupation en RAM est supérieur/ J'ai simplement dû commenter "skip-name-resolve" car ISPconfig (le panel que j'utilise) met des noms dans la table des privilèges Mysql. Note : si tu as le temps d'être plus verbeux dans des explications n'hésite pas ça m'intéresse tout autant... David tranxene50 <tranxene50@developpeur-neurasthenique.fr> a écrit :
Suite !
Au final c'est quoi l'objectif ? Avoir un MySQL qui consomme rien en mémoire (possible) ou obtenir de bonnes perfs ?
C'est de minimiser tant que faire se peut, l'occupation RAM sans trop pourrir les perfs forcément même si je peux en conséder. Je veux que Mysqld utilise la mémoire en "bon père de famille" - expression très adéquate -
Voici une première conf : la consommation mémoire ne devrait pas diminuer mais les perfs seront sûrement meilleures.
Laisse tourner 24 heures et rebelote : mysqltuner.pl & tuning-primer.sh.
A+
-- tranxene50 tranxene50@developpeur-neurasthenique.fr
Plop ! :) Nouvelle config : ce coup-ci, attend plusieurs jours avant de poster les résultats.
Au ressenti ça semble effectivement plus réactif par contre l’occupation en RAM est supérieur/
Logiquement, l'utilisation RAM devrait être réduite tout en conservant des perfs acceptables. Ceci étant, ton VPS n'est pas à l'agonie, l'utilisation de la RAM d'après Munin est plutôt bien équilibrée (Apps, cache/buffers, swap). Le fait que la SWAP soit rapidement utilisée n'est pas forcément un mauvais signe : généralement, il s'agit de processus qui dorment.
Note : si tu as le temps d'être plus verbeux dans des explications n'hésite pas ça m'intéresse tout autant...
Pas de souci (mais pas ce soir... ^^) Est-ce qu'il y a une raison pour conserver certaines bases/tables au format MyISAM ? Généralement, c'est quand on a des index FULLTEXT (marche pô en Innodb) ou des requêtes INSERT DELAYED (pareil, innodb => marche pas..). Sinon, après les backups qui s'imposent, tout le reste peut passer en InnoDB sans souci. Et avec Debian Wheezy, il est possible d'utiliser le plugin "Barracuda" au lieu d'InnoDB. A priori il est plus performant (j'ai pas de fait de benchs). En tout cas ça marche bien, que ce soit sur ma Nobox ou des serveurs en prod. A+ -- tranxene50 tranxene50@developpeur-neurasthenique.fr
Ceci étant, ton VPS n'est pas à l'agonie, l'utilisation de la RAM d'après Munin est plutôt bien équilibrée (Apps, cache/buffers, swap).
Le fait que la SWAP soit rapidement utilisée n'est pas forcément un mauvais signe : généralement, il s'agit de processus qui dorment.
Ok, mais libéré un peu de RAM me permettrait d'envisager l'installation de nouveau service (xmpp, etherpad) sans être au taquet...
Note : si tu as le temps d'être plus verbeux dans des explications n'hésite pas ça m'intéresse tout autant...
Pas de souci (mais pas ce soir... ^^)
Est-ce qu'il y a une raison pour conserver certaines bases/tables au format MyISAM ?
Généralement, c'est quand on a des index FULLTEXT (marche pô en Innodb) ou des requêtes INSERT DELAYED (pareil, innodb => marche pas..).
Sinon, après les backups qui s'imposent, tout le reste peut passer en InnoDB sans souci.
Le truc c'est que je propose de l'hébergement (mutualisation) - rhien.org - donc je ne maîtrise pas toutes les installations présentes. Il est donc très compliquer à mon avis de tout migrer vers innodb. Quel serait la valeur ajouter d'une migration totale sur innodb ? (faut voir si le jeu en vaut la chandelle)
Et avec Debian Wheezy, il est possible d'utiliser le plugin "Barracuda" au lieu d'InnoDB.
A priori il est plus performant (j'ai pas de fait de benchs). En tout cas ça marche bien, que ce soit sur ma Nobox ou des serveurs en prod.
Intéressant je connaissais pas je vais regarder ça !
A+
-- tranxene50 tranxene50@developpeur-neurasthenique.fr
Merci, David
Plop !
Ok, mais libéré un peu de RAM me permettrait d'envisager l'installation de nouveau service (xmpp, etherpad) sans être au taquet...
Ton VPS n'est pas au "taquet". :)
Le truc c'est que je propose de l'hébergement (mutualisation) - rhien.org - donc je ne maîtrise pas toutes les installations présentes.
Tu peux "forcer" les nouvelles bases au format InnoDB : default-storage_engine = InnoDB Si l'utilisateur précise MyISAM, il restera dans ce format.
Il est donc très compliquer à mon avis de tout migrer vers innodb.
Compris.
Quel serait la valeur ajouter d'une migration totale sur innodb ? (faut voir si le jeu en vaut la chandelle)
En fait cela permet d'une certaine manière de "simplifier" la conf de MySQL : si tu as 95% de BDD en InnoDB, la variable qui devient cruciale c'est "innodb_buffer_pool_size". Quand tu as 50/50 MyISAM/InnoDB, c'est pas évident de savoir quelle est la partie "immergée" pour chaque format, c'est à dire les données régulièrement utilisées. Tu utilises quel outil/script pour la sauvegarde des BDD ? A+ -- tranxene50 tranxene50@developpeur-neurasthenique.fr
Suite ! Des news concernant les perfs de MySQL ? A+ -- tranxene50 tranxene50@developpeur-neurasthenique.fr
Salut, Désolé, planning encombré en ce moment... Voilà ce que ça donne : http://pastebin.com/eeVkTw9E VIRT : 550M RES : 249M @+ David tranxene50 <tranxene50@developpeur-neurasthenique.fr> a écrit :
Suite !
Des news concernant les perfs de MySQL ?
A+
-- tranxene50 tranxene50@developpeur-neurasthenique.fr _______________________________________________ auto-hebergement-aide mailing list auto-hebergement-aide@listes.auto-hebergement.fr http://listes.auto-hebergement.fr/listinfo/auto-hebergement-aide
Hello ! Désolé pour le délai.
Voilà ce que ça donne :
Ok. Les résultats ont l'air pas mal. Sauf le "Table cache hit rate" et la, je sais pas trop... :/ Au niveau de la conf, peu de changements : - sort_buffer_size = 512K - key_buffer = 32M - innodb_additional_mem_pool_size = 8M - innodb_buffer_pool_size = 64M Cela va réduire légèrement l'occupation mémoire et donner un peu plus "d'air" au tables en MyISAM. A+ -- tranxene50 tranxene50@developpeur-neurasthenique.fr
Bonjour, ça marche j'ai appliqué les changements ! Petite question, dans munin il m'affiche en "critical" le graph " innodb free tablespace" (voir PJ) est-ce normal ? David tranxene50 <tranxene50@developpeur-neurasthenique.fr> a écrit :
Hello !
Désolé pour le délai.
Voilà ce que ça donne :
Ok. Les résultats ont l'air pas mal.
Sauf le "Table cache hit rate" et la, je sais pas trop... :/
Au niveau de la conf, peu de changements :
- sort_buffer_size = 512K - key_buffer = 32M - innodb_additional_mem_pool_size = 8M - innodb_buffer_pool_size = 64M
Cela va réduire légèrement l'occupation mémoire et donner un peu plus "d'air" au tables en MyISAM.
A+
-- tranxene50 tranxene50@developpeur-neurasthenique.fr _______________________________________________ auto-hebergement-aide mailing list auto-hebergement-aide@listes.auto-hebergement.fr http://listes.auto-hebergement.fr/listinfo/auto-hebergement-aide
participants (3)
-
admin＠zici.fr -
David Mercereau -
tranxene50