Re: [pgsql-es-ayuda] autovacuum excesivo PostgreSQL 9.5

2017-01-10 Por tema Hellmuth Vargas 
Hola Alvaro

Muchas gracias por la respuesta...  Finalmente,  todas las réplicas que
tenía configurados slot y hot_standby_feedback en ON hacían que sus
correspondientes máster quedarán haciendo autovacuum "permanentementes" por
lo tanto se estableció hot_standby_feedback en OFF y se soluciono el tema.


El 9 ene. 2017 9:53 AM, "Alvaro Herrera" 
escribió:

Hellmuth Vargas escribió:
> Hola Alvaro
>
> Hice lo que sumrece me indico:
>
> - Borre el replication Slot
> - Comentarie # primary_slot_name = 'replica_local_slot' del archivo
> recovery.conf en la replica y reinicie la misma para  que tomara el cambio
> - Realice un vacuum sobre la tabla marcador
>
> INFO:  vacuuming "sac.marcador"
> INFO:  "marcador": found 1074892 removable, 1505259 nonremovable row
> versions in 105572 pages
> DETAIL:  35 dead row versions cannot be removed yet.
> CPU 0.65s/5.76u sec elapsed 9.17 sec.
> INFO:  analyzing "sac.marcador"
> INFO:  "marcador": scanned 59833 of 59833 pages, containing 1505224 live
> rows and 53 dead rows; 12 rows in sample, 1505224 estimated total rows
> Query returned successfully with no result in 17.4 secs.
>
> Y santo remedio!!!
>
> pero me queda las siguientes dudas?
>
> - Puedo volver a disponer un replication slot para esta replica?
> - O  debo colocar hot_standby_feedback  en OFF en la replica?

Hola, no había visto este correo.  Me parece que si tienes
hot_standby_feedback no necesitas el replication slot, y tienes un slot,
no necesitas hot_standby_feedback.  Con uno solo de los dos mecanismos
es suficiente.  Ambos hacen lo mismo: impedir que el master recicle
(borre) WAL que la réplica todavía necesita.  El standby feedback sólo
funciona cuando la réplica está conectada, en cambio el slot funciona
siempre, incluso si borras la réplica (y entonces tienes que asegurarte
de borrar el slot cuando la réplica deja de usarlo).  El problema del
feedback es que si la réplica se desconecta por un tiempo largo, el
maestro podría borrar el WAL, creo.

El hot_standby_feedback es código más antiguo, en cambio los slots
recién se inventaron en Postgres 9.4 ó 9.5.  Yo usaría un slot, que es
más seguro, pero agregaría en el monitoreo del sistema un seguimiento de
qué tan atrasados están los slots.  Así, cuando en el futuro una réplica
tenga problemas ya sabrán que hay que borrar un slot, antes de que se
convierta en un problema serio.

Saludos

--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: [pgsql-es-ayuda] autovacuum excesivo PostgreSQL 9.5

2017-01-09 Por tema Alvaro Herrera 
Hellmuth Vargas escribió:
> Hola Alvaro
> 
> Hice lo que sumrece me indico:
> 
> - Borre el replication Slot
> - Comentarie # primary_slot_name = 'replica_local_slot' del archivo
> recovery.conf en la replica y reinicie la misma para  que tomara el cambio
> - Realice un vacuum sobre la tabla marcador
> 
> INFO:  vacuuming "sac.marcador"
> INFO:  "marcador": found 1074892 removable, 1505259 nonremovable row
> versions in 105572 pages
> DETAIL:  35 dead row versions cannot be removed yet.
> CPU 0.65s/5.76u sec elapsed 9.17 sec.
> INFO:  analyzing "sac.marcador"
> INFO:  "marcador": scanned 59833 of 59833 pages, containing 1505224 live
> rows and 53 dead rows; 12 rows in sample, 1505224 estimated total rows
> Query returned successfully with no result in 17.4 secs.
> 
> Y santo remedio!!!
> 
> pero me queda las siguientes dudas?
> 
> - Puedo volver a disponer un replication slot para esta replica?
> - O  debo colocar hot_standby_feedback  en OFF en la replica?

Hola, no había visto este correo.  Me parece que si tienes
hot_standby_feedback no necesitas el replication slot, y tienes un slot,
no necesitas hot_standby_feedback.  Con uno solo de los dos mecanismos
es suficiente.  Ambos hacen lo mismo: impedir que el master recicle
(borre) WAL que la réplica todavía necesita.  El standby feedback sólo
funciona cuando la réplica está conectada, en cambio el slot funciona
siempre, incluso si borras la réplica (y entonces tienes que asegurarte
de borrar el slot cuando la réplica deja de usarlo).  El problema del
feedback es que si la réplica se desconecta por un tiempo largo, el
maestro podría borrar el WAL, creo.

El hot_standby_feedback es código más antiguo, en cambio los slots
recién se inventaron en Postgres 9.4 ó 9.5.  Yo usaría un slot, que es
más seguro, pero agregaría en el monitoreo del sistema un seguimiento de
qué tan atrasados están los slots.  Así, cuando en el futuro una réplica
tenga problemas ya sabrán que hay que borrar un slot, antes de que se
convierta en un problema serio.

Saludos

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

Re: [pgsql-es-ayuda] autovacuum excesivo PostgreSQL 9.5

2016-10-04 Por tema Hellmuth Vargas 
Hola Alvaro

Hice lo que sumrece me indico:

- Borre el replication Slot
- Comentarie # primary_slot_name = 'replica_local_slot' del archivo
recovery.conf en la replica y reinicie la misma para  que tomara el cambio
- Realice un vacuum sobre la tabla marcador

INFO:  vacuuming "sac.marcador"
INFO:  "marcador": found 1074892 removable, 1505259 nonremovable row
versions in 105572 pages
DETAIL:  35 dead row versions cannot be removed yet.
CPU 0.65s/5.76u sec elapsed 9.17 sec.
INFO:  analyzing "sac.marcador"
INFO:  "marcador": scanned 59833 of 59833 pages, containing 1505224 live
rows and 53 dead rows; 12 rows in sample, 1505224 estimated total rows
Query returned successfully with no result in 17.4 secs.

