Bonjour,

Quels sont les fichiers qui remplissent ce disque ?
Pouvez-vous ajouter de l'espace dans le FS ?
L'instance est-elle en mode archivage des wal ? Et si oui, où sont stockés les journaux archivés ?

votre instance est arrêtée.
Il faut la relancer et comme c'est windows, normalement il suffit de lancer le service windows correspondant (dans le gestionnaire de service)

alors s'il n'y a pas de traces dans postgresql c'est que la demande de connexion n'arrive pas jusqu'au serveur postgresql.
Essayez de voir s'il n'y a pas un problème de firewall et assurez vous que l'instance est bien démarrée.

Bonjour,

Effectivement le paramètre archive-async=y permet de paralléliser l'archivage des WAL via pgbackrest.

Avec cett config par exemple, ça marche très bien (mettre un spool-path sur le FS des WAL, c'est conseillé pour les performances dixit la doc et calibrer process-max en fonction du nb de CPU du serveur) :

[global]
epo1-path=/mon_path_backup/
log-level-console=info
start-fast=y
process-max=6
archive-async=y
spool-path=/mon_path_wal/spool
[IPHDRX1]
pg1-path=/mon_path_admin/
repo1-retention-full-type=time
repo1-retention-full=7
repo1-retention-archive-type=full

Merci Marc pour les conseils !

bonjour Marc,

Une chose est sûr ce n'est pas le réseau (c'est à ça qu'on a pensé en premier en tant que facteur de contention, mais non).
pour le nombre de processus, vous parlez de process-max de pgbackrest.conf ? ça entre en jeu dans l'archivage ?
Pourtant dans les traces postgresql en peut voir qu'un seul processus (P00) est utilisé dans l'archivage.

Merci à tous pour vos réponses c'est plus clair maintenant.

et du coup avec pgbackrest, qui sait à tout moment tout ce qu'il a dans son repository, pas de problème.
Il faut que fasse des tests.

ah tiens je ne savais pas qu'on ne pouvait pas utiliser un restore point si celui ci est dans un WAL archivé... ça change tout effectivement.
En fait dans mon entreprise on est très friand des restore points "fonctionnels" à la sauce Oracle. Perso je préfère la technique PITR avec une date et une heure précise. Mais bon. il faut que je creuse ce point. ce n'est pas anodin.
Merci en tout cas c'est toujours intéressant d'avoir des avis éclairés.

180 connexions simultanées ? Si oui on peut atteindre les 14G juste pour les sessions actives, sans compter tout le reste qui tourne sur le serveur (y compris les autres process postgresql).
le mieux serait de faire un état des lieux système au moment où le problème de CPU intervient pour voir quel process surconsomme, pour voir l'état de la RAM/SWAP.
Si le CPU est surconsommé par des sessions PostgreSQL, peut être faudrait-il voir du côté des requêtes qui passe à ce moment là. Peut être certaines sont mal écrites et/ou ont de mauvais explain plans.

je pense qu'il y a 2 problèmes potentiel ici :
Pas assez de RAM sur le serveur car avec 1000 connections simultannées potentielles multipliées par 82MB par session on peut atteindre 80G de mémoire utilisée donc avec le risque de saturer le serveur (swap notamment).
Ensuite quand la swap est saturée il existe un process linux "kswapd" qui tente de faire du ménage en utilisant beaucoup de CPU.
Donc c'est normal qu'en rebootant le serveur tout redevienne normal (au moins au début...)
tout ceci n'est qu'une piste parmi d'autres.