Re: Limitar memoria postgresql

[Horacio Miranda]

Eh visto de todo.

> On 2/10/2022, at 9:07 PM, Francisco Olarte  wrote:
> 
> On Sat, 1 Oct 2022 at 19:03, Edwin Quijada  wrote:
>> 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

Dudo mucho que sea un tema del JDBC. lo importante es saber que planes de 
ejecuciones estan corriendo para saber que esta haciendo la base de datos.

Los servidores cuando tiran un OOM kill, por lo general solo lo unico pesado 
que tienes corriendo es la base, seguramente estas con parametros muy altos 
para la maquina y sesiones.

Saca los planes de ejecución de tu consulta y veras cuanta RAM esta suando. 

explain (analyze,buffers) select ….. ; 

> A ver, un servidor bien configurado no deberia ser tumbado por un
> query mal, o maliciosamente, hecho. Digo tumbado, en el que no cuento
> que se quede un tiempo infinito calculando o que aborte el query por
> execeso de consumo de algun recursos.
> 
> El problema del OOM killer, mas bien del overcommit, es que postgres
> necesita correr en un sistema operativo que no le mienta, que si le
> dice que le da un giga se lo de de verdad. Un linux con overcommit NO
> cumple esas condiciones. De todas formas aqui  el query no tumba al
> servidor, es el SO el que lo mata, que lo mismo se podria hacer
> poniendo un "kill -9 ramdon()" suelto por ahi.

Si tienes algo como esto, o algo matando sesiones vas a tener otros problemas.

> El overcommit es para cuando se tienen programas que no usan todo lo
> que piden. Pg no es de esos. Normalmente para un servidor de BD lo
> suyo es determinar que necesita y empezar sin swap ni overcommit, no
> le van a ayudar. Una vez dicho esto es obvio que un poco de swap puede
> ayudar ( a p.e. transformarte un piñazo total en un slowdown
> recuperable ( dificilmente, pero recuperable ) ) y un minimo de
> overcommit, si se sabe un webo de eso, tambien ( aunque el overcommit
> tiene el riesgo de que OTRO programa malo mate al servidor ).
> 
> Si el servidor esta correcto, las queries no deberian matarlo. Ahora,
> si el Pg corre en un SO que mata procesos con criterios creativos, un
> query puede engañar al SO para que mate al Pg que no debe.
> 
> Mandar al servidor un query que no pueda procesar por falta de espacio
> es trivial para probar esto, un producto cartesiano adecuado y
> explota, probablemente un generate_series adecuado tambien, no se
> necesitan queries complicadas. Asi a pelo, me da que un "select
> generate_series(1,2^64-1), random() order by 2" tiene que fornicar un
> rato.
> 
> FOS
> 
> 

Re: Limitar memoria postgresql

[Francisco Olarte]

On Sat, 1 Oct 2022 at 19:03, Edwin Quijada  wrote:
> 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

A ver, un servidor bien configurado no deberia ser tumbado por un
query mal, o maliciosamente, hecho. Digo tumbado, en el que no cuento
que se quede un tiempo infinito calculando o que aborte el query por
execeso de consumo de algun recursos.

El problema del OOM killer, mas bien del overcommit, es que postgres
necesita correr en un sistema operativo que no le mienta, que si le
dice que le da un giga se lo de de verdad. Un linux con overcommit NO
cumple esas condiciones. De todas formas aqui  el query no tumba al
servidor, es el SO el que lo mata, que lo mismo se podria hacer
poniendo un "kill -9 ramdon()" suelto por ahi.

El overcommit es para cuando se tienen programas que no usan todo lo
que piden. Pg no es de esos. Normalmente para un servidor de BD lo
suyo es determinar que necesita y empezar sin swap ni overcommit, no
le van a ayudar. Una vez dicho esto es obvio que un poco de swap puede
ayudar ( a p.e. transformarte un piñazo total en un slowdown
recuperable ( dificilmente, pero recuperable ) ) y un minimo de
overcommit, si se sabe un webo de eso, tambien ( aunque el overcommit
tiene el riesgo de que OTRO programa malo mate al servidor ).

Si el servidor esta correcto, las queries no deberian matarlo. Ahora,
si el Pg corre en un SO que mata procesos con criterios creativos, un
query puede engañar al SO para que mate al Pg que no debe.

