¿Hay alguna forma de verificar cómo se usa realmente la memoria asignada a cada conexión?
Después de actualizar de PostgreSQL 9.3 a PG 12, el uso de memoria para cada conexión de PostgreSQL se duplicó o incluso triplicó. Así que tuve que pasar de una máquina de 32 GB con: shared_buffers = 8 GB de memoria utilizada para conexiones = 8 GB de memoria para búfer de disco = 16 GB A: máquina de 64 GB con: shared_buffers = 8 GB de memoria utilizada para conexiones = 40 GB de memoria para búfer de disco = 16 GB
Y todavía no es suficiente. No es raro que una sola conexión llegue a usar 170 MB de RAM privada ( Private en smaps , como se describe en https://www.depesz.com/2012/06/09/how-much-ram-is-postgresql-using/ ), no compartida con otros procesos.
¿Cuál puede ser la causa de un uso de memoria tan alto? Por lo que puedo decir, es persistente: la memoria no se libera hasta que se cierra la conexión. Como estoy usando grupos de conexiones administrados por Wildfly, se reutilizan y es raro que se cierren y vuelvan a crear.
Aquí está mi definición de fuente de datos:
<datasource jta="true" jndi-name="java:/MainDS" pool-name="MainDCPool"> <connection-url>jdbc:postgresql://dbhost/</connection-url> <driver-class>org.postgresql.Driver</driver-class> <driver>postgres</driver> <pool> <min-pool-size>1</min-pool-size> <max-pool-size>30</max-pool-size> </pool> <security> <user-name>dbuser</user-name> <password>password</password> </security> <validation> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/> <validate-on-match>true</validate-on-match> <background-validation>false</background-validation> </validation> <statement> <share-prepared-statements>false</share-prepared-statements> </statement> <timeout> <idle-timeout-minutes>1</idle-timeout-minutes> </timeout> </datasource> Por lo que llamo, la configuración de 'idle-timeout-minutes=1' y min-pool-size=1 no tuvo mucho o ningún impacto. Parece que WildFly selecciona una conexión aleatoria del grupo (cuando lo solicita la aplicación), por lo que es poco probable que alguno de ellos permanezca inactivo durante un período prolongado y el tamaño del grupo nunca caerá por debajo de ~ 20 conexiones
Resultó que la razón era el histograma (pg_stats). Se almacena en la memoria por cada conexión, y en la base de datos con una gran cantidad de particiones provoca una sobrecarga significativa. Las columnas que contienen valores grandes/largos tienen un impacto significativo. Reducir el atributo ESTADÍSTICAS en 4 columnas de una sola tabla y sus particiones redujo el uso de memoria (por conexión) en un 35 %. La actualización en sí no tuvo la culpa, pero, como parte del procedimiento de actualización, se analizó toda la base de datos y se aplicó el nuevo valor default_statistics_target a todas las tablas.
Verificación del tamaño del histograma: Encontrar el tamaño del histograma para una tabla dada PostgreSQL