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

Gracias Raul, Alvaro, hasta el momento esta funcionando bastante bien
inclusive mejoro la tasa de tps despues de quitar la comprobación de la
partición, voy a probar ajustar tambien el nuevo parametro que me pasaron,
les comento como me va.

Saludos!

2014-05-20 19:43 GMT-04:00 raul andrez gutierrez alejo <raulandrez(at)gmail(dot)com
>:

> 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.conffile 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
>

--
Brian Colman Miers
brian(at)bricosolutions(dot)com