Mandar al servidor un query que no pueda procesar por falta de espacio
es trivial para probar esto, un producto cartesiano adecuado y
explota, probablemente un generate_series adecuado tambien, no se
necesitan queries complicadas. Asi a pelo, me da que un "select
generate_series(1,2^64-1), random() order by 2" tiene que fornicar un
rato.

FOS

RE: Limitar memoria postgresql

[Edwin Quijada]

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
 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.

Re: Limitar memoria postgresql

[Francisco Olarte]

Jorge:

On Mon, 25 Jul 2022 at 16:02, jorge gerardo fernandez lugo
 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.

Re: Limitar memoria postgresql

[Jairo Graterón]

dle
> postgres 30625  0.0 15.5 2420808 1246456 ? Ss   jul21   0:48 postgres:
>  (37528) idle
> postgres 30674  0.0  0.0 2409780 4332 ?Ss   jul21   0:00 postgres:
>  (37626) idle
> postgres 30736  0.0  0.0 2409776 4336 ?Ss   jul18   0:00 postgres:
>  (45482) idle
> -bash-4.2$
>
>
>
> bash-4.2$ cat postgresql.conf | grep 'mem\|buff\|conn'
> # "postgres -c log_connections=on".  Some parameters can be changed at run
> time
> *max_connections = 600* # (change requires restart)
> superuser_reserved_connections = 10 # (change requires restart)
> *shared_buffers = 2GB* # min 128kB
> #temp_buffers = 8MB # min 800kB
> *work_mem = 50MB * # min 64kB
> maintenance_work_mem = 256MB # min 1MB
> #autovacuum_work_mem = -1 # min 1MB, or -1 to use maintenance_work_mem
> dynamic_shared_memory_type = posix # the default is the first option
> # use none to disable dynamic shared memory
> #bgwriter_lru_maxpages = 100 # 0-1000 max buffers written/round
> #bgwriter_lru_multiplier = 2.0 # 0-10.0 multiplier on buffers scanned/round
> #wal_buffers = -1 # min 32kB, -1 sets based on shared_buffers
> #log_connections = off
> #log_disconnections = off
> bash-4.2$
>
>
> Espero sirva para analizar,
> Aguardo comentarios.
> Saludos cordiales
>
>
> --
> *De:* Jairo Graterón 
> *Enviado:* domingo, 24 de julio de 2022 18:34
> *Para:* jorge gerardo fernandez lugo 
> *Cc:* pgsql-es-ay...@postgresql.org 
> *Asunto:* Re: Limitar memoria postgresql
>
> Hola a todos
>
> Si tienes que revisar estas variables
>
> max_connections
> work_mem
> shared_buffers
> maintenance_work_mem
>
> Si puedes compartir esa información y el total de RAM. Además podrías
> ejecutar éste comando para ver cuanto consume cada proceso de postgres.
> ps -u -U postgres
>
> Saludos.
>
>
> El dom, 24 jul 2022 a las 11:19, jorge gerardo fernandez lugo (<
> jorge...@hotmail.com>) escribió:
>
> Bunas!
>
>
>
> Quisiera saber si existe algún parámetro del postgres.conf para limitar el
> uso de la memoria que Postgresql utiliza.
>
> El servidor de base de datos que utilizamos es un Linux dedicado solo al
> motor Postgresql, pero hace unos días que, el postgres consume toda la
> memoria disponible y, el SO, a fin de que no se cuelgue, dispara el oom
> killer y mata el PG.
>
>
>
> No estoy seguro si limitar el consumo de memoria es una combinación de los
> parámetros max_connections y el work_mem.
>
>
>
> Saludos cordiales a todos,
>
> Jorge Fernandez
>
>

RE: Limitar memoria postgresql

[jorge gerardo fernandez lugo]

Hola Francisco,

Gracias por el contacto. 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.

Saludos cordiales,
Jorge Fernandez


De: Francisco Olarte 
Enviado: lunes, 25 de julio de 2022 04:21
Para: jorge gerardo fernandez lugo 
Cc: pgsql-es-ay...@postgresql.org 
Asunto: Re: Limitar memoria postgresql

Jorge:
On Sun, 24 Jul 2022 at 17:19, jorge gerardo fernandez lugo
 wrote:
> Quisiera saber si existe algún parámetro del postgres.conf para limitar el 
> uso de la memoria que Postgresql utiliza.

