Symptômes observés

Les équipes qui font tourner PostgreSQL à l’échelle rencontrent fréquemment cinq problèmes : ingestion qui passe de secondes à minutes, latence de lecture P95 qui monte de millisecondes à secondes, autovacuum qui ne suit plus les UPDATE, checkpoints qui monopolissent les ressources, et retard de réplication logique vers Kafka ou ClickHouse. Ces symptômes apparaissent généralement quand le volume de données dépasse plusieurs centaines de gigaoctets.

Impact du stockage

Lorsque le jeu de données excède la capacité du cache OS, chaque lecture nécessite un accès physique. Sur un stockage lent, le coût d’accès et les files d’attente augmentent, ce qui gonfle à la fois la latence moyenne et la latence de queue. Les mêmes bandes passantes sont partagées entre les requêtes client, les écritures de heap et d’index, la synchronisation du WAL, les opérations de VACUUM et le décodage logique. Ainsi, un goulet d’étranglement au niveau IOPS ou de bande passante entraîne des retards mutuels, expliquant pourquoi des problèmes apparemment distincts ont souvent une cause commune : le stockage.

Benchmark NVMe vs EBS

Pour isoler le facteur stockage, Sai Srirampur a déployé huit clusters PostgreSQL identiques : quatre sur des disques NVMe locaux et quatre sur des volumes gp3 EBS provisionnés à 3 000 IOPS. Chaque instance était un m6id.4xlarge (16 vCPU, 64 GiB RAM, 16 GiB shared_buffers). Le jeu de données était un tableau pgbench_accounts de 482 GiB contenant 3,3 milliards de lignes. Le test consistait en une charge aléatoire d’UPDATE avec 64 clients et 16 threads pendant cinq minutes :

1 \ set aid random( 1 , 3300000000 )
2 UPDATE pgbench_accounts SET abalance = abalance + 1 WHERE aid = :aid;

Les résultats montrent un débit médian de 16 030 TPS sur NVMe contre 1 734 TPS sur EBS, soit un facteur 9,24×. La latence médiane est passée de 36,9 ms à 4,0 ms. Un VACUUM de 10 GiB de bloat a nécessité 366 s sur NVMe contre 964 s sur EBS, et le rattrapage d’un backlog de réplication logique de 10 GiB a duré 139 s contre 238 s. Ces écarts confirment que le coût d’accès passe de l’ordre de la milliseconde sur le réseau à quelques dizaines de microsecondes en local.

Recommandations pour la production

Le principal levier d’amélioration consiste à placer les fichiers de données, les WAL et les répertoires de travail sur un stockage NVMe local, tout en conservant les sauvegardes sur des volumes réseau. Cette architecture minimise les temps de flush du WAL, réduit la durée des checkpoints et libère la bande passante nécessaire aux opérations de maintenance. Il reste toutefois essentiel de surveiller la capacité du cache OS : si le working set dépasse la RAM disponible, même le NVMe le plus rapide sera sollicité. En combinant NVMe local avec une configuration de shared_buffers proportionnelle à la RAM (par ex. 25 % de la mémoire), les équipes peuvent atténuer les cinq symptômes décrits et restaurer une latence prévisible.