Configuration de la mémoire de la base de données selon votre palier
Valeurs de buffers concrètes pour PostgreSQL et MySQL pour VDS-1…VDS-6, et une règle pour répartir la mémoire entre la base de données, l'application et le système.
Mis à jour le 23 août 2026
Les paramètres par défaut des bases de données sont conçus pour démarrer partout, pas pour être rapides. Sur un VDS-3 avec 8 Go de mémoire, PostgreSQL en sortie de boîte utilise 128 Mo pour le cache — ce qui signifie qu'il lit presque tout depuis le disque, alors qu'il pourrait lire depuis la mémoire.
Règle d'allocation
Répartissez la mémoire du palier à peu près ainsi :
- les processus système et de service — 10–15 % ;
- l'application (PHP-FPM, Node, gunicorn) — selon le nombre de workers ;
- la base de données — tout ce qui reste, mais pas plus de 60–70 % de la mémoire totale.
Ne donnez jamais toute la mémoire à la base de données : le système passera en swap, et le NVMe ne vous sauvera pas — la latence augmentera de plusieurs dizaines de fois.
Ce qui est utilisé en ce moment :
free -h
ps -eo pmem,rss,comm --sort=-rss | head
Les graphiques de mémoire sur une heure, un jour, une semaine et un mois sont disponibles dans « Vue d'ensemble » du panneau /hosting/vds/m/<id> — ils montrent le pic réel, pas l'instant présent.
PostgreSQL
/etc/postgresql/17/main/postgresql.conf :
| Palier | shared_buffers | effective_cache_size | work_mem | maintenance_work_mem | max_connections |
|---|---|---|---|---|---|
| VDS-1 (2 Go) | 384MB | 1GB | 8MB | 96MB | 40 |
| VDS-2 (4 Go) | 1GB | 2GB | 12MB | 256MB | 60 |
| VDS-3 (8 Go) | 2GB | 5GB | 16MB | 512MB | 100 |
| VDS-4 (16 Go) | 4GB | 10GB | 24MB | 1GB | 150 |
| VDS-5 (24 Go) | 6GB | 16GB | 32MB | 2GB | 200 |
| VDS-6 (32 Go) | 8GB | 22GB | 48MB | 2GB | 250 |
Plus les réglages généraux pour le NVMe :
random_page_cost = 1.1
effective_io_concurrency = 200
work_mem est alloué par opération de tri, pas par connexion : une centaine de requêtes parallèles avec un tri complexe le multiplieront par centaines. Ne le réglez pas trop haut.
Application : systemctl restart postgresql (modifier shared_buffers nécessite précisément un redémarrage).
MySQL et MariaDB
| Palier | innodb_buffer_pool_size | innodb_log_file_size | max_connections |
|---|---|---|---|
| VDS-1 | 512M | 128M | 60 |
| VDS-2 | 1G | 256M | 100 |
| VDS-3 | 3G | 512M | 150 |
| VDS-4 | 8G | 1G | 200 |
| VDS-5 | 12G | 1G | 250 |
| VDS-6 | 18G | 2G | 300 |
innodb_flush_method = O_DIRECT
innodb_flush_log_at_trx_commit = 1
innodb_io_capacity = 2000
Le buffer pool est le paramètre principal : s'il contient le jeu de données de travail, le disque n'est presque pas lu.
Vérification de l'effet
SELECT sum(blks_hit)*100/sum(blks_hit+blks_read) FROM pg_stat_database;
Pour MySQL, regardez SHOW ENGINE INNODB STATUS et le rapport entre Innodb_buffer_pool_reads et Innodb_buffer_pool_read_requests. Un taux de succès du cache inférieur à 95 % signifie que la base de données manque de mémoire.
Erreurs courantes
| Symptôme | Cause |
|---|---|
| La base de données ne démarre pas après une modification | Plus de mémoire demandée que disponible — vérifiez le journal |
| Le processus a été tué par l'OOM | La base de données, l'application et le système dépassent ensemble la mémoire du palier |
| C'est devenu plus lent après « optimisation » | work_mem est réglé trop haut, la machine swappe |
| Le disque est constamment lu | Les buffers sont trop petits, le jeu de travail ne tient pas |
Si vous vous heurtez encore à un mur après avoir réglé la mémoire, le problème vient du volume de données, pas de la configuration. Vous ne pouvez qu'augmenter votre offre, avec un paiement au prorata pour les jours restants de la période payée ; les rétrogradations ne sont pas disponibles, alors choisissez le palier suivant en connaissance de cause.