Y santo remedio!!!

pero me queda las siguientes dudas?

- Puedo volver a disponer un replication slot para esta replica?
- O  debo colocar hot_standby_feedback  en OFF en la replica?

Muchas gracias Alvaro por todo su tiempo ! :-)




El 4 de octubre de 2016, 08:50, Alvaro Herrera
escribió:

> Hellmuth Vargas escribió:
> > Hola Alvaro
> >
> > No se si se me cruzaron las terminales!! reenvio todas las consultas y/o
> > pantallas para verificar y si el es caso mil disculpas:
>
> OK.  Así tiene que haber sido ... los datos que das ahora son
> diferentes.  Lo importante considerar es acá:
>
> > [postgres@MDB ~]# pg_controldata -D /PostgreSQL/9.5/data
>
> > Latest checkpoint's NextXID:  0/8406787
>
> > bd=# select * from pg_replication_slots;
> >
> > -[ RECORD 2 ]+-
> > slot_name| replica_local_slot
> > plugin   |
> > slot_type| physical
> > datoid   |
> > database |
> > active   | t
> > active_pid   | 2054
> > xmin | 5463120
> > catalog_xmin |
> > restart_lsn  | 9/3670A150
>
> En este slot el xmin es 5 millones, que es muy anterior a los 8 millones
> que es el valor actual del contador de transacciones.  Es importante
> hacer que ese slot se mueva; si la aplicación que lo usaba se murió,
> entonces hay que eliminarlo.  Puedes fijarte qué lo está usando buscando
> un proceso con PID 2054, y ver si está conectado y a quién.  Si no tiene
> uso, dale un
>   select * from pg_drop_replication_slot('replica_local_slot')
>
> y luego vuelve a probar vacuum.
>
> --
> Álvaro Herrerahttps://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] autovacuum excesivo PostgreSQL 9.5

2016-10-04 Por tema Alvaro Herrera 
Hellmuth Vargas escribió:
> Hola Alvaro
> 
> No se si se me cruzaron las terminales!! reenvio todas las consultas y/o
> pantallas para verificar y si el es caso mil disculpas:

OK.  Así tiene que haber sido ... los datos que das ahora son
diferentes.  Lo importante considerar es acá:

> [postgres@MDB ~]# pg_controldata -D /PostgreSQL/9.5/data

> Latest checkpoint's NextXID:  0/8406787
 
> bd=# select * from pg_replication_slots;
> 
> -[ RECORD 2 ]+-
> slot_name| replica_local_slot
> plugin   |
> slot_type| physical
> datoid   |
> database |
> active   | t
> active_pid   | 2054
> xmin | 5463120
> catalog_xmin |
> restart_lsn  | 9/3670A150

En este slot el xmin es 5 millones, que es muy anterior a los 8 millones
que es el valor actual del contador de transacciones.  Es importante
hacer que ese slot se mueva; si la aplicación que lo usaba se murió,
entonces hay que eliminarlo.  Puedes fijarte qué lo está usando buscando
un proceso con PID 2054, y ver si está conectado y a quién.  Si no tiene
uso, dale un
  select * from pg_drop_replication_slot('replica_local_slot')

y luego vuelve a probar vacuum.

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

Re: [pgsql-es-ayuda] autovacuum excesivo PostgreSQL 9.5

2016-10-04 Por tema Hellmuth Vargas 
Hola Alvaro

No se si se me cruzaron las terminales!! reenvio todas las consultas y/o
pantallas para verificar y si el es caso mil disculpas:

El servidor, por mantenimiento de la virtualizacion, se le realizo un
reinicio anoche (hacia las 9 pm), pero apenas inicio nuevamente las tablas
en mención iniciaron autovacuum a pesar de estar en horas no laborales...

control data:

[postgres@MDB ~]# pg_controldata -D /PostgreSQL/9.5/data
pg_control version number:942
Catalog version number:   201510051
Database system identifier:   6315449280875279671
Database cluster state:   in production
pg_control last modified: Tue 04 Oct 2016 07:58:16 AM COT
Latest checkpoint location:   9/35E20BE8
Prior checkpoint location:9/3460DF20
Latest checkpoint's REDO location:9/35D87A50
Latest checkpoint's REDO WAL file:000100090035
Latest checkpoint's TimeLineID:   1
Latest checkpoint's PrevTimeLineID:   1
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID:  0/8406787
Latest checkpoint's NextOID:  184033
Latest checkpoint's NextMultiXactId:  12442
Latest checkpoint's NextMultiOffset:  25635
Latest checkpoint's oldestXID:1741
Latest checkpoint's oldestXID's DB:   13236
Latest checkpoint's oldestActiveXID:  8406787
Latest checkpoint's oldestMultiXid:   1
Latest checkpoint's oldestMulti's DB: 13236
Latest checkpoint's oldestCommitTsXid:0
Latest checkpoint's newestCommitTsXid:0
Time of latest checkpoint:Tue 04 Oct 2016 07:58:02 AM COT
Fake LSN counter for unlogged rels:   0/1
Minimum recovery ending location: 0/0
Min recovery ending loc's timeline:   0
Backup start location:0/0
Backup end location:  0/0
End-of-backup record required:no
wal_level setting:hot_standby
wal_log_hints setting:off
max_connections setting:  230
max_worker_processes setting: 8
max_prepared_xacts setting:   0
max_locks_per_xact setting:   64
track_commit_timestamp setting:   off
Maximum data alignment:   8
Database block size:  8192
Blocks per segment of large relation: 131072
WAL block size:   8192
Bytes per WAL segment:16777216
Maximum length of identifiers:64
Maximum columns in an index:  32
Maximum size of a TOAST chunk:1996
Size of a large-object chunk: 2048
Date/time type storage:   64-bit integers
Float4 argument passing:  by value
Float8 argument passing:  by value
Data page checksum version:   1


