RE: Inserccion muy lenta a una base de datos

> -----Mensaje original-----
> De: motum hesa
>
> Hola disculpa la tardanza.. por error mande la respuesta a
> borrador en vez de enviarla por correo y hasta ahorita me di cuenta
>
> >>
> >
> > El primer paso es determinar dónde está el cuello de
> botella: ¿CPU o discos?
> > Monitorea tu sistema y confirma qué valores se disparan al
> momento que
> > notas las transacciones muy lentas.
> >
> > De todas maneras, los síntomas descriptos sugieren problemas de
> > concurrencia con checkpoints.
> > Comentanos qué versión de Postgres estás utilizando, como está
> > configurado (shared_buffers, checkpoints, synchronous_commit) y la
> > naturaleza de tu hardware, en especial el I/O, y el sistema
> operativo.
> >
>
> Postgres 8.2.9 ( con postgis 1.3.2 ) .- Tengo un sistema en
> JAVA que usa esas mismas librerias, espero actualizar este año.
> En cuanto a la configuración es la siguiente:
>
> shared_buffers = 24MB
> Sobre Checkpoitns no tengo ninguna configuración por
> desgracia desconosco del tema pero ya comence a investigar..
> te agradeceria si tienes info sobre esto. Por lo tanto no
> tengo activado el WAL ( o mas bien todo lo referente a eso
> esta comentado)

Eso quiere decir que estas usando los valores default. Dado que tienes
apenas 24 MB de shared_buffers esos defaults son aceptables para la
actividad que describes y sería extraño esté allí el problema.

¿Verificaste si no tienes problemas de lockeos en la base? Posiblemente esos
triggers que mencionaste logran de alguna manera molestarse entre si.
Otro factor que podría estar incidiendo es el pool de conexiones de jdbc,
que justo en los momentos de pico de carga insuma tiempo en abrir
conexiones, aunque 1 min de delay me parece altamente exagerado, incrementar
el min_connections en el pool a 20 no hará daño.

>
> En cuanto al Hardware tengo:
> AMD de 2 nucleos a 2GHZ
> 3 GB de memoria ram
> 1 disco SATA de 160GB a 7200rpm
>

Ese único disco es el talón de aquiles del sistema, aunque sea suficiente
para la carga que prevees, mínimamente pondría 2 en RAID 1.

> SO: SLACKWARE 11
> GLASSFISH 2 ( como servidor de paginas web)
>
> Comento que este servidor es de pruebas por que ahorita solo
> atiende a 20 dispositivos la idea original era que soportara
> 100 y de ahi a mejorar el hardware.
>
> >
> > Te recomiendo vayas leyendo la guía de Greg Smith:
> > http://www.westnet.com/~gsmith/content/postgresql/chkp-bgw-83.htm
> >
>
> He leido el documento y me parece muy interesante y aunque
> trae cosas para la version 8.2 casi todo es para la version
> 8.3 aqui tengo un dilema entre buscar mas para la version que
> tengo o intentar actualizar ( esperando no colapse mi sistema
> por las librerias que uso en JAVA )
>

Pues esas cosas que la guía menciona para 8.2 son clave para diagnosticar
problemas en los checkpoints. Pero insisto que no creo ese sea el caso con
un shared_buffers tan chico.

Yo también administro una aplicación sobre glassfish (hibernate/jdbc). He
podido actualizar de la versión de Postgres a la 8.2 a la 8.3 y ahora a la
8.4 sin problemas. Lo único que tuve el cuidado de actualizar el driver jdbc
con cada cambio mayor de versión.
Si tu sistema está aún en fase de pruebas tienes una gran oportunidad de
actualizar el motor ahora antes de entrar en producción.

Como herramienta de diagnóstico te sugiero corras un vmstat 1 y te fijes qué
valores se disparan cuando los inserts empiezan a sufrir demoras. Si todos
los valores están estables es probable tengas lockeos en la base.

Saludos,
Fernando.