Hay varios, por ahi te han comentado algunos, y hay paginas enteras en
la wiki explicando tuneos, pero queria decir:

> El servidor de base de datos que utilizamos es un Linux dedicado solo al 
> motor Postgresql, pero hace unos días que, el postgres consume toda la 
> memoria disponible y, el SO, a fin de que no se cuelgue, dispara el oom 
> killer y mata el PG.

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.

Como el SWAP el overcommit suele ir bien cuando hay una mezcla grande
de cosas corriendo, una variabilidad, en servidores de un solo proceso
suele ser mejor no usarlo mucho, sobre todo porque los programas que
se corren suelen ya tener control de uso de memoria y formas de
morirse cuando el SO no se la da mejores que la del OOM killer.

Respecto a limitar, en estos casos el problema clasico suele ser la
variabilidad de tus queries, es decir tienes algunas que consumen
mucho ( lo que te obliga a poner un limite generoso por
proceso/backend ) y muchas que consumen poco ( lo que te obliga a un
max-connections elevado ), lo que hace que si quieres garantizar
desperdicies mucho y el OOM killer empieze a parecer atractivo.

Francisco Olarte.

RE: Limitar memoria postgresql

[jorge gerardo fernandez lugo]

Hola Jaime,

Gracias por el contacto.

La version de postgres es 9.6.
Por ello creo que no encontre dicho parametro.


Pero tengo otra intalacion con postgres 13 para otro sistema, y voy a 
considerar dicho parametro.
En dicha instalacion esta por defecto, osea on:
#jit_above_cost = 10# perform JIT compilation if available
#jit_inline_above_cost = 50   # inline small functions if query is
#jit_optimize_above_cost = 50   # use expensive JIT optimizations if
#jit = on # allow JIT compilation
#jit_provider = 'llvmjit'   # JIT library to use

Pero en esta instalacion no tengo problemas de memoria. Sera que igual paso a 
OFF el parametro?

Espero tus comentarios.
Saludos cordiales,
Jorge Fernandez

De: Jaime Casanova 
Enviado: lunes, 25 de julio de 2022 02:03
Para: jorge gerardo fernandez lugo 
Cc: pgsql-es-ay...@postgresql.org 
Asunto: Re: Limitar memoria postgresql

On Sun, Jul 24, 2022 at 03:19:23PM +, jorge gerardo fernandez lugo wrote:
> Bunas!
>
> Quisiera saber si existe algún parámetro del postgres.conf para limitar el 
> uso de la memoria que Postgresql utiliza.
> El servidor de base de datos que utilizamos es un Linux dedicado solo al 
> motor Postgresql, pero hace unos días que, el postgres consume toda la 
> memoria disponible y, el SO, a fin de que no se cuelgue, dispara el oom 
> killer y mata el PG.
>

Qué versión de postgres es?
si es una versión que tiene el parámetro jit en "on", pasalo a "off" y
haz un restart.

Hay un problema en la librería de LLVM que causa que consuma, en algunos
casos, grandes cantidades de memoria.

--
Jaime Casanova
Director de Servicios Profesionales
SystemGuards - Consultores de PostgreSQL

RE: Limitar memoria postgresql

[jorge gerardo fernandez lugo]

nce_work_mem = 256MB# min 1MB
#autovacuum_work_mem = -1   # min 1MB, or -1 to use maintenance_work_mem
dynamic_shared_memory_type = posix  # the default is the first option
  # use none to disable dynamic shared memory
#bgwriter_lru_maxpages = 100# 0-1000 max buffers written/round
#bgwriter_lru_multiplier = 2.0# 0-10.0 multiplier on buffers 
scanned/round
#wal_buffers = -1 # min 32kB, -1 sets based on shared_buffers
#log_connections = off
#log_disconnections = off
bash-4.2$


Espero sirva para analizar,
Aguardo comentarios.
Saludos cordiales



De: Jairo Graterón 
Enviado: domingo, 24 de julio de 2022 18:34
Para: jorge gerardo fernandez lugo 
Cc: pgsql-es-ay...@postgresql.org 
Asunto: Re: Limitar memoria postgresql

Hola a todos

Si tienes que revisar estas variables

max_connections
work_mem
shared_buffers
maintenance_work_mem

Si puedes compartir esa información y el total de RAM. Además podrías ejecutar 
éste comando para ver cuanto consume cada proceso de postgres.
ps -u -U postgres