bd=# select * from  pg_stat_user_tables where relname in ('marcador',
'usuario');
-[ RECORD 1 ]---+--
relid   | 44940
schemaname  | sac
relname | usuario
seq_scan| 119
seq_tup_read| 404413
idx_scan| 97053
idx_tup_fetch   | 83670
n_tup_ins   | 0
n_tup_upd   | 529
n_tup_del   | 0
n_tup_hot_upd   | 493
n_live_tup  | 296
n_dead_tup  | 53806
n_mod_since_analyze | 523
last_vacuum | 2016-10-04 00:12:05.059494-05
last_autovacuum | 2016-10-04 08:03:00.81192-05
last_analyze| 2016-10-04 00:12:25.596793-05
last_autoanalyze|
vacuum_count| 1
autovacuum_count| 376
analyze_count   | 2
autoanalyze_count   | 0
-[ RECORD 2 ]---+--
relid   | 44165
schemaname  | sac
relname | marcador
seq_scan| 12
seq_tup_read| 21272907
idx_scan| 15787
idx_tup_fetch   | 48832353
n_tup_ins   | 6504
n_tup_upd   | 6237
n_tup_del   | 0
n_tup_hot_upd   | 4866
n_live_tup  | 1497958
n_dead_tup  | 1099897
n_mod_since_analyze | 12741
last_vacuum | 2016-10-04 00:12:03.261379-05
last_autovacuum | 2016-10-04 07:58:16.192087-05
last_analyze| 2016-10-04 00:12:49.75513-05
last_autoanalyze|
vacuum_count| 1
autovacuum_count| 73
analyze_count   | 2
autoanalyze_count   | 0


--configuracion autovacuum

autovacuum;on
autovacuum_analyze_scale_factor;0.05
autovacuum_analyze_threshold;40
autovacuum_freeze_max_age;2
autovacuum_max_workers;5
autovacuum_multixact_freeze_max_age;4
autovacuum_naptime;1min
autovacuum_vacuum_cost_delay;10ms
autovacuum_vacuum_cost_limit;-1
autovacuum_vacuum_scale_factor;0.2
autovacuum_vacuum_threshold;90


VACUUM FULL analyze verbose sac.marcador;

INFO:  vacuuming "bd.sac.marcador"
INFO:  "marcador": found 0 removable, 2580480 nonremovable row versions in
104585 pages
DETAIL:  1082081 dead row versions cannot be removed yet.
CPU 0.95s/10.97u sec elapsed 26.32 sec.
INFO:  analyzing "sac.marcador"
INFO:  "marcador": scanned 104611 of 104611 pages, containing 1498399 live
rows and 1082098 dead rows; 12 rows

Re: [pgsql-es-ayuda] autovacuum excesivo PostgreSQL 9.5

2016-10-03 Por tema Alvaro Herrera 
Hellmuth Vargas escribió:

> > Ahh, ¿no tendrás un standby con "feedback" activado que tiene una
> > transacción preparada, o un slot inactivo?  Pega acá
> > select * from pg_stat_replication
> 
> 
> bd=# select * from pg_stat_replication
> bd-# ;
> -[ RECORD 1 ]+--
> pid  | 1892
> usesysid | 10
> usename  | postgres
> application_name | walreceiver
> client_addr  | 192.168.72.XX
> client_hostname  |
> client_port  | 46648
> backend_start| 2016-10-02 11:46:57.003511-05
> backend_xmin |
> state| streaming
> sent_location| 9/11E181C0
> write_location   | 9/11E181C0
> flush_location   | 9/11E181C0
> replay_location  | 9/11E18090
> sync_priority| 0
> sync_state   | async
> -[ RECORD 2 ]+--
> pid  | 2043
> usesysid | 10
> usename  | postgres
> application_name | walreceiver
> client_addr  | 10.72.73.YY
> client_hostname  |
> client_port  | 55716
> backend_start| 2016-10-02 11:48:07.38359-05
> backend_xmin |
> state| streaming
> sent_location| 9/11E181C0
> write_location   | 9/11E181C0
> flush_location   | 9/11E181C0
> replay_location  | 9/11E18090
> sync_priority| 0
> sync_state   | async

???

Según controldata que pasaste antes,
  Latest checkpoint's REDO location:1896/AB72AB00
No tiene ningún sentido que sent_location acá sea 9/11E181C0. ¿Estamos
hablando del mismo servidor?

> > select * from pg_replication_slots
> >
> > bd=# select * from pg_replication_slots;
> -[ RECORD 1 ]+-
> slot_name| replica_calleXX_slot
> plugin   |
> slot_type| physical
> datoid   |
> database |
> active   | t
> active_pid   | 1892
> xmin | 8355084
> catalog_xmin |
> restart_lsn  | 9/11FA3D18
> -[ RECORD 2 ]+-
> slot_name| replica_local_slot
> plugin   |
> slot_type| physical
> datoid   |
> database |
> active   | t
> active_pid   | 2043
> xmin | 5463120
> catalog_xmin |
> restart_lsn  | 9/11FA3D18

Ídem; además, el xmin es 8 millones que no está ni cerca del
Latest checkpoint's NextXID:  0/2021183943
(dos mil millones) que mostraste en controldata.

Wtf?

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

Re: [pgsql-es-ayuda] autovacuum excesivo PostgreSQL 9.5

2016-10-03 Por tema Hellmuth Vargas 
Hola Alvaro

El 3 de octubre de 2016, 16:39, Alvaro Herrera
escribió:

> Hellmuth Vargas escribió:
> > El 3 de octubre de 2016, 16:17, Alvaro Herrera
> > escribió:
> >
> > > Hellmuth Vargas escribió:
> > > > Hola Alvaro
> > > >
> > > > Muchas gracias por el tiempo.. respondo entre lineas:
> > >
> > > Pero no respondiste esta parte:
> > >
> > >¿no tendrás alguna transacción preparada abierta?  Mira en
> > >pg_stat_activity y pg_prepared_xacts.
> > >
> > >
> > Perdon Alvaro
>
> Hmm, no hay ninguna "idle in transaction" ni nada que esté ejecutándose
> desde hace más que un rato.  Y no hay ninguna transacción preparada ...
> ¿qué otra cosa puede impedir que vacuum elimine filas?  Supongo que algo
> se me está escapando pero no sé qué.  Por un momento pensé que podría
> haber sido un "backup" abierto, pero eso no debería causar este problema
> que yo recuerde ...
>
> Ahh, ¿no tendrás un standby con "feedback" activado que tiene una
> transacción preparada, o un slot inactivo?  Pega acá
> select * from pg_stat_replication
>


