Mercredi 23 Avril 2025

Optimisation de notre serveur Debian

Aurelienazerty

Notre serveur web commençait sérieusement à tirer la langue : lenteurs, pages longues à charger (jusqu'à 13s pour la page d'accueil !), base de données qui semblait faire du surplace… Il était temps d’aller voir sous le capot 🔍

🚦 Le diagnostic

Après quelques commandes bien choisies (ps, free, mysqladmin status), le constat était clair :

MariaDB mangeait une grosse part de la RAM (~20 %).
Apache2 ouvrait plein de processus, chacun assez gourmand.
Notre serveur n’a que 2 Go de RAM, et aucune partition de swap activée.
En prime, plus de 1000 requêtes par seconde vers MariaDB. 😬

🩺 Les traitements mis en place

🧠 1. Ajout d'une zone de swap

C’est sans doute le changement le plus déterminant. Sans swap, le système n’a aucun filet de sécurité lorsque la RAM est pleine. En quelques lignes, on a ajouté une zone de 2 Go de swap :

sudo fallocate -l 2G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile

Et pour la rendre persistante au redémarrage :

echo '/swapfile none swap sw 0 0' sudo tee -a /etc/fstab

➡️ Résultat : plus de crashs ou de blocages, le système tient bien mieux sous charge.

🛠️ 2. Tuning de MariaDB

Limitation des connexions et des caches
Réduction de l’usage mémoire via innodb_buffer_pool_size
Désactivation de modules inutiles (query cache, performance schema)

⚡ 3. Activation d’OPcache pour PHP

Un cache qui évite de recompiler les scripts PHP à chaque appel. Configuration utilisée :

opcache.enable=1 opcache.memory_consumption=64 opcache.interned_strings_buffer=8 opcache.max_accelerated_files=4000

📂 4. Cache de chemins (realpath)

Pour éviter que PHP refasse constamment les mêmes recherches de fichiers :

realpath_cache_size = 4096k realpath_cache_ttl = 300

🔄 Mise à jour (19h48) : Passage à MariaDB 11.7 🎉

Suite à nos optimisations initiales, nous avons poussé encore plus loin la stabilité du serveur en migrant vers la toute dernière version de MariaDB : 11.7.2.

Ce changement nous permet :

de bénéficier des dernières améliorations de performance et de sécurité,
officiellement maintenue à long terme,
et de profiter d’un support optimal avec Debian 12.

👉 La migration s’est faite sans douleur grâce à un dépôt officiel et une bonne préparation (backup, test de compatibilité de la config, etc.).
Pour les curieux : mariadb --version affiche désormais fièrement 11.7.2

📌 Mise à jour du 24 avril

Plusieurs optimisations techniques ont été apportées à notre serveur. Nous sommes passés de mod_php (prefork) à mpm_event avec php-fpm pour une meilleure gestion des connexions simultanées, et avons nettoyé la configuration Apache en supprimant les restes de php8.2-fpm.

Côté PHP, nous avons installé et activé APCu afin d’améliorer la mise en cache des données utilisées par phpBB. Du côté de MariaDB, un tuning mémoire a été effectué (max_connections, buffers) ainsi que l’activation du slow query log pour faciliter l’analyse des performances.

Suite à la mise à jour vers MariaDB 11.7.2, nous avons supprimé plusieurs directives obsolètes (provider_lz4, etc.) et corrigé un problème de démarrage causé par des options héritées dans MYSQLD_OPTS.

Résultat : un site plus fluide, plus réactif et une base de données qui respire !

🛠 MAJ du 25/04/205 13h11 : Finalisation du tuning et disparition des lenteurs

Malgré les nombreuses optimisations apportées à notre serveur (MariaDB, cache, architecture Apache/PHP), des lenteurs aléatoires persistaient. Après analyse, nous avons identifié une saturation récurrente du pool PHP-FPM, limitant les connexions simultanées.

Nous avons donc augmenté les limites du pool de processus FPM :

pm.max_children porté à 24
ajustement des valeurs start_servers, min_spare_servers et max_spare_servers

Depuis ce changement, la charge est mieux absorbée et les lenteurs se sont résorbées. Cette dernière étape clôture le chapitre de l’optimisation serveur débuté quelques jours plus tôt 🧙‍♂️.

MAJ du 26/04/2025 : Script ultime d'optimisation :

Suite aux bons résultats obtenus, nous avons décidé d'aller encore plus loin en mettant en place un script d'optimisation complet de notre serveur.

Ce script a permis d'appliquer plusieurs ajustements clés :

MariaDB : ajustement de la taille du buffer InnoDB, désactivation de paramètres inutiles (adaptive hash index, query cache...), tuning des connexions pour mieux coller à notre usage (phpBB + Matomo).
Redis : installation d'un serveur Redis pour stocker les sessions PHP, réduisant la sollicitation du disque et accélérant la navigation.
PHP-FPM : passage du mode dynamic à ondemand pour mieux gérer les processus selon la charge, limitation plus stricte de la mémoire et du nombre de requêtes par processus pour éviter les débordements.
PHP.INI : augmentation des limites mémoire adaptées à nos applications, activation et configuration fine d’OPcache pour accélérer le traitement PHP.
Matomo : désactivation automatique des requêtes SQL d’optimisation coûteuses, afin de réduire la charge sur la base de données.
Apache : tuning du module MPM Event pour mieux répartir les connexions, activation de la compression (mod_deflate) et d'un cache navigateur (mod_expires) pour accélérer le chargement des pages et des ressources statiques.
Sécurité : masquage des versions logicielles exposées par Apache pour limiter la surface d’attaque.
Swap : vérification et création automatique d'un fichier swap si besoin, avec tuning des paramètres système (vm.swappiness, vm.vfs_cache_pressure) pour optimiser l'utilisation de la mémoire.

Grâce à toutes ces optimisations, notre site devrait être encore plus rapide, plus stable et mieux préparé pour accueillir du trafic ! 🚀

MAJ du 27/04 au 29/04 :🕵️ Analyse des lenteurs et limitation de certains accès

Afin d’identifier l’origine des lenteurs persistantes survenues certains jours, nous avons activé un slow log PHP (/var/log/php8.4-fpm.slow.log) enregistrant les scripts dépassant 3 secondes d’exécution. Cela nous a permis de repérer plusieurs scripts particulièrement gourmands appelés à haute fréquence, dont :

Ces scripts, pourtant Disallow dans notre robots.txt, ont été massivement sollicités par des bots indélicats, ignorant les consignes. Pour préserver les ressources du serveur, l’accès à ces pages a été restreint aux seuls utilisateurs connectés.

Une vérification est en cours sur la rotation des logs afin d’éviter la mésaventure de 2024 où 19 Go de logs avaient saturé le disque.