Re: Posible fuga de memoria

Hola ya lo mensionaron un posible, OOM (Out Of memory).
Como lo puedes revisar.

dmesg -T en versiones nuevas.
dmesg (en versiones viejas).

si haces un sosreport captura todos los logs que cualquier sysadmin
necesita para revisar tu servidor completo.

Mira ese reporte por lo general te dice todo.

revisa el uso del /dev/shm ( eso es memoria y cualquier punto de mentaje
que este usando la RAM, sera menos memoria disponible para los programas ).

baja/ajusta la RAM a algo más chico ya que claramente estas usando SWAP.
Al usar SWAP usas IO.
Al usa IO de disco, operaciones de lecturas full scan son mas lentas.

Ajusta el SAR para capturar como estan tus IO cada minuto, por defecto
son cada 10 min.

Si puedes, revisa que programa te da una vista de la CPU, la RAM y la
latencia de los discos.
Si tienes iSCSI, revisa la red.
Si tienes HBA, revisa la latencia de los IOPS.

Un parametros a revisar es la concurrencia, muchos ponen concurrencia
alta con Storages no locales, esto eh encontrado es un error por que el
postgresql no optimiza los IOPS en bloques. En lo personal lo que me da
más resultado es poner los discos como si fueran discos mecanicos cuando
tengo Storages remotos o iSCSI, iSCSI tiene más latencia que un HBA de
fibra.

Pero definiticamente, revisa que esta usando la RAM y revisa cambios de
parametros a nivel de session.
A nivel de session se puede ajustar el work_mem que eh encontrado come
mucha RAM cuando se ajusta mal.

La regla es encontrar una consulta significativa y ponerle la RAM de esa
consulta si quieres que el sistema ande bien para que corra en RAM el
ordenamiento, pero si tienes problemas de RAM vas a tener que ajustarlo
y manejar ese ordenamiento a nivel de session, role o proceso.

On 5/03/2025 4:57 am, Damian Alonso wrote:
> Es muy probable este relacionado al OOM fijate si tenes bien los
> umbrales en el conf para no llegar a pasar el maximo de memoria libre
> del SO y asi el OOM no aparece para materte al motor. Igual en los
> logs del SO deberias ver el OOM killeando al motor por consumo.
>
> Revisa los parametros de memoria del .conf que esten bien seteados
>
> El mar, 4 de mar de 2025, 12:41, Marcelo Diaz
> <marcelorauldiaz(at)gmail(dot)com> escribió:
>
> Probablemente este relacionado a un OOM en la documentación
> esta bien explicado como evitarlo
> https://www.postgresql.org/docs/16/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT
> quizas aún mas amigable en este post
> https://www.cybertec-postgresql.com/en/what-you-should-know-about-linux-memory-overcommit-in-postgresql/
>
> Saludos.
>
>  Marcelo Diaz
>
>
>
>
> On Tue, Mar 4, 2025 at 3:42 PM Jairo Graterón
> <jgrateron(at)gmail(dot)com> wrote:
>
> Saludos lista, desde que actualizamos de la versión 12 a 16
> hemos observado que postgresql
> se reinicia automáticamente.
>
> PostgreSQL 16.8 (Ubuntu 16.8-0ubuntu0.24.04.1) on
> x86_64-pc-linux-gnu
>
> image.png
>
> image.png
>
> El servidor tiene 32GB de RAM y sus parámetros son:
> max_connections = 300 # el máximo observado es 150
> shared_buffers = 6144MB
> work_mem = 32MB
> maintenance_work_mem = 2GB
> max_wal_size = 1GB
> min_wal_size = 80MB
> random_page_cost = 1.0
> effective_cache_size = 12GB
>
> Cabe destacar que he bajado todos los valores con respecto a
> la instalación 12 pero aún se sigue reiniciando.
>
> ¿Alguna idea de cómo puedo abordar éste tema?
>