Es una instancia EC2 de aws. probaré sar.
Gracias. El mar, 4 mar 2025 a las 19:34, Horacio Miranda (<hmira...@gmail.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 <jgrate...@gmail.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 (<marcelorauld...@gmail.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 <jgrate...@gmail.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? >>> >> >