Saludos.


El dom, 24 jul 2022 a las 11:19, jorge gerardo fernandez lugo 
(mailto:jorge...@hotmail.com>>) escribió:

Bunas!



Quisiera saber si existe algún parámetro del postgres.conf para limitar el uso 
de la memoria que Postgresql utiliza.

El servidor de base de datos que utilizamos es un Linux dedicado solo al motor 
Postgresql, pero hace unos días que, el postgres consume toda la memoria 
disponible y, el SO, a fin de que no se cuelgue, dispara el oom killer y mata 
el PG.



No estoy seguro si limitar el consumo de memoria es una combinación de los 
parámetros max_connections y el work_mem.



Saludos cordiales a todos,

Jorge Fernandez

Re: Limitar memoria postgresql

[Francisco Olarte]

Jorge:
On Sun, 24 Jul 2022 at 17:19, jorge gerardo fernandez lugo
 wrote:
> Quisiera saber si existe algún parámetro del postgres.conf para limitar el 
> uso de la memoria que Postgresql utiliza.

Hay varios, por ahi te han comentado algunos, y hay paginas enteras en
la wiki explicando tuneos, pero queria decir:

> El servidor de base de datos que utilizamos es un Linux dedicado solo al 
> motor Postgresql, pero hace unos días que, el postgres consume toda la 
> memoria disponible y, el SO, a fin de que no se cuelgue, dispara el oom 
> killer y mata el PG.

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.

Como el SWAP el overcommit suele ir bien cuando hay una mezcla grande
de cosas corriendo, una variabilidad, en servidores de un solo proceso
suele ser mejor no usarlo mucho, sobre todo porque los programas que
se corren suelen ya tener control de uso de memoria y formas de
morirse cuando el SO no se la da mejores que la del OOM killer.

Respecto a limitar, en estos casos el problema clasico suele ser la
variabilidad de tus queries, es decir tienes algunas que consumen
mucho ( lo que te obliga a poner un limite generoso por
proceso/backend ) y muchas que consumen poco ( lo que te obliga a un
max-connections elevado ), lo que hace que si quieres garantizar
desperdicies mucho y el OOM killer empieze a parecer atractivo.

Francisco Olarte.

Re: Limitar memoria postgresql

[Jaime Casanova]

On Sun, Jul 24, 2022 at 03:19:23PM +, jorge gerardo fernandez lugo wrote:
> Bunas!
> 
> Quisiera saber si existe algún parámetro del postgres.conf para limitar el 
> uso de la memoria que Postgresql utiliza.
> El servidor de base de datos que utilizamos es un Linux dedicado solo al 
> motor Postgresql, pero hace unos días que, el postgres consume toda la 
> memoria disponible y, el SO, a fin de que no se cuelgue, dispara el oom 
> killer y mata el PG.
> 

Qué versión de postgres es?
si es una versión que tiene el parámetro jit en "on", pasalo a "off" y
haz un restart.

Hay un problema en la librería de LLVM que causa que consuma, en algunos
casos, grandes cantidades de memoria.

-- 
Jaime Casanova
Director de Servicios Profesionales
SystemGuards - Consultores de PostgreSQL

Re: Limitar memoria postgresql

[Jairo Graterón]

Hola a todos

Si tienes que revisar estas variables

max_connections
work_mem
shared_buffers
maintenance_work_mem

Si puedes compartir esa información y el total de RAM. Además podrías
ejecutar éste comando para ver cuanto consume cada proceso de postgres.
ps -u -U postgres

Saludos.


El dom, 24 jul 2022 a las 11:19, jorge gerardo fernandez lugo (<
jorge...@hotmail.com>) escribió:

> Bunas!
>
>
>
> Quisiera saber si existe algún parámetro del postgres.conf para limitar el
> uso de la memoria que Postgresql utiliza.
>
> El servidor de base de datos que utilizamos es un Linux dedicado solo al
> motor Postgresql, pero hace unos días que, el postgres consume toda la
> memoria disponible y, el SO, a fin de que no se cuelgue, dispara el oom
> killer y mata el PG.
>
>
>
> No estoy seguro si limitar el consumo de memoria es una combinación de los
> parámetros max_connections y el work_mem.
>
>
>
> Saludos cordiales a todos,
>
> Jorge Fernandez
>