Re: Ayuda con tunning de base de datos/vacuum/wraparround

hola Brian.

para el vacuum hay un parametro muy importante que no han tenido en cuenta
y es*maintenance_work_mem (integer)*
http://www.postgresql.org/docs/9.3/static/runtime-config-resource.html

Specifies the maximum amount of memory to be used by maintenance
operations, such as *VACUUM*, CREATE INDEX, and ALTER TABLE ADD FOREIGN KEY.
It defaults to 16 megabytes (16MB). Since only one of these operations can
be executed at a time by a database session, and an installation normally
doesn't have many of them running concurrently, it's safe to set this value
significantly larger than work_mem. Larger settings might improve
performance for vacuuming and for restoring database dumps.

Note that when autovacuum runs, up to
autovacuum_max_workers<http://www.postgresql.org/docs/9.3/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-MAX-WORKERS>times
this memory may be allocated, so be careful not to set the default
value too high.
tambien recomiendo active el full log del autovacuum para ver el
comportamiento con
*log_autovacuum_min_duration (-1)*
http://www.postgresql.org/docs/9.3/static/runtime-config-autovacuum.html

Causes each action executed by autovacuum to be logged if it ran for at
least the specified number of milliseconds. Setting this to zero logs all
autovacuum actions. Minus-one (the default) disables logging autovacuum
actions. For example, if you set this to 250ms then all automatic vacuums
and analyzes that run 250ms or longer will be logged. In addition, when
this parameter is set to any value other than -1, a message will be logged
if an autovacuum action is skipped due to the existence of a conflicting
lock. Enabling this parameter can be helpful in tracking autovacuum
activity. This setting can only be set in the postgresql.conf file or on
the server command line.

El 20 de mayo de 2014, 15:34, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>escribió:

> Brian Colman escribió:
> > Hola Alvaro,
> > Gracias por la ayuda, antes de insertar, habian un procedimiento
> almacenado
> > que chequeaba la existencia de la particion, caso contrario la creaba,
> esto
> > hacia para cada transacción, ahora cambie esto, las particiones ya estan
> > creadas previamente y mejoro bastante los tps, y tambien mejoraron los
> > bloqueos,
>
> Ese mismo chequeo probablemente hacía que autovacuum se suicidara cada
> vez que le tocaba hacer un vacuum; y que el vacuum insuicidable de
> emergencia cuando aparecía el wraparound causara que todo el sistema se
> bloqueara.
>
> La idea de chequear particiones antes de insertar es un error bastante
> serio que muchos cometen.
>
> > ahora volvi a setear los valores del vacuum para que no duerma
> > tanto, veremos como me va.
>
> Esperaremos noticias tuyas la próxima semana, si ha habido o no futuros
> bloqueos ...
>
> --
> Álvaro Herrera http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>
> -
> Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org
> )
> Para cambiar tu suscripción:
> http://www.postgresql.org/mailpref/pgsql-es-ayuda
>

--
Raul Andres Gutierrez Alejo