Y a-t-il un délai pour les connexions PostgreSQL inactives?

1 S postgres  5038   876  0  80   0 - 11962 sk_wai 09:57 ?        00:00:00 postgres: postgres my_app ::1(45035) idle                                                                                 
1 S postgres  9796   876  0  80   0 - 11964 sk_wai 11:01 ?        00:00:00 postgres: postgres my_app ::1(43084) idle             

J'en vois beaucoup. Nous essayons de réparer notre fuite de connexion. Mais en attendant, nous voulons définir un délai d'expiration pour ces connexions inactives, peut-être jusqu'à 5 minutes maximum.

Il semble que vous ayez une fuite de connexion dans votre application car elle ne parvient pas à fermer les connexions groupées . Vous ne rencontrez pas de problèmes uniquement avec les <idle> in transactionsessions, mais avec trop de connexions en général.

Tuer les connexions n'est pas la bonne réponse pour cela, mais c'est une solution de contournement temporaire OK.

Plutôt que de redémarrer PostgreSQL pour démarrer toutes les autres connexions à partir d'une base de données PostgreSQL, consultez: Comment détacher tous les autres utilisateurs d'une base de données postgres? et Comment supprimer une base de données PostgreSQL s'il y a des connexions actives? . Ce dernier montre une meilleure requête.

Pour définir les délais d'expiration, comme @Doon l'a suggéré, consultez Comment fermer automatiquement les connexions inactives dans PostgreSQL? , qui vous conseille d'utiliser PgBouncer pour proxy pour PostgreSQL et gérer les connexions inactives. C'est une très bonne idée si vous avez une application boguée qui perd de toute façon des connexions; Je recommande fortement de configurer PgBouncer.

Un keepalive TCP ne fera pas le travail ici, car l'application est toujours connectée et vivante, elle ne devrait tout simplement pas l'être.

Dans PostgreSQL 9.2 et versions ultérieures, vous pouvez utiliser la nouvelle state_changecolonne d'horodatage et le statechamp de pg_stat_activitypour implémenter un outil de récupération de connexion inactif. Demandez à une tâche cron d'exécuter quelque chose comme ceci:

SELECT pg_terminate_backend(pid)
    FROM pg_stat_activity
    WHERE datname = 'regress'
      AND pid <> pg_backend_pid()
      AND state = 'idle'
      AND state_change < current_timestamp - INTERVAL '5' MINUTE;

Dans les anciennes versions, vous devez implémenter des schémas complexes qui permettent de suivre le moment où la connexion est devenue inactive. Ne pas déranger; utilisez simplement pgbouncer.

Dans PostgreSQL 9.6, il existe une nouvelle option idle_in_transaction_session_timeoutqui devrait accomplir ce que vous décrivez. Vous pouvez le définir à l'aide de la SETcommande, par exemple:

SET SESSION idle_in_transaction_session_timeout = '5min';

Dans PostgreSQL 9.1, les connexions inactives avec la requête suivante. Cela m'a aidé à éviter la situation qui justifiait le redémarrage de la base de données. Cela se produit principalement avec les connexions JDBC ouvertes et non fermées correctement.

SELECT
   pg_terminate_backend(procpid)
FROM
   pg_stat_activity
WHERE
   current_query = '<IDLE>'
AND
   now() - query_start > '00:10:00';

si vous utilisez postgresql 9.6+, vous pouvez définir dans votre postgresql.conf

idle_in_transaction_session_timeout = 30000 (msec)

Une solution de contournement possible qui permet d'activer le délai d'expiration de session de base de données sans tâche planifiée externe consiste à utiliser l'extension pg_timeout que j'ai développée.