bd=# select * from pg_stat_replication
bd-# ;
-[ RECORD 1 ]+--
pid  | 1892
usesysid | 10
usename  | postgres
application_name | walreceiver
client_addr  | 192.168.72.XX
client_hostname  |
client_port  | 46648
backend_start| 2016-10-02 11:46:57.003511-05
backend_xmin |
state| streaming
sent_location| 9/11E181C0
write_location   | 9/11E181C0
flush_location   | 9/11E181C0
replay_location  | 9/11E18090
sync_priority| 0
sync_state   | async
-[ RECORD 2 ]+--
pid  | 2043
usesysid | 10
usename  | postgres
application_name | walreceiver
client_addr  | 10.72.73.YY
client_hostname  |
client_port  | 55716
backend_start| 2016-10-02 11:48:07.38359-05
backend_xmin |
state| streaming
sent_location| 9/11E181C0
write_location   | 9/11E181C0
flush_location   | 9/11E181C0
replay_location  | 9/11E18090
sync_priority| 0
sync_state   | async



> select * from pg_replication_slots
>
> bd=# select * from pg_replication_slots;
-[ RECORD 1 ]+-
slot_name| replica_calleXX_slot
plugin   |
slot_type| physical
datoid   |
database |
active   | t
active_pid   | 1892
xmin | 8355084
catalog_xmin |
restart_lsn  | 9/11FA3D18
-[ RECORD 2 ]+-
slot_name| replica_local_slot
plugin   |
slot_type| physical
datoid   |
database |
active   | t
active_pid   | 2043
xmin | 5463120
catalog_xmin |
restart_lsn  | 9/11FA3D18





> --
> Álvaro Herrerahttps://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] autovacuum excesivo PostgreSQL 9.5

2016-10-03 Por tema Alvaro Herrera 
Hellmuth Vargas escribió:
> El 3 de octubre de 2016, 16:17, Alvaro Herrera
> escribió:
> 
> > Hellmuth Vargas escribió:
> > > Hola Alvaro
> > >
> > > Muchas gracias por el tiempo.. respondo entre lineas:
> >
> > Pero no respondiste esta parte:
> >
> >¿no tendrás alguna transacción preparada abierta?  Mira en
> >pg_stat_activity y pg_prepared_xacts.
> >
> >
> Perdon Alvaro

Hmm, no hay ninguna "idle in transaction" ni nada que esté ejecutándose
desde hace más que un rato.  Y no hay ninguna transacción preparada ...
¿qué otra cosa puede impedir que vacuum elimine filas?  Supongo que algo
se me está escapando pero no sé qué.  Por un momento pensé que podría
haber sido un "backup" abierto, pero eso no debería causar este problema
que yo recuerde ...

Ahh, ¿no tendrás un standby con "feedback" activado que tiene una
transacción preparada, o un slot inactivo?  Pega acá
select * from pg_stat_replication
select * from pg_replication_slots

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

Re: [pgsql-es-ayuda] autovacuum excesivo PostgreSQL 9.5

2016-10-03 Por tema Hellmuth Vargas 
El 3 de octubre de 2016, 16:17, Alvaro Herrera
escribió:

> Hellmuth Vargas escribió:
> > Hola Alvaro
> >
> > Muchas gracias por el tiempo.. respondo entre lineas:
>
> Pero no respondiste esta parte:
>
>¿no tendrás alguna transacción preparada abierta?  Mira en
>pg_stat_activity y pg_prepared_xacts.
>
>
Perdon Alvaro

pid backend_start xact_start query_start state_change waiting state
backend_xid backend_xmin query
2329 2016-10-02 11:50:48.211693-05
2016-10-03 16:24:13.078628-05 2016-10-03 16:24:13.080102-05 f idle


1951 2016-10-02 11:47:38.104996-05
2016-10-03 16:24:07.580646-05 2016-10-03 16:24:07.581901-05 f idle


2998 2016-10-02 11:57:18.434209-05
2016-10-03 16:24:11.504117-05 2016-10-03 16:24:11.512482-05 f idle


*1974* *2016-10-03 16:23:59.018115-05* *2016-10-03 16:24:12.994839-05*
*2016-10-03
16:24:12.994839-05* *2016-10-03 16:24:12.99484-05* *f* *active*
*8342722* *autovacuum: VACUUM pg_catalog.pg_attribute*
60412 2016-10-03 15:42:18.497036-05
2016-10-03 16:24:00.295426-05 2016-10-03 16:24:00.295465-05 f idle

COMMIT
62959 2016-10-03 15:58:24.344015-05
2016-10-03 16:12:26.563051-05 2016-10-03 16:12:26.58076-05 f idle

COMMIT
62960 2016-10-03 15:58:24.351477-05
2016-10-03 16:16:24.455809-05 2016-10-03 16:16:24.455825-05 f idle

COMMIT
2244 2016-10-02 11:50:06.527689-05
2016-10-03 16:24:08.550525-05 2016-10-03 16:24:08.550557-05 f idle

COMMIT
2953 2016-10-02 11:56:58.935904-05
2016-10-03 16:24:12.413807-05 2016-10-03 16:24:12.41585-05 f idle


2999 2016-10-02 11:57:18.559647-05
2016-10-03 16:24:11.513935-05 2016-10-03 16:24:11.524073-05 f idle


2290 2016-10-02 11:50:39.419437-05
2016-10-03 16:24:16.042693-05 2016-10-03 16:24:16.057769-05 f idle


