Re: Posible fuga de memoria

Sospecho que también puede ser que las actualizaciones automáticas haga que
se reinicie el servidor postgresql, voy a desactivarlo temporalmente.

[image: image.png]

El mar, 4 mar 2025 a las 16:51, Horacio Miranda (<hmiranda(at)gmail(dot)com>)
escribió:

> 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: image.png]
>>>
>>> [image: 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?
>>>
>>>