Re: Posible fuga de memoria

Ahh, revisa los tipos de discos que tienes.
los discos si son menos de 2T del tipo gp2 tienen limites de IOPS y no son para bases de datos.

los tipo GP3 son mejores y no tienen el mismo limite.

si realmente necesitas mayor IOPS puedes usar unos mas caros, 3 veces mas caros los io2 o io1.

Ahora si te llegas a meter con discos ephymeros que son mucho mas rapidos y baratos debes saber que si apagas y prender la instancia los datos se borran, esto esta diseñado para bases de lectura intensa replicadas, mongoDB con varios nodos donde seleccionas la opción de no tener los nodos en el mismo RACK ( hay veces que los RACK se apagaban por una falla que no puedo decir ), y si sospechas, sí, era soporte Linux de AWS por un tiempo hasta que tuve que viajar a Chile por un tema familiar.

En palabras simples, revisa la consola, las metricas de los discos, si todo te dice que esta bien puede que tengas algo llamado micro burst. lee esto.

https://repost.aws/knowledge-center/ebs-identify-micro-bursting
Identify micro-bursting on EBS volumes
repost.aws

https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html

> On 5 Mar 2025, at 1:38 PM, Jairo Graterón <jgrateron(at)gmail(dot)com> wrote:
>
> 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 <mailto: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 <mailto: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 <mailto: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 <mailto: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?
>>