*65328* *2016-10-03 16:12:32.051363-05* *2016-10-03
16:13:06.642648-05* *2016-10-03
16:13:06.642648-05* *2016-10-03 16:13:06.642649-05* *f* *active*
*8338139* *autovacuum: VACUUM sac.marcador*
54614 2016-10-03 15:06:17.258045-05
2016-10-03 15:12:29.003785-05 2016-10-03 15:12:29.005669-05 f idle

SELECT column_name FROM information_schema.columns WHERE
table_schema='colpensionessac' AND table_name='tipificacioncorreo' ORDER BY
ordinal_position
51512 2016-10-03 08:06:09.047226-05
2016-10-03 15:59:33.065909-05 2016-10-03 15:59:33.066646-05 f idle


54615 2016-10-03 15:06:17.26081-05
2016-10-03 16:02:23.832531-05 2016-10-03 16:02:23.832585-05 f idle

SET search_path TO "$user", public
51517 2016-10-03 08:06:13.017255-05
2016-10-03 08:07:33.183604-05 2016-10-03 08:07:34.920135-05 f idle


analyze sac.marcador ;
46848 2016-10-03 14:18:36.332516-05
2016-10-03 16:12:26.572828-05 2016-10-03 16:12:26.580269-05 f idle

COMMIT
60004 2016-10-03 15:39:52.918343-05
2016-10-03 16:24:16.06574-05 2016-10-03 16:24:16.065748-05 f idle

COMMIT
46084 2016-10-03 07:32:56.116658-05
2016-10-03 16:12:26.568076-05 2016-10-03 16:12:26.581555-05 f idle

COMMIT
36428 2016-10-03 13:14:09.801684-05
2016-10-03 16:12:19.34997-05 2016-10-03 16:12:19.351039-05 f idle

COMMIT
54857 2016-10-03 15:07:47.494428-05
2016-10-03 15:11:10.2174-05 2016-10-03 15:11:10.217493-05 f idle


28717 2016-10-03 12:26:48.557859-05
2016-10-03 12:26:48.874593-05 2016-10-03 12:26:48.874657-05 f idle

SELECT nspname FROM pg_namespace
59489 2016-10-03 08:55:03.645719-05
2016-10-03 08:57:33.986584-05 2016-10-03 08:57:33.986957-05 f idle

SELECT c.oid, a.attnum, a.attname, c.relname, n.nspname, a.attnotnull OR
(t.typtype = 'd' AND t.typnotnull), pg_catalog.pg_get_expr(d.adbin,
d.adrelid) LIKE '%nextval(%' FROM pg_catalog.pg_class c JOIN
pg_catalog.pg_namespace n ON (c.relnamespace = n.oid) JOIN
pg_catalog.pg_attribute a ON (c.oid = a.attrelid) JOIN pg_catalog.pg_type t
ON (a.atttypid = t.oid) LEFT JOIN pg_catalog.pg_attrdef d ON (d.adrelid =
a.attrelid AND d.adnum = a.attnum) JOIN (SELECT 44940 AS oid , 1 AS attnum
UNION ALL SELECT 44940, 2 UNION ALL SELECT 44940, 3 UNION ALL SELECT 44940,
4 UNION ALL SELECT 44940, 5 UNION ALL SELECT 44940, 6 UNION ALL SELECT
44940, 7 UNION ALL SELECT 44940, 8 UNION ALL SELECT 44940, 9 UNION ALL
SELECT 44940, 10 UNION ALL SELECT 44940, 11 UNION ALL SELECT 44940, 12
UNION ALL SELECT 44940, 13 UNION ALL SELECT 44940, 14 UNION ALL SELECT
44940, 15 UNION ALL SELECT 44940, 16 UNION ALL SELECT 44940, 17 UNION ALL
SELECT 44940, 18 UNION ALL SELECT 44940, 19 UNION ALL SELECT 44940, 20
UNION ALL SELECT 44940, 21 UNION ALL SELECT 44940, 22 UNION ALL SELECT
44940, 23 UNION ALL SELECT 44940, 24 UNION ALL SELECT 44940, 25 UNION ALL
SELECT 44940, 26 UNION ALL SELECT 44940, 27 UNION ALL SELECT 44940, 28
UNION ALL SELECT 44940, 29 UNION ALL SELECT 44940, 30 UNION ALL SELECT
44940, 31 UNION ALL SELECT 44940, 32 UNION ALL SELECT 44940, 33) vals ON
(c.oid = vals.oid AND a.attnum = vals.attnum)
59671 2016-10-03 08:56:18.50717-05
2016-10-03 08:56:18.838372-05 2016-10-03 08:56:18.838396-05 f idle

show search_path
28718 2016-10-03 12:26:48.56114-05
2016-10-03 12:29:44.169251-05 2016-10-03 12:29:44.169288-05 f idle

SET search_path TO "$user", public
60006 2016-10-03

Re: [pgsql-es-ayuda] autovacuum excesivo PostgreSQL 9.5

2016-10-03 Por tema Alvaro Herrera 
Hellmuth Vargas escribió:
> Hola Alvaro
> 
> Muchas gracias por el tiempo.. respondo entre lineas:

Pero no respondiste esta parte:

   ¿no tendrás alguna transacción preparada abierta?  Mira en
   pg_stat_activity y pg_prepared_xacts.

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

Re: [pgsql-es-ayuda] autovacuum excesivo PostgreSQL 9.5

2016-10-03 Por tema Hellmuth Vargas 
Hola Alvaro

Muchas gracias por el tiempo.. respondo entre lineas:


El 3 de octubre de 2016, 16:01, Alvaro Herrera
escribió:

> Hellmuth Vargas escribió:
>
> > bd=# select * from  pg_stat_user_tables where relname in ('marcador',
> > 'usuario');
>
> Por alguna razón estas tablas tienen n_dead_tup que no parece decrecer?
> ¿no tendrás alguna transacción preparada abierta?  Mira en
> pg_stat_activity y pg_prepared_xacts.


> Si haces un "vacuum verbose usuario", ¿qué dice?  Me pregunto si
> autovacuum estará arrojando errores antes que termine.  Mira en el log.
>
>
VACUUM FULL analyze verbose sac.marcador;

