Gestion des connexions
Les connexions à votre déploiement Databases for PostgreSQL utilisent des ressources, il est donc important de prendre en compte le nombre de connexions dont vous avez besoin pour ajuster les performances de votre déploiement. PostgreSQL utilise
un paramètre max_connections
permettant de limiter le nombre de connexions (et de ressources consommées par les connexions) afin d'empêcher qu'un comportement de connexion hors de contrôle ne vienne surcharger les ressources de
votre déploiement.
Vous pouvez vérifier la valeur de max_connections
avec votre administrateur et psql
.
ibmclouddb=> SHOW max_connections;
max_connections
-----------------
115
(1 row)
limites de connexion
A disposition, Databases for PostgreSQL définit le nombre maximal de connexions à votre base de données PostgreSQL vers 115. 15 connexions sont réservées au superutilisateur pour le maintien de l'état et de l'intégrité de votre base de données, et 100 connexions sont disponibles pour vous et vos applications. Si le nombre de connexions à la base de données dépasse la limite de 100 connexions, les nouvelles connexions échouent et renvoient une erreur.
FATAL: remaining connection slots are reserved for
non-replication superuser connections
Le dépassement du nombre limite de connexions pour votre déploiement peut rendre votre base de données inaccessible pour vos applications.
Vous pouvez vérifier le nombre de connexions à votre déploiement à l'aide de l'administrateur, psql
et pg_stat_database
.
SELECT count(distinct(numbackends)) FROM pg_stat_database;
Si vous devez déterminer la destination des connexions, vous pouvez les répartir par base de données.
SELECT datname, numbackends FROM pg_stat_database;
Pour plus d'informations sur les connexions à une base de données spécifique, lancez une requête sur pg_stat_activity
.
SELECT * FROM pg_stat_activity WHERE datname='ibmclouddb';
Arrêt des connexions
Votre administrateur dispose du rôle pg_signal_backend
. If you find connections that need to reset or be closed, the Admin user can use both pg_cancel_backend
et " pg_terminate_backend
. Le pid
d'un processus figure dans le tableau pg_stat_activity
.
-
pg_cancel_backend
annule la requête en cours d'une connexion sans mettre fin à la connexion et sans arrêter aucune des éventuelles requêtes qu'elle est en train d'exécuter.SELECT pg_cancel_backend(pid);
-
pg_terminate_backend
arrête l'ensemble du processus et ferme la connexion.SELECT pg_terminate_backend(pid);
L'administrateur a le pouvoir de réinitialiser ou fermer les connexions de n'importe quel utilisateur du déploiement, à l'exception des superutilisateurs. Prenez soin de ne pas arrêter les connexions de réplication à partir de l'utilisateur
ibm-replication
, car cela interfère avec la haute disponibilité de votre déploiement.
Arrêt des connexions
Si votre déploiement atteint la limite de connexion ou si vous avez des difficultés à vous connecter à votre déploiement et que vous pensez qu'un nombre élevé de connexions est à l'origine du problème, déconnectez toutes les connexions à votre déploiement.
Dans l'interface utilisateur, dans l'onglet Paramètres , vous accédez à End connections
à votre déploiement. Soyez prudent car cela entraînera l'interruption de toutes les connexions établies avec votre déploiement.
La commande CLI pour mettre fin aux connexions au déploiement est la suivante :
ibmcloud cdb deployment-kill-connections <DEPLOYMENT_NAME_OR_CRN>
Vous pouvez également utiliser l'APICloud Databases pour exécuter toutes les opérations d'arrêt de connexions.
regroupement de connexions
Le regroupement de connexions est l'un des moyens permettant de prévenir le dépassement du nombre limite de connexions et de garantir que les connexions à partir de vos applications sont gérées efficacement. Si vous définissez vous-même la limite de connexion IBM Cloud® Databases for PostgreSQL sur plus de 500 connexions, vous devez envisager sérieusement d'utiliser le regroupement de connexions ou de réévaluer la façon d'utiliser et de gérer plus efficacement les connexions. L'analyse comparative des performances dans la communauté PostgreSQL suggère que 500 connexions ou moins sont optimales pour les performances de la base de données.
De nombreuses bibliothèques de pilotes PostgreSQL possèdent des classes et des fonctions de regroupement de connexions. Vous devez vous reporter à la documentation de votre pilote pour implémenter le regroupement de connexions optimal pour votre cas d'utilisation. Par exemple, le pilote Python Psycopg2 comporte des classes permettant de gérer la mise en commun des connexions dans votre application. Le pilote JDBC Java PostgreSQL dispose de méthodes de mise en commun des connexions au niveau de l'application et du serveur d'application.
Vous pouvez également utiliser un outil tiers tel que PgBouncer pour gérer les connexions de votre application.
Augmentation du nombre limite de connexions
PostgreSQL alloue une certaine quantité de mémoire par connexion, typiquement entre 5 et 10 Mo par connexion. Il est important de prendre en compte la quantité totale de mémoire disponible pour votre déploiement avant d'augmenter le nombre limite de connexions. Avant d'augmenter le nombre limite de connexions, il peut être judicieux d'augmenter la capacité de votre déploiement afin de vous assurer que vous disposez de suffisamment de mémoire pour prendre en charge davantage de connexions.
Modifiez ensuite la valeur de max_connections
sur votre déploiement. Pour apporter des modifications permanentes à la configuration dePostgreSQL,
vous voulez utiliser le cli-plugin ou l'API Cloud Databases pour écrire les modifications dans le fichier de configuration de votre déploiement.
Par exemple, pour augmenter la valeur de max_connections
à 215, il peut être judicieux d'augmenter la capacité de votre déploiement à au moins 2 Go de mémoire RAM par membre de données, pour un total de 4 Go de mémoire RAM pour
votre déploiement. Une fois l'opération d'augmentation de capacité terminée, définissez le nombre de limite de connexions.
- Avant d'ajuster
max_connections
, assurez-vous de cibler votre région préférée à l'aide d'une commande telle que :
ibmcloud target -r <REGION>
- Ensuite, augmentez la quantité de mémoire disponible pour un groupe de déploiement à l'aide d'une commande telle que la suivante:
ibmcloud cdb deployment-groups-set deployment-example member --memory 4096
- Enfin, ajustez
max_connections
à l'aide d'une commande telle que la suivante:
ibmcloud cdb deployment-configuration <DEPLOYMENT_NAME_OR_CRN> '{"configuration":{"max_connections":215}}'
Pour effectuer les modifications via l'API, utilisez la commande suivante :
curl -X PATCH `https://api.{region}.databases.cloud.ibm.com/v5/ibm/deployments/{id}/groups/member' \
-H "Authorization: Bearer $APIKEY" \
-H "Content-Type: application/json" \
-d '{"memory": {
"allocation_mb": 4096
}
}'
curl -X PATCH 'https://api.{region}.databases.cloud.ibm.com/v5/ibm/deployments/{id}/configuration' \
-H "Authorization: Bearer $APIKEY" \
-H "Content-Type: application/json" \
-d '{"configuration":{
"max_connections":215
}
}'
Paramètres de limites de connexion et de signal de présence TCP/IP
En cas de connexion réseau ou de basculement, il est possible que les connexions TCP/IP interrompues restent dans un état semi-ouvert/fermé jusqu'à ce que les délais TCP keepalive soient atteints. Pour éviter ce scénario, définissez également
les paramètres socket_timeout
et connection_timeout
dans vos pilotes d'application spécifiques. Paramètres corrects Varient en fonction de la charge de travail spécifique et il est important d'exécuter des tests de charge avant d'aller à la production.
Un bon point de départ pour le " connection_timeout
est de 2 à 5 secondes. Pour le " socket_timeout
, un bon point de départ est de 30 à 60 secondes.
En outre, côté serveur, les configurations de signal de présence suivantes sont utilisées comme valeur par défaut.
tcp_keepalives_idle
est défini sur 5 minutestcp_keepalives_interval
L'intervalle de vérification est défini sur 10 secondestcp_keepalives_count
est défini sur 6
Pour éviter que des connexions semi-ouvertes/fermées ou des tentatives de connexion en rafale ne submergent votre déploiement, définissez le " paramètre max_connections
pour le " Postgres à au moins le double du nombre de connexions prévu.
Si votre limite de connexion est atteinte, vous pouvez mettre fin à toutes les connexions immédiatement.