Optimiseur PostgreSQL
Moteur de performance de production pour PostgreSQL

PostgreSQL (postgresql.conf) Hardware Tuner & Builder

Calculez et générez des paramètres postgresql.conf optimisés en fonction des spécifications matérielles (shared_buffers, work_mem, effective_cache_size, max_connections).

Exécution client sans aucune télémétrie
Préréglages :
Entrée
Total System RAM (Memory)
GB RAM
Physical / Virtual CPU Cores
Cœurs
Connexions
clients
~41MB work_mem/connexion
RAM: 32GB•CPU: 8 Cœurs•Workload: web•Storage: nvme
# ----------------------------------------------------------------------
# PostgreSQL 17 Hardware-Tuned Configuration
# Target Profile: WEB | RAM: 32GB | CPU: 8 Cores | Storage: NVME
# Generated: 2026-01-01T00:00:00.000Z via ToolsAA Client-Side Tuner
# ----------------------------------------------------------------------

# CONNECTIONS & NETWORKING
max_connections = 200
# Note: Transaction pooler (PgBouncer) is assumed in front of PostgreSQL.

# MEMORY ALLOCATION
shared_buffers = 8GB
effective_cache_size = 24GB
maintenance_work_mem = 1.6GB
work_mem = 41MB
wal_buffers = 16MB
huge_pages = try

# CHECKPOINT & WAL ENGINE
checkpoint_completion_target = 0.9
checkpoint_timeout = 15min
min_wal_size = 2GB
max_wal_size = 16GB
wal_compression = zstd
synchronous_commit = on

# QUERY PLANNER & DISK I/O TUNING
random_page_cost = 1.05
effective_io_concurrency = 300
default_statistics_target = 100
jit = off

# PARALLEL QUERY WORKERS
max_worker_processes = 8
max_parallel_workers_per_gather = 4
max_parallel_workers = 8
max_parallel_maintenance_workers = 4

# TELEMETRY & DIAGNOSTICS
track_io_timing = on
track_functions = pl
log_min_duration_statement = 1000   # Log queries exceeding 1000ms
log_checkpoints = on
log_connections = on
log_disconnections = on
log_lock_waits = on
shared_buffers: 8GB•work_mem: 41MB•effective_cache: 24GB
Shared Buffers Allocation
8GB

Cache mémoire central de PostgreSQL (~25% de la RAM physique totale).

Effective Cache Size
24GB

Cache disque estimé de l'OS disponible pour les analyses d'index (~75% RAM).

Parallel Query Pool
8 Workers

4 workers parallèles par nœud gather sur 8 Cœurs

Exécution Locale Zero-Knowledge

Tous les traitements, analyses et générations s'exécutent strictement dans la mémoire de votre navigateur. Zéro transmission vers un serveur externe.

Moteur Réactif Submilliseconde

All data payloads remain strictly local with zero external server communication.

Production Ready Export

Clean, optimized output formats ready for immediate deployment.

Référence technique et guide d'architecture

Guide Développeur : Optimiseur et Générateur Hardware pour PostgreSQL (postgresql.conf) — Guide de référence

Calculez et générez des paramètres postgresql.conf optimisés en fonction des spécifications matérielles (shared_buffers, work_mem, effective_cache_size, max_connections).

Paramètres clés et contrôles

shared_buffersstring (memory_size)

Tampon de mémoire partagée dédié à PostgreSQL pour la mise en cache des pages de tables et d'index.

Par défaut : 25 % de la RAM totale (ex. : 4 Go pour un serveur de 16 Go)
work_memstring (memory_size)

Mémoire allouée par nœud de requête pour les tris internes et tables de hachage avant déversement sur disque temporaire.

Par défaut : ((RAM totale - shared_buffers) / (max_connections * 3)) ~ 16 Mo - 64 Mo
effective_cache_sizestring (memory_size)

