Un problema que tuve con el OOMKiller fue por culpa de un drive ODBC, lanzaba desde Xcell una conexion al servidor con un query bien complicado y la verdad no se pq cuando este cquery corria me tumbaba el servidor pero si lo corria directamente en la consola no pasaba nada. Puede que sea bajo una de esta premisa, un query mal hecho, puede darte al traste con el servidor Tambien
Edwin Quijada, MA JQ Microsistemas Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 From: Francisco Olarte<mailto:fola...@peoplecall.com> Sent: Wednesday, July 27, 2022 4:03 AM To: jorge gerardo fernandez lugo<mailto:jorge...@hotmail.com> Cc: pgsql-es-ay...@postgresql.org<mailto:pgsql-es-ay...@postgresql.org> Subject: Re: Limitar memoria postgresql Jorge: On Mon, 25 Jul 2022 at 16:02, jorge gerardo fernandez lugo <jorge...@hotmail.com> wrote: >... Voy a comentarlo con la gente que administra el SO. > Ya que creo que lo que mencionas viene por ese lado, puede ser? > En postgres no encontré esos parámetros. Como no se a que parte respondes, no se que decirte aqui. Lo que yo te decia es: > Si te lo mata el OOM killer, es que tienes overcommit. Mirate tambien > de configurar bien eso, en servidores dedicados con programas como Pg > que se controla el uso de memoria suele ser mejor que Pg muera el solo > porque el SO no le da memoria que que el SO tenga que elegir alguno de > los procesos de Pg a matar. Asi por partes, muchos programas tienen tendencia a pedir al sistema grandes bloques de memoria que luego van usando segun necesitan, p.e. un programa en C puede pedir bloques de 128Mb con sbrk() para luego ir usandolo a trocitos con malloc() y resultar que solo usa 16Mb. El kernel sabe que memoria usas ( porque te ve tocar las paginas ). Para mejorar el rendimiento se invento el overcommit, que hace un "educated guess", p.e. puede darle a los programas hasta el 150% de la memoria que tiene ( RAM+SWAP ) porque no usan mas del 60% de lo que piden. Pero si se equivoca , si todos usan el 100% de lo que les dio, tenemos un problema, porque no puede decirles "me equivoque, de los 128Mb que te di y has usado 64, ya no puedes usar el resto", por lo que tienes el killer, que elige un proceso victima y lo mata para liberar memoria. El OOM killer entrando es malo, se hace para evitar algo peor, pero es malo. Cuando tu maquina tiene un solo programa, tipo Pg, que esta preparado para que el SO no le pueda dar la memoria que pide ( muchos programas en C revientan como falle una peticion de memoria, algunos ni chequean ) y que pide mucha porque usa mucha es mejor que no uses overcommit ( con lo cual el OOM killer no entrara nunca, solo entra si hay overcommit Y la prediccion fue erronea ). Ademas, con el Pg, si un programa tonto se pasa de memoria puede que el OOM te mate un postgres antes de ese ( porque son gordos, consumen mucho, y mirando desde el lado del kernel pueden parecer los mejores candidatos ). Yo ya no me dedico mucho a eso y lo tengo muy olvidado, pero tus admin seguro que te lo pueden mirar. Pero, como te decia, es como el SWAP en las BD ( antiguamente se decia swap=2*ram, pero en BD es mejor swap=0, mejor que la BD sepa que no hay RAM y use sus algoritmos basados en archivos temporales directamente que que piense que la hay y se dedique a ejecutar algoritmos de RAM sobre el SWAP ), util pero peligroso y normalmente configurado muy abajo. Francisco Olarte.