INFO:  vacuuming "bd.sac.marcador"
INFO:  "marcador": found 0 removable, 2580480 nonremovable row versions in
104585 pages
DETAIL:  1082081 dead row versions cannot be removed yet.
CPU 0.95s/10.97u sec elapsed 26.32 sec.
INFO:  analyzing "sac.marcador"
INFO:  "marcador": scanned 104611 of 104611 pages, containing 1498399 live
rows and 1082098 dead rows; 12 rows in sample, 1498399 estimated total
rows
Query returned successfully with no result in 39.8 secs.


--- log:

_2016-10-03 01:56:26 COTproc:9348 LOG:  automatic vacuum of table
"bd.sac.marcador": index scans: 0
pages: 0 removed, 59776 remain, 0 skipped due to pins
tuples: 0 removed, 2478519 remain, 989963 are dead but not yet
removable
buffer usage: 54441 hits, 70857 misses, 2 dirtied
avg read rate: 4.769 MB/s, avg write rate: 0.000 MB/s
system usage: CPU 0.13s/0.26u sec elapsed 116.06 sec

_2016-10-03 01:58:46 COTproc:9421 LOG:  automatic vacuum of table
"bd.sac.marcador": index scans: 0
pages: 0 removed, 59776 remain, 0 skipped due to pins
tuples: 0 removed, 2478519 remain, 989963 are dead but not yet
removable
buffer usage: 54441 hits, 70857 misses, 2 dirtied
avg read rate: 4.260 MB/s, avg write rate: 0.000 MB/s
system usage: CPU 0.15s/0.24u sec elapsed 129.93 sec

_2016-10-03 02:01:32 COTproc:9581 LOG:  automatic vacuum of table
"bd.sac.marcador": index scans: 0
pages: 0 removed, 59776 remain, 0 skipped due to pins
tuples: 0 removed, 2478519 remain, 989963 are dead but not yet
removable
buffer usage: 54473 hits, 70825 misses, 2 dirtied
avg read rate: 4.524 MB/s, avg write rate: 0.000 MB/s
system usage: CPU 0.13s/0.26u sec elapsed 122.31 sec

--- la tabla usuario:
VACUUM FULL analyze verbose sac.usuario;
INFO:  vacuuming "sac.usuario"
INFO:  "usuario": found 0 removable, 52298 nonremovable row versions in
2201 pages
DETAIL:  52002 dead row versions cannot be removed yet.
CPU 0.01s/0.20u sec elapsed 0.34 sec.
INFO:  analyzing "sac.usuario"
INFO:  "usuario": scanned 2209 of 2209 pages, containing 296 live rows and
52002 dead rows; 296 rows in sample, 296 estimated total rows
Query returned successfully with no result in 2.2 secs.


--- log:

_2016-10-03 01:58:49 COTproc:9421 LOG:  automatic vacuum of table
"bd.sac.usuario": index scans: 0
pages: 0 removed, 1587 remain, 0 skipped due to pins
tuples: 0 removed, 47457 remain, 47161 are dead but not yet
removable
buffer usage: 3450 hits, 1061 misses, 5 dirtied
avg read rate: 2.927 MB/s, avg write rate: 0.014 MB/s
system usage: CPU 0.00s/0.01u sec elapsed 2.83 sec

_2016-10-03 02:00:45 COTproc:9619 LOG:  automatic vacuum of table
"bd.sac.usuario": index scans: 0
pages: 0 removed, 1587 remain, 0 skipped due to pins
tuples: 0 removed, 47457 remain, 47161 are dead but not yet
removable
buffer usage: 3185 hits, 1326 misses, 6 dirtied
avg read rate: 3.009 MB/s, avg write rate: 0.014 MB/s
system usage: CPU 0.00s/0.01u sec elapsed 3.44 sec

_2016-10-03 02:01:36 COTproc:9581 LOG:  automatic vacuum of table
"bd.sac.usuario": index scans: 0
pages: 0 removed, 1587 remain, 0 skipped due to pins
tuples: 0 removed, 47457 remain, 47161 are dead but not yet
removable
buffer usage: 3187 hits, 1324 misses, 6 dirtied
avg read rate: 3.064 MB/s, avg write rate: 0.014 MB/s
system usage: CPU 0.00s/0.00u sec elapsed 3.37 sec


Lo particular es que  esa campaña solo trabaja en horario hábil.. y el log
corresponde a la madrugada cuando no se esta haciendo naday asi se la
pasa tooodo el tiempo


Ademas también se evidencia sobre algunas tablas del sistema

bd=# select * from pg_stat_sys_tables where relname in ('pg_statistic');
-[ RECORD 1 ]---+--
relid   | 2619
schemaname  | pg_catalog
relname | pg_statistic
seq_scan| 38
seq_tup_read| 363762
idx_scan| 4596569
idx_tup_fetch   | 2439173
n_tup_ins   | 329
n_tup_upd   | 78854
n_tup_del   | 31
n_tup_hot_upd   | 6053
n_live_tup  | 4478
n_dead_tup  | 77924
n_mod_since_analyze | 79214
last_vacuum | 2016-10-03 00:10:02.477176-05
last_autovacuum

Re: [pgsql-es-ayuda] autovacuum excesivo PostgreSQL 9.5

2016-10-03 Por tema Alvaro Herrera 
Hellmuth Vargas escribió:

> bd=# select * from  pg_stat_user_tables where relname in ('marcador',
> 'usuario');

Por alguna razón estas tablas tienen n_dead_tup que no parece decrecer?
¿no tendrás alguna transacción preparada abierta?  Mira en
pg_stat_activity y pg_prepared_xacts.

Si haces un "vacuum verbose usuario", ¿qué dice?  Me pregunto si
autovacuum estará arrojando errores antes que termine.  Mira en el log.

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

Re: [pgsql-es-ayuda] autovacuum excesivo PostgreSQL 9.5

2016-10-03 Por tema Hellmuth Vargas 
Hola Alvaro

Respondo entre lineas


El 3 de octubre de 2016, 15:15, Alvaro Herrera
escribió:

