Re: ERROR: out of memory

<p>Buen dia Lista.</p><p>&nbsp;</p><p>Agradeceria un poco de informacion con respecto a este mensaje.</p><p>&nbsp;</p><p>Existe una consulta que se ejecutaba sobre&nbsp; PostgresSQL 7.3.7 , en una maquina DELL PowerEdge 2600 con 4 Gb de RAM, y ejecutando Gnu/Linux RedHat Enterprise 4.0 para 32 bits. y la consulta se ejecuta y la selecccion</p><p>finalizaba , usando un cursor (haciendo un join de dos tablas con aproximandamente una de 9383423 y la otra unos 3832237 ) junto con dos tablas mas de mas o menos los mismos registros (millon y medio aprox).<br /></p><p>&nbsp;</p><p>Pero ahora sobre una Servidor Dell (Intel Xeon&nbsp;2.66 Hgz) en rack (vmware) con los mismos 4Gb de RAM, el mismo sistema operativo pero ejecutando PostgreSQL 8.1.11, falla generando el mensaje de error out out memory</p><p>failed request</p><p>&nbsp;</p><p>ademas de evaluar work_mem, y los buffers , que otro parametro podria evaluar?</p><p>la consulta consumo ram pero al cabo de poco mas de 20 minutos aborta</p><p><p> </p></p><p>Gracias.</p><p>&nbsp;</p><p>&nbsp;</p><p>Juan Pablo Sandoval Rivera<br /></p><BR>

2008/10/7 <juapabsan(at)tutopia(dot)com>:
> Buen dia Lista.
>
>
>
> Agradeceria un poco de informacion con respecto a este mensaje.
>
>
>
> Existe una consulta que se ejecutaba sobre PostgresSQL 7.3.7 , en una
> maquina DELL PowerEdge 2600 con 4 Gb de RAM, y ejecutando Gnu/Linux RedHat
> Enterprise 4.0 para 32 bits. y la consulta se ejecuta y la selecccion
>
> finalizaba , usando un cursor (haciendo un join de dos tablas con
> aproximandamente una de 9383423 y la otra unos 3832237 ) junto con dos
> tablas mas de mas o menos los mismos registros (millon y medio aprox).

Ups !! creo que el problema viene por este lado .. los cursores en si
son una estructura no muy recomendable para consultas de esta
magnitud.. no puedes tratar de ir por otro camino???

>
>
>
> Pero ahora sobre una Servidor Dell (Intel Xeon 2.66 Hgz) en rack (vmware)
> con los mismos 4Gb de RAM, el mismo sistema operativo pero ejecutando
> PostgreSQL 8.1.11, falla generando el mensaje de error out out memory
>
> failed request
>
>
>
> ademas de evaluar work_mem, y los buffers , que otro parametro podria
> evaluar?
>
> la consulta consumo ram pero al cabo de poco mas de 20 minutos aborta
>
> Gracias.
>
>
>
>
>
> Juan Pablo Sandoval Rivera
>
>
Slds

J

--
Cumprimentos
jchavez
linux User #397972 on http://counter.li.org/

2008/10/7 <juapabsan(at)tutopia(dot)com>:
> Buen dia Lista.
>
>
> Existe una consulta que se ejecutaba sobre PostgresSQL 7.3.7 , en una
> maquina DELL PowerEdge 2600 con 4 Gb de RAM, y ejecutando Gnu/Linux RedHat
> Enterprise 4.0 para 32 bits. y la consulta se ejecuta y la selecccion
>
> finalizaba , usando un cursor (haciendo un join de dos tablas con
> aproximandamente una de 9383423 y la otra unos 3832237 ) junto con dos
> tablas mas de mas o menos los mismos registros (millon y medio aprox).
>

podrias mostrar lo que estas haciendo como para darnos una idea...

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157

Javier Chávez B. escribió:
> 2008/10/7 <juapabsan(at)tutopia(dot)com>:

> > finalizaba , usando un cursor (haciendo un join de dos tablas con
> > aproximandamente una de 9383423 y la otra unos 3832237 ) junto con dos
> > tablas mas de mas o menos los mismos registros (millon y medio aprox).
>
> Ups !! creo que el problema viene por este lado .. los cursores en si
> son una estructura no muy recomendable para consultas de esta
> magnitud.. no puedes tratar de ir por otro camino???

Al contrario ... si tienes que entregarle un numero muy grande de
registros al cliente, es mas recomendable usar un cursor de manera que
pueda ir leyendolos de a pocos.

Como dice Jaime, para poder ayudar más tendríamos que ver más detalles.

--
Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4
Y dijo Dios: "Que sea Satanás, para que la gente no me culpe de todo a mí."
"Y que hayan abogados, para que la gente no culpe de todo a Satanás"

On Tue, Oct 7, 2008 at 7:02 PM, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> Javier Chávez B. escribió:
>> 2008/10/7 <juapabsan(at)tutopia(dot)com>:
>
>> > finalizaba , usando un cursor (haciendo un join de dos tablas con
>> > aproximandamente una de 9383423 y la otra unos 3832237 ) junto con dos
>> > tablas mas de mas o menos los mismos registros (millon y medio aprox).
>>
>> Ups !! creo que el problema viene por este lado .. los cursores en si
>> son una estructura no muy recomendable para consultas de esta
>> magnitud.. no puedes tratar de ir por otro camino???
>
> Al contrario ... si tienes que entregarle un numero muy grande de
> registros al cliente, es mas recomendable usar un cursor de manera que
> pueda ir leyendolos de a pocos.

Que ???? eso si que no lo sabia .. :S pero en armar un cursor es una
estructura que se llena iterativamente o no??? eso en si no tiene mas
costo que tentar de hacer todo con una consulta quiza mas compleja????

> Como dice Jaime, para poder ayudar más tendríamos que ver más detalles.
>
> --
> Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4
> Y dijo Dios: "Que sea Satanás, para que la gente no me culpe de todo a mí."
> "Y que hayan abogados, para que la gente no culpe de todo a Satanás"
>

--
Cumprimentos
jchavez
linux User #397972 on http://counter.li.org/

Javier Chávez B. escribió:
> On Tue, Oct 7, 2008 at 7:02 PM, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> > Javier Chávez B. escribió:
> >> 2008/10/7 <juapabsan(at)tutopia(dot)com>:
> >
> >> > finalizaba , usando un cursor (haciendo un join de dos tablas con
> >> > aproximandamente una de 9383423 y la otra unos 3832237 ) junto con dos
> >> > tablas mas de mas o menos los mismos registros (millon y medio aprox).
> >>
> >> Ups !! creo que el problema viene por este lado .. los cursores en si
> >> son una estructura no muy recomendable para consultas de esta
> >> magnitud.. no puedes tratar de ir por otro camino???
> >
> > Al contrario ... si tienes que entregarle un numero muy grande de
> > registros al cliente, es mas recomendable usar un cursor de manera que
> > pueda ir leyendolos de a pocos.
>
> Que ???? eso si que no lo sabia .. :S pero en armar un cursor es una
> estructura que se llena iterativamente o no???

Hmmm.

Un cursor se ejecuta de la misma forma que una consulta común y
corriente. La única diferencia es que al cursor se le piden las tuplas
en conjuntos pequeños a medida que el usuario hace FETCH. En cambio a
una consulta invocada directamente se le piden todas las tuplas de una
sola vez.

La verdad es que en el lado del servidor no hay casi ninguna diferencia
(hay un par de excepciones, que son caracteristicas especiales que se le
piden a los cursores cuando especificas WITH HOLD y/o WITH SCROLL).
Pero para el cliente puede ser muy diferente, porque en el caso de la
consulta directa tiene que ser capaz de recibir todo de una sola vez, y
por lo tanto ser capaz de emplazar (alloc) mucha memoria. En cambio con
el cursor, puede emplazar una cantidad pequeña de memoria recibiendo una
cantidad pequeña de tuplas, luego liberar esa memoria y recibir más
tuplas; y así repetir hasta consumir todas las tuplas del resultado.

¿Se entiende?

> eso en si no tiene mas costo que tentar de hacer todo con una consulta
> quiza mas compleja????

Hmm, si lo que el individuo está haciendo es tomar el resultado del
cursor y luego aplicando un "join" manualmente en la aplicación,
entonces ciertamente sería mejor usar una sola consulta más compleja.
Pero no es eso lo que yo entendí del primer post.

--
Alvaro Herrera http://www.amazon.com/gp/registry/3BP7BYG9PUGI8
"Llegará una época en la que una investigación diligente y prolongada sacará
a la luz cosas que hoy están ocultas" (Séneca, siglo I)

2008/10/7 Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>:
> Javier Chávez B. escribió:
>> On Tue, Oct 7, 2008 at 7:02 PM, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>> > Javier Chávez B. escribió:
>> >> 2008/10/7 <juapabsan(at)tutopia(dot)com>:
>> >
>> >> > finalizaba , usando un cursor (haciendo un join de dos tablas con
>> >> > aproximandamente una de 9383423 y la otra unos 3832237 ) junto con dos
>> >> > tablas mas de mas o menos los mismos registros (millon y medio aprox).
>> >>
>> >> Ups !! creo que el problema viene por este lado .. los cursores en si
>> >> son una estructura no muy recomendable para consultas de esta
>> >> magnitud.. no puedes tratar de ir por otro camino???
>> >
>> > Al contrario ... si tienes que entregarle un numero muy grande de
>> > registros al cliente, es mas recomendable usar un cursor de manera que
>> > pueda ir leyendolos de a pocos.
>>
>> Que ???? eso si que no lo sabia .. :S pero en armar un cursor es una
>> estructura que se llena iterativamente o no???
>
> Hmmm.
>
> Un cursor se ejecuta de la misma forma que una consulta común y
> corriente. La única diferencia es que al cursor se le piden las tuplas
> en conjuntos pequeños a medida que el usuario hace FETCH. En cambio a
> una consulta invocada directamente se le piden todas las tuplas de una
> sola vez.
>
> La verdad es que en el lado del servidor no hay casi ninguna diferencia
> (hay un par de excepciones, que son caracteristicas especiales que se le
> piden a los cursores cuando especificas WITH HOLD y/o WITH SCROLL).
> Pero para el cliente puede ser muy diferente, porque en el caso de la
> consulta directa tiene que ser capaz de recibir todo de una sola vez, y
> por lo tanto ser capaz de emplazar (alloc) mucha memoria. En cambio con
> el cursor, puede emplazar una cantidad pequeña de memoria recibiendo una
> cantidad pequeña de tuplas, luego liberar esa memoria y recibir más
> tuplas; y así repetir hasta consumir todas las tuplas del resultado.
>
> ¿Se entiende?

Yes .. Clarisimo!!! Obrigado :0)

>
>> eso en si no tiene mas costo que tentar de hacer todo con una consulta
>> quiza mas compleja????
>
> Hmm, si lo que el individuo está haciendo es tomar el resultado del
> cursor y luego aplicando un "join" manualmente en la aplicación,
> entonces ciertamente sería mejor usar una sola consulta más compleja.
> Pero no es eso lo que yo entendí del primer post.

Mmm puede ser .. personalmente siempre dejo de lado los cursores, voy
a testear en algunas cosas..
Sld.s

> --
> Alvaro Herrera http://www.amazon.com/gp/registry/3BP7BYG9PUGI8
> "Llegará una época en la que una investigación diligente y prolongada sacará
> a la luz cosas que hoy están ocultas" (Séneca, siglo I)
>

--
Cumprimentos
jchavez
linux User #397972 on http://counter.li.org/