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 <[email protected]>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 ([email protected] > ) > Para cambiar tu suscripción: > http://www.postgresql.org/mailpref/pgsql-es-ayuda > -- Raul Andres Gutierrez Alejo