> Hellmuth Vargas escribió:
> > Hola Alvaro, gracias por responder
> >
> > La versión anterior era la postgresql-9.3.12 pero incluso esta base de
> > datos la venia actualizando periódicamente con las diferentes
> publicaciones
> > de la 9.3 y nunca observe el comportamiento que he descrito.
>
> OK.  ¿hay algún patrón visible en las tablas que se les está haciendo
> autovacuum?  Mira el last_autovacuum y last_autoanalyze en
> pg_stat_user_tables y pg_stat_sys_tables.  Si no hay nada extraño (unas
> pocas tablas que se procesen continuamente), activa
> log_autovacuum_min_duration (en 0) para ver qué tablas son las
> afectadas.
>


bd=# select * from  pg_stat_user_tables where relname in ('marcador',
'usuario');
-[ RECORD 1 ]---+--
relid   | 44940
schemaname  | sac
relname | usuario
seq_scan| 15692
seq_tup_read| 5708142
idx_scan| 20595628
idx_tup_fetch   | 19409438
n_tup_ins   | 27
n_tup_upd   | 53326
n_tup_del   | 0
n_tup_hot_upd   | 30722
n_live_tup  | 296
n_dead_tup  | 51691
n_mod_since_analyze | 4530
last_vacuum | 2016-10-03 00:11:41.772669-05
last_autovacuum | 2016-10-03 15:46:05.782991-05
last_analyze| 2016-10-03 00:11:57.540457-05
last_autoanalyze| 2016-09-30 13:56:12.424892-05
vacuum_count| 14
autovacuum_count| *20022*
analyze_count   | 19
autoanalyze_count   | 63
-[ RECORD 2 ]---+--
relid   | 44165
schemaname  | colpensionessac
relname | marcadoroutbound
seq_scan| 871
seq_tup_read| 578174252
idx_scan| 2922480
idx_tup_fetch   | 5844053124
n_tup_ins   | 1114425
n_tup_upd   | 1085804
n_tup_del   | 144
n_tup_hot_upd   | 506464
n_live_tup  | 1497215
n_dead_tup  | 1079276
n_mod_since_analyze | 83183
last_vacuum | 2016-10-03 00:11:34.40105-05
last_autovacuum | 2016-10-03 15:45:34.593168-05
last_analyze| 2016-10-03 08:07:34.91577-05
last_autoanalyze| 2016-09-30 11:08:48.261976-05
vacuum_count| 15
autovacuum_count| *14540*
analyze_count   | 19
autoanalyze_count   | 11




>
> ¿Cuánto es autovacuum_freeze_max_age?  Usa SHOW para mostrarlo.
>

autovacuum;on
autovacuum_analyze_scale_factor;0.05
autovacuum_analyze_threshold;40
autovacuum_freeze_max_age;2
autovacuum_max_workers;5
autovacuum_multixact_freeze_max_age;4
autovacuum_naptime;1min
autovacuum_vacuum_cost_delay;10ms
autovacuum_vacuum_cost_limit;-1
autovacuum_vacuum_scale_factor;0.2
autovacuum_vacuum_threshold;90




>
> > El volcado del control file es:
>
> > Latest checkpoint's NextMultiXactId:  2053905
> > Latest checkpoint's oldestMultiXid:   2052644
> > Latest checkpoint's NextMultiOffset:  3269641
>
> Hmm, esto es extraño creo.  si no leo mal, has usado 1261 multixacts y
> 3269641 miembros, es decir 2592 miembros por multixact?  Eso no tiene
> sentido ... ¿cuántos archivos tienes en pg_multixact/offsets y cuántos
> en pg_multixact/members?   ¿tienes muchas llaves foráneas?
>


[postgres@MBD data]# cd pg_multixact/
[postgres@MBD pg_multixact]# ls
members  offsets
[postgres@MBD pg_multixact]# cd offsets/
[postgres@MBD offsets]# ls -lah
total 96K
drwx-- 2 postgres postgres 4,0K sep 30 01:53 .
drwx-- 4 postgres postgres 4,0K sep 30 01:50 ..
-rwx-- 1 postgres postgres  88K oct  3 15:27 001F
[postgres@MBD offsets]# cd ..
[postgres@MBD pg_multixact]# cd members/
[postgres@MBD members]# ls -lah
total 128K
drwx-- 2 postgres postgres 4,0K sep 30 01:53 .
drwx-- 4 postgres postgres 4,0K sep 30 01:50 ..
-rwx-- 1 postgres postgres 120K oct  3 15:27 003E

Muchas Gracias



>
> --
> Álvaro Herrerahttps://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet

Re: [pgsql-es-ayuda] autovacuum excesivo PostgreSQL 9.5

2016-10-03 Por tema Alvaro Herrera 
Hellmuth Vargas escribió:
> Hola Alvaro, gracias por responder
> 
> La versión anterior era la postgresql-9.3.12 pero incluso esta base de
> datos la venia actualizando periódicamente con las diferentes publicaciones
> de la 9.3 y nunca observe el comportamiento que he descrito.

OK.  ¿hay algún patrón visible en las tablas que se les está haciendo
autovacuum?  Mira el last_autovacuum y last_autoanalyze en
pg_stat_user_tables y pg_stat_sys_tables.  Si no hay nada extraño (unas
pocas tablas que se procesen continuamente), activa
log_autovacuum_min_duration (en 0) para ver qué tablas son las
afectadas.

¿Cuánto es autovacuum_freeze_max_age?  Usa SHOW para mostrarlo.

> El volcado del control file es:

> Latest checkpoint's NextMultiXactId:  2053905
> Latest checkpoint's oldestMultiXid:   2052644
> Latest checkpoint's NextMultiOffset:  3269641

Hmm, esto es extraño creo.  si no leo mal, has usado 1261 multixacts y
3269641 miembros, es decir 2592 miembros por multixact?  Eso no tiene
sentido ... ¿cuántos archivos tienes en pg_multixact/offsets y cuántos
en pg_multixact/members?   ¿tienes muchas llaves foráneas?

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

Re: [pgsql-es-ayuda] autovacuum excesivo PostgreSQL 9.5

