Re: Tunning postgres 8.2.5 con parametros ya definidos

Patricio Cifuentes Ithal escribió:
> > -----Mensaje original-----
> > De: pgsql-es-ayuda-owner(at)postgresql(dot)org [mailto:pgsql-es-ayuda-
> > owner(at)postgresql(dot)org] En nombre de Alvaro Herrera
> > Enviado el: Miércoles, 17 de Octubre de 2007 18:36
> > Para: Patricio Cifuentes Ithal
> > CC: pgsql-es-ayuda(at)postgresql(dot)org
> > Asunto: Re: [pgsql-es-ayuda] Tunning postgres 8.2.5 con parametros ya
> > definidos
> >
> > Patricio Cifuentes Ithal escribió:
> >
> > > max_prepare_transactions = 5
> >
> > Si no usas "prepared transactions", puedes ponerlo en 0.
> [Patricio Cifuentes Ithal]
> Estoy ocupando starttrans y completetrans del adodb for php en mi
> desarrollo, igualmente deviera ponerlo en 0?

Me da la impresion de que esas dos funciones son para usar transacciones
normales, no transacciones preparadas. Las transacciones preparadas son
para hacer commit en dos fases. Por lo que dices, no creo que lo estes
usando.

> > > vacumm_cost_delay=0
> >
> > No creo que te convenga tener un delay=0. Yo lo pondria en 10 solo
> > para
> > empezar, quizas despues subirlo.
> [Patricio Cifuentes Ithal]
> Esto es para el delay de inicio del vacuum? Ya que no lo entendí bien.

Es para que vacuum duerma un rato (en milisegundos) cada cierto tiempo.
De esa manera impides que consuma toda la potencia de I/O de la maquina.
Eso ayuda a que el rendimiento no decrezca cuando estas ejecutando
vacuum.

> > > seq_page_cost = 5.0
> > > random_page_cost = 4.0
> > > cpu_tuple_cost = 0.5
> > > cpu_index_tuple_cost = 0.5
> > > cpu_operator_cost = 0.5
> >
> > Estas parecen modificaciones aleatorias sin mucho sentido ...
> [Patricio Cifuentes Ithal]
> Quisiera entender bien para qué sirven estos parámetros, la doc en ingles
> repoco me facilita las cosas, alguna idea en español de como configurar esos
> parámetros, yo creo q se deben modificar según el uso de la BD q se le va a
> dar. O es algo a lo cual puede servir para cualquier cosa?. Par ami efecto
> son varios select ya q las tablas q se consultan son tablas geográficas de a
> lo menos 1 millon de registros. Ya q se muestran vrios ríos y caminos, en
> donde cada línea de rio ocamino representa un registro en la BD con postgis.

IMHO vuelvelas a los valores por omision.

> > > effective_cache_size = 128MB
> >
> > Esto esta totalmente malo; deberia ser shared_buffers+memoria que el
> > OS usa para cache.
> [Patricio Cifuentes Ithal]
> El share_buffer esta en 1,6 GB por lo tanto debiera ser eso mas la memoria
> del cache del S.O. q aun no la he visto (aunq no lo crean)

Si tienes 4 GB, y el servidor es dedicado para Postgres, entonces
probablemente effective_cache_size = 3 GB mas o menos.

> > > stats_reset_on_server_start = on
> >
> > Huhh ... para que??
> [Patricio Cifuentes Ithal]
> Ese parámetro no es parte de las estadísticas del vacuum?, no debiera
> resetearce cada vez q el server se reinicie?, ahora si mi idea no es
> factible o es una cabeza de pescado pido las disculpas correspondientes.

En realidad este parametro no sirve para nada (fue eliminado en 8.3).
Es mala idea reiniciar las estadísticas en cada restart; autovacuum
pierde informacion.

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