Gestión de conexiones
Las conexiones a su despliegue Databases for PostgreSQL utilizan recursos, por lo que es importante tener en cuenta cuántas conexiones necesita para ajustar el rendimiento de su despliegue. PostgreSQL utiliza el valor max_connections
para limitar el número de conexiones (y los recursos consumidos por las conexiones) para evitar que el comportamiento de la conexión en ejecución sobrepase los recursos del despliegue.
Puede comprobar el valor de max_connections
con el usuario administrativo y psql
.
ibmclouddb=> SHOW max_connections;
max_connections
-----------------
115
(1 row)
límites de conexiones
En el suministro, Databases for PostgreSQL establece el número máximo de conexiones a la base de datos PostgreSQL en 115. Se reservan 15 conexiones para que el superusuario mantenga el estado y la integridad de la base de datos, y hay 100 conexiones disponibles para usted y sus aplicaciones. Si el número de conexiones a la base de datos supera el límite de 100 conexiones, las nuevas conexiones fallan y devuelven un error.
FATAL: remaining connection slots are reserved for
non-replication superuser connections
La superación del límite de conexiones para el despliegue puede hacer que la base de datos deje de ser accesible para las aplicaciones.
Puede comprobar el número de conexiones en el despliegue con el usuario administrador, psql
y pg_stat_database
.
SELECT count(distinct(numbackends)) FROM pg_stat_database;
Si necesita averiguar hacia dónde van las conexiones, puede desglosar las conexiones por base de datos.
SELECT datname, numbackends FROM pg_stat_database;
Para investigar las conexiones a una base de datos específica con más detalle, consulte pg_stat_activity
.
SELECT * FROM pg_stat_activity WHERE datname='ibmclouddb';
Terminar conexiones
El usuario administrativo tiene el rol pg_signal_backend
. Si encuentra conexiones que deben restablecerse o cerrarse, el usuario administrador puede utilizar tanto ' pg_cancel_backend
y pg_terminate_backend
. El pid
de un proceso se encuentra en la tabla pg_stat_activity
.
-
pg_cancel_backend
cancela la consulta actual de una conexión sin terminar la conexión ni detener ninguna otra consulta que pueda estar en ejecución.SELECT pg_cancel_backend(pid);
-
pg_terminate_backend
detiene todo el proceso y cierra la conexión.SELECT pg_terminate_backend(pid);
El usuario administrador tiene la capacidad de restablecer o cerrar las conexiones de cualquier usuario en el despliegue, excepto de los superusuarios. Tenga cuidado de no terminar las conexiones de réplica del usuario ibm-replication
,
ya que esto interfiere con la alta disponibilidad del despliegue.
Finalizar conexiones
Si su implantación alcanza el límite de conexiones o tiene problemas para conectarse a su implantación y sospecha que el problema es un número elevado de conexiones, desconecte todas las conexiones a su implantación.
En la interfaz de usuario, en la pestaña Valores, hay un botón para End connections
en el despliegue. Tenga cuidado, ya que interrumpe cualquier cosa que esté conectada al despliegue.
El comando CLI para finalizar las conexiones al despliegue es:
ibmcloud cdb deployment-kill-connections <DEPLOYMENT_NAME_OR_CRN>
También puede utilizar la API de Cloud Databases para llevar a cabo la operación de finalizar todas las conexiones.
técnica de agrupación de conexiones
Una manera de evitar que se supere el límite de conexiones y garantizar que las conexiones de las aplicaciones se gestionan de forma eficiente es a través de la agrupación de conexiones. Si se encuentra estableciendo el límite de conexión de IBM Cloud® Databases for PostgreSQL en más de 500 conexiones, debe considerar seriamente utilizar la agrupación de conexiones o reevaluar cómo utilizar y mantener conexiones de forma más eficiente. El benchmarking de rendimiento en la comunidad PostgreSQL sugiere 500 conexiones o menos para ser óptimo para el rendimiento de la base de datos
Muchas bibliotecas de controladores de PostgreSQL tienen clases y funciones de agrupación de conexiones. Debe consultar la documentación del controlador para implementar una técnica de agrupación de conexiones que sea óptima para su caso de uso. Por ejemplo, el controlador Python Psycopg2 tiene clases para manejar la agrupación de conexiones en su aplicación. El controlador Java PostgreSQL JDBC tiene métodos para la agrupación de conexiones tanto a nivel de aplicación como de servidor de aplicaciones.
Alternativamente, puedes utilizar una herramienta de terceros como PgBouncer para gestionar las conexiones de tu aplicación.
Aumento del límite de conexiones
PostgreSQL asigna cierta cantidad de memoria por conexión, normalmente entre 5 y 10 MB por conexión. Es importante tener en cuenta la cantidad total de memoria disponible para el despliegue antes de aumentar el límite de conexiones. Para aumentar el límite de conexiones, es posible que en primer lugar quiera escalar el despliegue para asegurarse de que haya memoria suficiente para dar cabida a más conexiones.
A continuación, cambie el valor de max_connections
en el despliegue. Para hacer realizar cambios permanentes en la Configuración de PostgreSQL,
debe utilizar el Cloud Databases plugin de CLI o la API para escribir los cambios en el archivo de configuración del despliegue.
Por ejemplo, para aumentar el valor de max_connections
a 215, puede ser buena idea escalar el despliegue al menos a 2 GB de RAM por miembro de datos, con un total de 4 GB de RAM para el despliegue. Una vez que haya finalizado la
operación de escalado, establezca el límite de conexiones.
- Antes de ajustar
max_connections
, asegúrese de apuntar a su región preferida con un comando como:
ibmcloud target -r <REGION>
- A continuación, aumente la cantidad de memoria disponible para un grupo de despliegue con un mandato como:
ibmcloud cdb deployment-groups-set deployment-example member --memory 4096
- Por último, ajuste
max_connections
con un mandato como:
ibmcloud cdb deployment-configuration <DEPLOYMENT_NAME_OR_CRN> '{"configuration":{"max_connections":215}}'
Para realizar los cambios a través de la API, utilice el siguiente comando:
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
}
}'
Límites de conexión y valores de keepalive de TCP/IP
En el caso de una conexión de red o una conmutación por error, es posible que las conexiones TCP/IP interrumpidas permanezcan en un estado de semiabierto/cerrado hasta que se alcancen los tiempos de espera de TCP keepalive. Para evitar este
escenario, establezca también los valores socket_timeout
y connection_timeout
en los controladores de aplicación específicos. Los valores correctos varían en función de la carga de trabajo específica y es importante ejecutar pruebas de carga antes de pasar a producción.
Un buen punto de partida para el " connection_timeout
" es de 2 a 5 segundos. Para el " socket_timeout
", un buen punto de partida es de 30 a 60 segundos.
Además, en el lado del servidor, se utilizan las siguientes configuraciones de keepalive como valor predeterminado.
tcp_keepalives_idle
se establece en 5 minutos- El intervalo de sondeo de
tcp_keepalives_interval
se establece en 10 segundos tcp_keepalives_count
se establece en 6
Para evitar que las conexiones medio abiertas/cerradas o las ráfagas de intentos de conexión saturen su despliegue, establezca el " parámetro max_connections
" para el " Postgres " en al menos el doble de su recuento de conexiones previsto.
Si se alcanza el límite de conexiones, puede finalizar todas las conexiones inmediatamente.