MySQL/MariaDB : Déterminer la taille recommandée de innodb_buffer_pool_size

Rapide mémo pour déterminer la taille recommandée du buffer pour les tables utilisant le moteur de stockage InnoDB de MySQL. Par défaut après installation cette valeur est en général à 128 Mo, ce qui peut être bien bas pour de grosses bases de données.

La requête ci-dessous retourne la taille à renseigner pour la valeur de la variable innodb_buffer_pool_size :


SELECT 
	CEILING(Total_InnoDB_Bytes*1.6/POWER(1024,3)) RIBPS 
FROM (
	SELECT 
		SUM(data_length+index_length) Total_InnoDB_Bytes
	FROM information_schema.tables 
	WHERE engine='InnoDB'
) A;

Il suffit alors de renseigner cette valeur dans le fichier de configuration /etc/my.cnf :

[mysqld]
innodb_buffer_pool_size=8G

Redémarrer MySQL/MariaDB :

$ sudo systemctl restart mariadb

Nouveau serveur Kimsufi SSD pour un hébergement Nginx, PHP-fpm, Varnish et Memcached

Mes sites ont migré sur un nouveau serveur Kimsufi SSD de OVH et les performances sont bien sympathiques grâce à Nginx et Varnish.

Petite évolution du serveur hébergeant feub.net et plusieurs autres sites qui reste chez Kimsufi d’OVH mais en version SSH cette fois-ci. Cela me titillait depuis un moment car il faut bien l’avouer le SSD lorsqu’on en goûte on ne peut plus s’en passer, côté desktop mais coté serveur aussi. Mais il fallait bien avouer que le boulot de la migration me faisait renoncer, je n’avais pas trop envie de passer des heures devant un terminal lorsque je passe déjà mes journées au boulot devant des lignes de code. Après moult réflexion donc, maintenant c’est fait, un Kimsufi moins cher (9.99€/mois) que celui d’avant, avec un couple processeur/mémoires similaire, mais aussi 20% de moins d’espace disque, passant d’1Tb à 40Gb.

Je reste fidèle à Fedora, en passant à la version 23, et le serveur web d’enfer Nginx se voit désormais épaulé par l’accélérateur d’applications web Varnish que je commence à apprivoiser et Memchached pour la mise en cache d’objets PHP. Belle petite équipe qui ne demande qu’à être optimisée ^.^

Je ne vais pas m’attarder sur le détail de mes configurations, mais ce sera certainement l’objet de prochains billets sur ce blog. Pour le moment ça roule, peut-être y’a-t-il quelques couacs à droite à gauche, alors n’hésitez surtout pas à me faire part de tout problème ou anomalie.

MySQL 5.6 occupe presque 500Mo de ressources

Depuis la version 5.6.17 de MySQL dans mon environnement de développement WAMP, les ressources occupées par le moteur de base de données flirtent avec les 500Mo.

Ressource avant

C’est plutôt ennuyeux. Il semble qu’il s’agisse de la valeur de la variable table_definition_cache qui est fixée par défaut à 1400, une valeur un peu trop importante pour mes besoins limités en développement local. La documentation informe que la valeur minimale est de 400, et que par défaut celle-ci est établie comme ceci : 400 + (table_open_cache / 2), plafonnée à la limite de 2000.

Cette variable n’est en principe pas présente dans le fichier de configuration de MySQL my.ini, il suffit de l’ajouter, puis de redémarrer MySQL, et le résultat est sans appel : environ 91Mo de ressources dans mon cas.

Ressource après

A noter que la documentation officielle informe que la valeur de table_definition_cache était établie à 400 jusqu’à MySQL 5.6.8

Mise à jour massive multi-tables MySQL utilisant une procédure stockée

Ce billet est un pur mémo, un quasi copier-coller. Et je n’ai pas trouver un autre titre, aussi générique et banal soit-il.

Pour l’un de mes projets principaux (un système de gestion de pièces de rechange/entrepôt), un gros changement m’a été demandé. Celui-ci, parmi d’autres choses, implique une modification du format du code barre des biens dans la base de données, et ce champ est une clé primaire, donc point délicat.

Le code barre était auto-généré en utilisant les premiers 6 caractères du code fournisseur – si existant – complétés par des zéros, puis un entier incrémenté, toujours complété par des zéros. Il existe donc différentes « typographies » de codes barres, avec et sans caractères alphabétiques : 0000002598 et DMP0000666 peuvent exister.
Maintenant ce code barre est plus simple, il s’agit juste d’un entier incrémenté.

Continuer la lecture de « Mise à jour massive multi-tables MySQL utilisant une procédure stockée »