Estimation consultée par le planificateur de requêtes sur la mémoire disponible pour le cache disque (PostgreSQL + cache du noyau de l'OS).

Par défaut : 50 % - 75 % de la RAM totale (ex. : 12 Go pour 16 Go de RAM)
maintenance_work_memstring (memory_size)

Mémoire maximale allouée aux opérations de maintenance telles que VACUUM, CREATE INDEX et l'ajout de clés étrangères.

Par défaut : 5 % - 10 % de la RAM totale (jusqu'à 2 Go)
max_connectionsinteger

Nombre maximal de connexions clientes simultanées autorisées par l'instance PostgreSQL.

Par défaut : 100 (Défaut) / 20-50 derrière PgBouncer

Conseils de pro et bonnes practices

Évitez de définir un paramètre

Évitez de définir un paramètre max_connections excessif (> 200) directement dans postgresql.conf. Utilisez PgBouncer en mode transaction pour restreindre les connexions actives et allouer sereinement un work_mem beaucoup plus important.

Sur les disques modernes SSD/NVMe

Sur les disques modernes SSD/NVMe, abaissez random_page_cost de 4.0 (défaut) à 1.1 et définissez effective_io_concurrency à 200. Le planificateur favorisera ainsi les parcours d'index, sachant que les accès aléatoires sont quasi instantanés.

Définissez

Définissez checkpoint_completion_target = 0.9 et augmentez max_wal_size à 16 Go - 32 Go sur les bases à fortes écritures pour répartir les écritures disque de manière fluide tout au long de l'intervalle de contrôle.

Lorsque shared_buffers atteint ou

Lorsque shared_buffers atteint ou dépasse 8 Go, activez les Huge Pages sous Linux (vm.nr_hugepages) et configurez huge_pages = try dans postgresql.conf pour limiter les défauts de cache TLB et la surcharge mémoire du noyau.

Pièges courants et dépannage

L'OOM Killer de Linux interrompt brutalement des processus d'arrière-plan PostgreSQL

Réduisez work_mem ou diminuez max_connections. N'oubliez pas que work_mem est alloué par opération de tri ou de hachage au sein d'une même requête, ce qui peut multiplier la consommation sur des requêtes complexes.

FATAL: could not create shared memory segment: Cannot allocate memory au démarrage

Vérifiez les paramètres du noyau Linux (sysctl vm.max_map_count) ainsi que la RAM disponible. Assurez-vous que shared_buffers ne dépasse pas la mémoire physique ou les quotas cgroup des conteneurs.

Avertissements récurrents dans les journaux : checkpoints are occurring too frequently

Augmentez max_wal_size (ex. : de 1 Go à 16 Go) et allongez checkpoint_timeout (ex. : de 5 min à 15 min) pour éviter les déclenchements anticipés dus à la saturation des segments WAL.

Foire aux questions (FAQ)

Pourquoi shared_buffers est-il généralement limité à 25 % - 40 % de la RAM sous Linux ?▼

PostgreSQL utilise une architecture à double cache où shared_buffers collabore avec le cache de pages du noyau Linux. Dépasser 40 % génère souvent des doublons en mémoire, dégrade le cache du système de fichiers et amplifie les pics d'écriture lors des checkpoints.

Le paramètre effective_cache_size consomme-t-il réellement de la mémoire physique ?▼

Non. effective_cache_size est une simple directive consultative pour l'optimiseur de requêtes. Il lui permet d'estimer si les pages d'index se trouvent déjà dans le cache de l'OS, sans réserver le moindre octet de mémoire vive.

Quelle est la différence fondamentale entre work_mem et maintenance_work_mem ?▼

work_mem est alloué dynamiquement par étape de tri ou de hachage lors des requêtes courantes des utilisateurs. À l'inverse, maintenance_work_mem est réservé aux tâches d'administration (VACUUM, CREATE INDEX, REINDEX) et peut être beaucoup plus élevé car très peu de ces opérations s'exécutent en parallèle.

Comment adapter la configuration entre les charges OLTP et OLAP (Data Warehouse) ?▼

Les environnements transactionnels OLTP à forte concurrence requièrent un work_mem maîtrisé et des connexions contrôlées pour une latence minimale. Les environnements décisionnels OLAP bénéficient d'un work_mem nettement plus élevé (ex. : 256 Mo - 1 Go) et d'un max_parallel_workers_per_gather plus important pour accélérer les calculs distribués.

Outils et utilitaires connexes

Tous les outils →
Guide Développeur du Générateur d'Unités Systemd (.timer et .service) sous LinuxDéveloppement

Créez et structurez des unités de minuterie systemd et des services associés prêts pour la production avec planification OnCalendar, intervalles OnBootSec, exécution Persistent et délais aléatoires.

Ouvrir l'outil→
Guide Développeur du Générateur de Configuration TypeScript (tsconfig.json)Développement

Générez des configurations tsconfig.json modernes et robustes pour Next.js, Node.js, Vite ou bibliothèques avec mode strict, alias de chemins et résolution de modules.

Ouvrir l'outil→
Guide Développeur : Générateur de DDL CREATE TABLE JSON vers ClickHouseDéveloppement

Convertissez des documents JSON en DDL SQL ClickHouse avec moteur MergeTree, types UInt/Int/Float/String/DateTime et mappage de colonnes Array/Nested.

Ouvrir l'outil→
Guide Développeur : Générateur de Schéma de Table Google BigQuery depuis JSONDéveloppement

Déduisez et convertissez des objets JSON en schémas de table Google Cloud BigQuery au format JSON avec prise en charge des types RECORD, STRING, INTEGER, NUMERIC et TIMESTAMP.

Ouvrir l'outil→
Guide Développeur : Générateur de DDL CREATE TABLE JSON vers SnowflakeDéveloppement

Convertissez vos structures et charges utiles JSON en instructions SQL CREATE TABLE prêtes pour la production dans Snowflake avec des types de données optimisés tels que VARIANT, VARCHAR, NUMBER, BOOLEAN et TIMESTAMP_NTZ.

Ouvrir l'outil→
Guide Développeur : Générateur de Variables et Locals Terraform HCL depuis JSON / YAMLDéveloppement

Convertissez des structures JSON et YAML en contraintes de types HCL Terraform (type = object({...})), valeurs par défaut, blocs locals et fichiers terraform.tfvars.

Ouvrir l'outil→