Eh visto de todo. > On 2/10/2022, at 9:07 PM, Francisco Olarte <fola...@peoplecall.com> wrote: > > On Sat, 1 Oct 2022 at 19:03, Edwin Quijada <listas_quij...@hotmail.com> 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 > >
