Calculateur config MariaDB

Dimensionne le buffer pool InnoDB, les buffers par connexion et le swap depuis la taille de base et la RAM.
Pensé pour un serveur type Apache/Nginx + PHP-FPM.

				-- Afficher la taille de la base de données
				mariadb -e "SELECT ROUND(SUM(data_length+index_length)/1024/1024/1024, 2) AS total_gb FROM information_schema.tables WHERE engine='InnoDB';"
Go
Go
Go

OS + services système (fail2ban, monitoring) ~0,7 · Apache/nginx + PHP-FPM ~0,9.

Go

RAM laissée libre. Sans elle le noyau swappe malgré un pool « correct ».

conn.

Le pic réel : SHOW GLOBAL STATUS LIKE 'Max_used_connections'; — ta vraie limite haute reste le nombre de workers PHP-FPM.

Buffer pool conseillé
–
Instances
–
Base cachée
–
RAM pour tout cacher
–
Overhead hors pool
–
Budget MariaDB
–

Bloc à coller dans /etc/mysql/my.cnf 


			
Le dernier lu gagne : ce bloc doit venir après la ligne !include /etc/mysql/db-performance.cnf. Cet !include est souvent placé en fin de fichier — tes overrides ne servent alors à rien pour toute clé qu'il redéfinit. Remonte la ligne
				!include avant ce bloc plutôt que d'éditer db-performance.cnf, qu'un outil de tuning automatique peut réécrire.
			


			
Redémarre le service MariaDB et vérifie :

			
				systemctl restart mariadb
				mariadb -e "SELECT @@innodb_buffer_pool_size/1024/1024 AS pool_mb, @@max_connections, @@aria_pagecache_buffer_size/1024/1024 AS aria_mb;"
			

			
Après une réduction de innodb_log_file_size, il faut un arrêt propre (systemctl stop mariadb, shutdown complet confirmé dans les logs) avant de redémarrer. MariaDB récente régénère seule les ib_logfile* ; sur MySQL 5.7 il faut les
				supprimer à la main.


		




		

			
Variables volontairement absentes du bloc

			
innodb_file_format = Barracuda — à supprimer de ton fichier actuel : retirée depuis MariaDB 10.6 (MySQL 8.0), variable inconnue, le serveur refuse de démarrer. Vérifie ta version avec mysqld --version.

			
internal_tmp_disk_storage_engine — variable MySQL, inexistante en MariaDB. Son équivalent aria_used_for_temp_tables est en lecture seule et déjà à ON.

			
performance_schema = OFF — inutile de l'écrire : c'est déjà le défaut en MariaDB. Contrôle avec SELECT @@performance_schema; (doit renvoyer 0).

			
sync_binlog = 1 — non repris : à trancher selon l'usage du binlog. Sans réplication ni PITR, sync_binlog = 0 (voire binlog désactivé) te rend des IOPS ; avec innodb_flush_log_at_trx_commit = 2 tu acceptes déjà de perdre jusqu'à 1 s
				de transactions, payer un fsync par commit sur le binlog est incohérent. Si le binlog te sert de PITR, garde 1.

			
query_cache_* — déjà désactivé par défaut en MariaDB récente, la ligne n'apporte rien.

		


		

			
Commandes swap

			

			
Ordre impératif : buffer pool + swappiness d'abord (créent le headroom), swapoff/swapon ensuite (ne réussit que si la RAM libre absorbe le swap actuel). Garde 2 Go de swap actif : mieux vaut un peu de swap qu'un OOM killer qui tue mysqld en pleine
				transaction.

		


		

			
Vérification après redémarrage

			
				# Mémoire réellement utilisée par mysqld
				ps -o rss= -C mysqld | awk '{print $1/1024 " Mo"}'

				# Vue d'ensemble mémoire + pression noyau
				free -m && cat /proc/pressure/memory

				# Pic de connexions atteint (pour recaler max_connections)
				mariadb -e "SHOW GLOBAL STATUS LIKE 'Max_used_connections';"

				# Tables temporaires tombées sur disque : si ça explose, tmp_table_size 32M → 64M
				mariadb -e "SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables';"
			

			
tmp_table_size reste à 32M : monter la valeur ne sert à rien, une requête qui manipule un TEXT bascule sur disque quoi qu'il arrive. Si Created_tmp_disk_tables explose, cherche la requête plutôt que le réglage.

			
Si l'application reste lente malgré tout, le vrai levier est souvent l'index sur la table la plus sollicitée plutôt que la config MariaDB : c'est elle qui concentre l'essentiel des I/O.