2016-10-03 Por tema Hellmuth Vargas 
Hola Alvaro, gracias por responder

La versión anterior era la postgresql-9.3.12 pero incluso esta base de
datos la venia actualizando periódicamente con las diferentes publicaciones
de la 9.3 y nunca observe el comportamiento que he descrito. El volcado del
control file es:


[postgres@M_BD tmp]# pg_controldata -D ./PostgreSQL/9.5/data/
pg_control version number:942
Catalog version number:   201510051
Database system identifier:   6336011272628208106
Database cluster state:   in production
pg_control last modified: lun 03 oct 2016 14:12:52 COT
Latest checkpoint location:   1896/ACA64958
Prior checkpoint location:1896/9A416FB8
Latest checkpoint's REDO location:1896/AB72AB00
Latest checkpoint's REDO WAL file:0001189600AB
Latest checkpoint's TimeLineID:   1
Latest checkpoint's PrevTimeLineID:   1
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID:  0/2021183943
Latest checkpoint's NextOID:  48985
Latest checkpoint's NextMultiXactId:  2053905
Latest checkpoint's NextMultiOffset:  3269641
Latest checkpoint's oldestXID:2014532528
Latest checkpoint's oldestXID's DB:   13236
Latest checkpoint's oldestActiveXID:  2021183943
Latest checkpoint's oldestMultiXid:   2052644
Latest checkpoint's oldestMulti's DB: 13236
Latest checkpoint's oldestCommitTsXid:0
Latest checkpoint's newestCommitTsXid:0
Time of latest checkpoint:lun 03 oct 2016 14:12:05 COT
Fake LSN counter for unlogged rels:   0/1
Minimum recovery ending location: 0/0
Min recovery ending loc's timeline:   0
Backup start location:0/0
Backup end location:  0/0
End-of-backup record required:no
wal_level setting:hot_standby
wal_log_hints setting:off
max_connections setting:  810
max_worker_processes setting: 10
max_prepared_xacts setting:   0
max_locks_per_xact setting:   1024
track_commit_timestamp setting:   off
Maximum data alignment:   8
Database block size:  8192
Blocks per segment of large relation: 131072
WAL block size:   8192
Bytes per WAL segment:16777216
Maximum length of identifiers:64
Maximum columns in an index:  32
Maximum size of a TOAST chunk:1996
Size of a large-object chunk: 2048
Date/time type storage:   64-bit integers
Float4 argument passing:  by value
Float8 argument passing:  by value
Data page checksum version:   0




El 3 de octubre de 2016, 12:26, Alvaro Herrera
escribió:

> Hellmuth Vargas escribió:
> > Hola Franciso
> >
> > Si en efecto esta consumiendo mas recursos  y la carga en general de la
> > maquina ha subido en comparación con los valores que mantenía
> (estadísticas
> > SAR) ademas, pues las operaciones que hacia antes son exactamente las
> > mismas que esta haciendo ahora por que no cambio en nada las
> aplicaciones,
> > incluso ya se ha evidenciado que algunas consultas se encolan en esperar
> de
> > la finalización del autovacuum
>
> ¿exactamente qué versión estabas corriendo antes?  Me pregunto si tiene
> que ver con multixact ids.  Pega la salida de pg_controldata.
>
> --
> Álvaro Herrerahttps://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] autovacuum excesivo PostgreSQL 9.5

2016-10-03 Por tema Alvaro Herrera 
Hellmuth Vargas escribió:
> Hola Franciso
> 
> Si en efecto esta consumiendo mas recursos  y la carga en general de la
> maquina ha subido en comparación con los valores que mantenía (estadísticas
> SAR) ademas, pues las operaciones que hacia antes son exactamente las
> mismas que esta haciendo ahora por que no cambio en nada las aplicaciones,
> incluso ya se ha evidenciado que algunas consultas se encolan en esperar de
> la finalización del autovacuum

¿exactamente qué versión estabas corriendo antes?  Me pregunto si tiene
que ver con multixact ids.  Pega la salida de pg_controldata.

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

Re: [pgsql-es-ayuda] autovacuum excesivo PostgreSQL 9.5

2016-10-03 Por tema Hellmuth Vargas 
Hola Franciso

Si en efecto esta consumiendo mas recursos  y la carga en general de la
maquina ha subido en comparación con los valores que mantenía (estadísticas
SAR) ademas, pues las operaciones que hacia antes son exactamente las
mismas que esta haciendo ahora por que no cambio en nada las aplicaciones,
incluso ya se ha evidenciado que algunas consultas se encolan en esperar de
la finalización del autovacuum

El 3 de octubre de 2016, 11:27, Francisco Olarte
escribió:

> Hellmuth:
>
> 2016-10-03 15:21 GMT+02:00 Hellmuth Vargas :
> ...
> > inhabilito, pero ahora prácticamente se mantiene realizaron autovacuum a
> > unas tablas de forma casi permanente, tema que no sucedía antes. Ya les
> ...
>
> Independientemente de que este muchos mas tiempo corriendo el
> autovacuum, ¿ consume mas recursos ( cpu / disco etc ) ? ¿ van las
> aplicaciones mas lentas ? es decir, a ver si es que va mas pausado, o
> que te lo esta mostrando de una forma que aparece mas tiempo corriendo
> que antes.
>
> Francisco Olarte.
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] autovacuum excesivo PostgreSQL 9.5

2016-10-03 Por tema Francisco Olarte 
Hellmuth:

2016-10-03 15:21 GMT+02:00 Hellmuth Vargas :
...
> inhabilito, pero ahora prácticamente se mantiene realizaron autovacuum a
> unas tablas de forma casi permanente, tema que no sucedía antes. Ya les
...

Independientemente de que este muchos mas tiempo corriendo el
autovacuum, ¿ consume mas recursos ( cpu / disco etc ) ? ¿ van las
aplicaciones mas lentas ? es decir, a ver si es que va mas pausado, o
que te lo esta mostrando de una forma que aparece mas tiempo corriendo
que antes.

Francisco Olarte.

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda