Re: Posible fuga de memoria

Es una instancia EC2 de aws.

probaré sar.

Gracias.

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

> Si tienes instalado sar, usar sar -w
> esto te da la información del swap. para ver otros dias. /var/log/sa/ hay
> archivos.
> sar -w -f FILE
>
> ahora si no tienes un sistema de monitoreo creo que datadog soporta un
> numero de maquinas gratis, junto con new relic, eh usado ambas en el pasado
> y cada una tiene gracias independientes. newrelic es mas para aplicaciones
> java ( en mi caso ) y datadog es buena para S.O. y temas de
> infraestructura, puede que esta ultima te convenga mirar por que swap y
> renicios es mas en linea con infraestructura.
>
> Ahora lo otro es que si la RAM tiene problemas, los logs se van a perder,
> tal ves te convenga replicar los logs del syslog a una maquina secundaria
> para capturar estos eventos. Es maquina real o virtual ?
>
> On 5 Mar 2025, at 10:31 AM, Jairo Graterón <jgrateron(at)gmail(dot)com> wrote:
>
> Interesante lo que mencionas, muestro a continuación los valores
> de /proc/meminfo
>
> CommitLimit: 20437112 kB
> Committed_AS: 7853352 kB
>
> Y esos valores se mantienen todo el día, otro punto es que esos reinicios
> no son frecuentes, a veces 4, 7 días entre ellos.
>
> total used free shared buff/cache
> available
> Mem: 30Gi 7.7Gi 623Mi 6.1Gi 29Gi
> 23Gi
> Swap: 4.0Gi 74Mi 3.9Gi
>
> La swap básicamente no se utiliza, y ese reinicio no ocurre en la hora
> pico cuando están todos los usuarios conectados, más o menos a la 1am
> cuando se ejecutan algunos procesos en lote.
>
> Modifiqué el valor vm.overcommit_memory = 2 en un servidor de prueba y el
> sistema se volvió inestable.
>
> Y no encuentro en el dmesg o el journal un OMMKilled.
>
> tmpfs 16G 2.3M 16G 1% /dev/shm
> La memoria compartida shm está bastante bien y en la hora pico.
>
> Seguiré revisando. Gracias.
>
> El mar, 4 mar 2025 a las 11: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?
>>>
>>
>