RE: problema de rendimiento

Estimados amigos, desde hace un tiempo aca he tenido un problema con mi base
de datos, la cual se empieza a quedar pegada poniendo lento los sistemas y
no dejando ingresar mas usuarios al sistema, esto sucede desde hace un
tiempo solamente y se soluciona haciendo un vacuum y reiniciando el servidor
de base de datos

Esta montado sobre un equipo con win2003 con 1gb de RAM disco ZATA 7200 rpm,
120 gb de capacidad y el sistema esta desarrollado con visual Basic 6.0

Cada vez que sucede esto aparece el siguiente mensaje en el visor de
aplicaciones de Windows

FATAL: could not reattach to shared memory (key=5432001, addr=01E00000):
Invalid argument

Hace u tiempo atrás averigue sobre este problema y no tiene solución, de
hecho alvaro me dijo que este problema podría venir reparado en la versión
8.3, en base a esta información me gustaría poder conocer cuales son las
tablas que tienen una mayor cantidad de transacciones para poder
configurarles el vacuum y si me pueden orientar para mejorar el rendimiento
de la configuración. Se adjunta el config de la base de datos

Desde ya muchas gracias

Cesar Erices Vergara

Ingeniero en Gestión Informática

Analista de Sistemas

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mira:

http://svr5.postgresql.org/pgsql-bugs/2006-05/msg00081.php

Al parecer puede tener algo que ver con el software antivirus, ya revisaste si tu antivirus esta revisando los archivos de datos de PostgreSQL, te lo
comento porque es normal que uno deje el antivirus revisando los directorios de datos de PostgreSQL, parece que el problema tiene algo de relación,
quiza no lo solucione pero si disminuya la incidencia. Trata de hacer que tu antivirus no revise los directorios de datos de PostgreSQL.

Saludos.

Cesar escribió:
> Estimados amigos, desde hace un tiempo aca he tenido un problema con mi
> base de datos, la cual se empieza a quedar pegada poniendo lento los
> sistemas y no dejando ingresar mas usuarios al sistema, esto sucede
> desde hace un tiempo solamente y se soluciona haciendo un vacuum y
> reiniciando el servidor de base de datos
>
>
>
> Esta montado sobre un equipo con win2003 con 1gb de RAM disco ZATA 7200
> rpm, 120 gb de capacidad y el sistema esta desarrollado con visual Basic 6.0
>
>
>
> Cada vez que sucede esto aparece el siguiente mensaje en el visor de
> aplicaciones de Windows
>
>
>
> FATAL: could not reattach to shared memory (key=5432001,
> addr=01E00000): Invalid argument
>
>
>
> Hace u tiempo atrás averigue sobre este problema y no tiene solución, de
> hecho alvaro me dijo que este problema podría venir reparado en la
> versión 8.3, en base a esta información me gustaría poder conocer cuales
> son las tablas que tienen una mayor cantidad de transacciones para poder
> configurarles el vacuum y si me pueden orientar para mejorar el
> rendimiento de la configuración. Se adjunta el config de la base de datos
>
>
>
> Desde ya muchas gracias
>
>
>
>
>
>
>
> **Cesar Erices Vergara**
>
> **Ingeniero en Gestión Informática**
>
> **Analista de Sistemas**
>
>
>
>
> ------------------------------------------------------------------------
>
> --
> TIP 10: no uses HTML en tu pregunta, seguro que quien responda no podrá leerlo

- --
L.A. Jenaro Centeno Gómez
Tecnologías de la Información
Alimentos La Concordia, S.A. de C.V.
Ext. 9280
www.aldia.com.mx
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHF3X9+nACvgizD48RAtCqAKCr+pdp8WozfatV4yZhSlIneyuVFQCeMC65
qiW4ZRfGyVa/6XBpzTMLk+Y=
=TjJ9
-----END PGP SIGNATURE-----

Gracias por el consejo pero ya lo habia hecho aunque no mensionado, pero aun
sige el problema pero muchas gracias por tu información, se agradece

-----Mensaje original-----
De: Jenaro Centeno Gomez [mailto:jcenteno(at)aldia(dot)com(dot)mx]
Enviado el: Jueves, 18 de Octubre de 2007 12:05
Para: Cesar
CC: pgsql-es-ayuda-owner(at)postgresql(dot)org; pgsql-es-ayuda(at)postgresql(dot)org
Asunto: Re: [pgsql-es-ayuda] problema de rendimiento

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mira:

http://svr5.postgresql.org/pgsql-bugs/2006-05/msg00081.php

Al parecer puede tener algo que ver con el software antivirus, ya revisaste
si tu antivirus esta revisando los archivos de datos de PostgreSQL, te lo
comento porque es normal que uno deje el antivirus revisando los directorios
de datos de PostgreSQL, parece que el problema tiene algo de relación,
quiza no lo solucione pero si disminuya la incidencia. Trata de hacer que tu
antivirus no revise los directorios de datos de PostgreSQL.

Saludos.

Cesar escribió:
> Estimados amigos, desde hace un tiempo aca he tenido un problema con mi
> base de datos, la cual se empieza a quedar pegada poniendo lento los
> sistemas y no dejando ingresar mas usuarios al sistema, esto sucede
> desde hace un tiempo solamente y se soluciona haciendo un vacuum y
> reiniciando el servidor de base de datos
>
>
>
> Esta montado sobre un equipo con win2003 con 1gb de RAM disco ZATA 7200
> rpm, 120 gb de capacidad y el sistema esta desarrollado con visual Basic
6.0
>
>
>
> Cada vez que sucede esto aparece el siguiente mensaje en el visor de
> aplicaciones de Windows
>
>
>
> FATAL: could not reattach to shared memory (key=5432001,
> addr=01E00000): Invalid argument
>
>
>
> Hace u tiempo atrás averigue sobre este problema y no tiene solución, de
> hecho alvaro me dijo que este problema podría venir reparado en la
> versión 8.3, en base a esta información me gustaría poder conocer cuales
> son las tablas que tienen una mayor cantidad de transacciones para poder
> configurarles el vacuum y si me pueden orientar para mejorar el
> rendimiento de la configuración. Se adjunta el config de la base de datos
>
>
>
> Desde ya muchas gracias
>
>
>
>
>
>
>
> **Cesar Erices Vergara**
>
> **Ingeniero en Gestión Informática**
>
> **Analista de Sistemas**
>
>
>
>
> ------------------------------------------------------------------------
>
> --
> TIP 10: no uses HTML en tu pregunta, seguro que quien responda no podrá
leerlo

- --
L.A. Jenaro Centeno Gómez
Tecnologías de la Información
Alimentos La Concordia, S.A. de C.V.
Ext. 9280
www.aldia.com.mx
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHF3X9+nACvgizD48RAtCqAKCr+pdp8WozfatV4yZhSlIneyuVFQCeMC65
qiW4ZRfGyVa/6XBpzTMLk+Y=
=TjJ9
-----END PGP SIGNATURE-----

Cesar escribió:
> Estimados amigos, desde hace un tiempo aca he tenido un problema con mi base
> de datos, la cual se empieza a quedar pegada poniendo lento los sistemas y
> no dejando ingresar mas usuarios al sistema, esto sucede desde hace un
> tiempo solamente y se soluciona haciendo un vacuum y reiniciando el servidor
> de base de datos
>
>
>
> Esta montado sobre un equipo con win2003 con 1gb de RAM disco ZATA 7200 rpm,
> 120 gb de capacidad y el sistema esta desarrollado con visual Basic 6.0
>
>
>
> Cada vez que sucede esto aparece el siguiente mensaje en el visor de
> aplicaciones de Windows
>
> FATAL: could not reattach to shared memory (key=5432001, addr=01E00000):
> Invalid argument

Si, el problemita este es un problema de Windows y no se le ha
encontrado solucion. En 8.3 se reescribio el uso de shared memory en
Win32 totalmente, de manera que ya no deberia existir (pero aun no se ha
demostrado que no exista).

Sin embargo no creo que ese problema tenga nada que ver con el
rendimiento de la BD.

Deberias hacer vacuum en forma regular (minimo una vez al dia). Con
eso, el problema de lentitud deberia desaparecer. Si no, entonces puede
ser que necesites hacerlo aun mas a menudo (o usar autovacuum).

--
Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC
Renaming ReiserFS to NinaFS is such an amazingly stupid suggestion, in so many
ways, that it ought to qualify for some kind of award. Or perhaps we should
name an award after it: the "NinaFS award" for outstanding crassness.
(edmundo, http://lwn.net/Articles/203846/)

Gracias alvaro por tu respuesta pero la base de datos tiene activado el
autovacuum y se hace manutención cada 10 dias, pero desde ahora se deberá
hacer diario gracias por tu tiempo nuevamente

-----Mensaje original-----
De: Alvaro Herrera [mailto:alvherre(at)commandprompt(dot)com]
Enviado el: Jueves, 18 de Octubre de 2007 14:15
Para: Cesar
CC: pgsql-es-ayuda(at)postgresql(dot)org
Asunto: Re: problema de rendimiento

Cesar escribió:
> Estimados amigos, desde hace un tiempo aca he tenido un problema con mi
base
> de datos, la cual se empieza a quedar pegada poniendo lento los sistemas y
> no dejando ingresar mas usuarios al sistema, esto sucede desde hace un
> tiempo solamente y se soluciona haciendo un vacuum y reiniciando el
servidor
> de base de datos
>
>
>
> Esta montado sobre un equipo con win2003 con 1gb de RAM disco ZATA 7200
rpm,
> 120 gb de capacidad y el sistema esta desarrollado con visual Basic 6.0
>
>
>
> Cada vez que sucede esto aparece el siguiente mensaje en el visor de
> aplicaciones de Windows
>
> FATAL: could not reattach to shared memory (key=5432001, addr=01E00000):
> Invalid argument

Si, el problemita este es un problema de Windows y no se le ha
encontrado solucion. En 8.3 se reescribio el uso de shared memory en
Win32 totalmente, de manera que ya no deberia existir (pero aun no se ha
demostrado que no exista).

Sin embargo no creo que ese problema tenga nada que ver con el
rendimiento de la BD.

Deberias hacer vacuum en forma regular (minimo una vez al dia). Con
eso, el problema de lentitud deberia desaparecer. Si no, entonces puede
ser que necesites hacerlo aun mas a menudo (o usar autovacuum).

--
Alvaro Herrera
http://www.amazon.com/gp/registry/5ZYLFMCVHXC
Renaming ReiserFS to NinaFS is such an amazingly stupid suggestion, in so
many
ways, that it ought to qualify for some kind of award. Or perhaps we should
name an award after it: the "NinaFS award" for outstanding crassness.
(edmundo,
http://lwn.net/Articles/203846/)

Cesar escribió:
> Gracias alvaro por tu respuesta pero la base de datos tiene activado el
> autovacuum y se hace manutención cada 10 dias, pero desde ahora se deberá
> hacer diario gracias por tu tiempo nuevamente

A que te refieres con que "se hace cada 10 dias"?

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Quoting Cesar <caerices(at)gmail(dot)com>:

> Estimados amigos, desde hace un tiempo aca he tenido un problema con mi base
> de datos, la cual se empieza a quedar pegada poniendo lento los sistemas y
> no dejando ingresar mas usuarios al sistema, esto sucede desde hace un
> tiempo solamente y se soluciona haciendo un vacuum y reiniciando el servidor
> de base de datos
>
>
>
> Esta montado sobre un equipo con win2003 con 1gb de RAM disco ZATA 7200 rpm,
> 120 gb de capacidad y el sistema esta desarrollado con visual Basic 6.0
>
>
>
> Cada vez que sucede esto aparece el siguiente mensaje en el visor de
> aplicaciones de Windows
>
>
>
> FATAL: could not reattach to shared memory (key=5432001, addr=01E00000):
> Invalid argument
>
>
>
> Hace u tiempo atrás averigue sobre este problema y no tiene solución, de
> hecho alvaro me dijo que este problema podría venir reparado en la versión
> 8.3, en base a esta información me gustaría poder conocer cuales son las
> tablas que tienen una mayor cantidad de transacciones para poder
> configurarles el vacuum y si me pueden orientar para mejorar el rendimiento
> de la configuración. Se adjunta el config de la base de datos
>
>
>
> Desde ya muchas gracias
>
>
>
>
>
>
>
> Cesar Erices Vergara
>
> Ingeniero en Gestión Informática
>
> Analista de Sistemas
>
>
>
>

tendrias que revisar el codigo visual Basic 6.0 y verificar que las
conexiones a
la base de datos se cierran correctamente y hacer un nothing de los objetos
connection. me imagino estas usando ado

Saludos
Guillermo Muñoz

Cada 10 dias realizo un vacuum desde el pgadmin, luego hago un analizy
tambien desde el pgadmin y por ultimo se rescata un backup, luego se
reinicia el servicio postgres

-----Mensaje original-----
De: Alvaro Herrera [mailto:alvherre(at)commandprompt(dot)com]
Enviado el: Jueves, 18 de Octubre de 2007 15:04
Para: Cesar
CC: pgsql-es-ayuda(at)postgresql(dot)org
Asunto: Re: problema de rendimiento

Cesar escribió:
> Gracias alvaro por tu respuesta pero la base de datos tiene activado el
> autovacuum y se hace manutención cada 10 dias, pero desde ahora se deberá
> hacer diario gracias por tu tiempo nuevamente

A que te refieres con que "se hace cada 10 dias"?

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Cesar escribió:
> Cada 10 dias realizo un vacuum desde el pgadmin, luego hago un analizy
> tambien desde el pgadmin y por ultimo se rescata un backup, luego se
> reinicia el servicio postgres

Ok, claramente es muy poco.

En todo caso no es necesario reiniciar el servicio.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Si el autovacuum está activado ¿Es necesario realizar un Vacuum cada cierto
tiempo aún? ¿No es suficiente con el Autovacuum?

atte.
Luis Guevara

On 10/18/07, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
>
> Cesar escribió:
> > Cada 10 dias realizo un vacuum desde el pgadmin, luego hago un analizy
> > tambien desde el pgadmin y por ultimo se rescata un backup, luego se
> > reinicia el servicio postgres
>
> Ok, claramente es muy poco.
>
> En todo caso no es necesario reiniciar el servicio.
>
>
>
> --
> Alvaro Herrera
> http://www.CommandPrompt.com/
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
> --
> TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?
> http://archives.postgresql.org/pgsql-es-ayuda
>

--
atte.
Luis Guevara

Luis Guevara escribió:
> Si el autovacuum está activado ¿Es necesario realizar un Vacuum cada cierto
> tiempo aún? ¿No es suficiente con el Autovacuum?

Debería ser suficiente, pero dados los problemas que tienes claramente
hace falta algo. Quizás la configuración de autovacuum no es
suficiente; o quizas el FSM es muy chico. Depende de muchas variables.

--
Alvaro Herrera Developer, http://www.PostgreSQL.org/
"La verdad no siempre es bonita, pero el hambre de ella sí"

> Cada 10 dias realizo un vacuum desde el pgadmin, luego hago un analizy
> tambien desde el pgadmin y por ultimo se rescata un backup, luego se
> reinicia el servicio postgres

¿Por último se rescata un backup? Eso significa que haces un pg_restore? Si
es así, después del pg_restore es cuando tienes que hacer los vacuum, y no
antes.

Un saludo,
David Prieto