La mesa ocupada no se aspira

11

Estamos utilizando Postgres 9.2 en Windows para almacenar datos de series de tiempo de baja frecuencia: estamos insertando alrededor de 2000 filas por segundo cada segundo 24 horas, 7 días a la semana sin tiempo de inactividad. Hay una DELETEque se ejecuta en la mesa cada 10 minutos más o menos para mantener la longitud de la mesa en un número fijo de días. Esto termina siendo unos 900 millones de filas bastante estables. (Para los interesados, SELECT, INSERT, DELETEson todos performant).

Como tal DELETE, mientras que eliminar filas no está liberando espacio en disco. Para eso tenemos VACUUMque correr.

Tengo consultas pg_stat_user_tablesy VACUUMparece que nunca se ha ejecutado.

Lo que entiendo de varios documentos ( http://www.postgresql.org/docs/9.2/static/routine-vacuuming.html ):

  • parece que tenemos la aspiradora automática activada, y se está ejecutando en otras tablas.
  • el vacío automático no funciona FULL, y no debería requerir un bloqueo exclusivo en la mesa.

¿Alguien tiene alguna idea de por qué la aspiradora automática no está funcionando? ¿Es esto simplemente porque la mesa está continuamente ocupada?

¿Y vale la pena correr VACUUMdespués de cada uno DELETEen este caso (que corre cada 10 minutos)?

Editar:

Consulta usando el SQL desde el siguiente enlace SO:

-[ RECORD 2 ]---+---------------------------
schemaname      | stats
relname         | statistic_values_by_sec
last_vacuum     |
last_autovacuum |
n_tup           |    932,315,264
dead_tup        |    940,727,818
av_threshold    |    186,463,103
expect_av       | *

y salida sin procesar:

-[ RECORD 3 ]-----+---------------------------
relid             | 501908
schemaname        | stats
relname           | statistic_values_by_sec
seq_scan          | 12
seq_tup_read      | 4526762064
idx_scan          | 29643
idx_tup_fetch     | 2544206912
n_tup_ins         | 1573896877
n_tup_upd         | 0
n_tup_del         | 941176496
n_tup_hot_upd     | 0
n_live_tup        | 688858417
n_dead_tup        | 940727818
last_vacuum       |
last_autovacuum   |
last_analyze      |
last_autoanalyze  | 2014-08-09 01:36:21.703+01
vacuum_count      | 0
autovacuum_count  | 0
analyze_count     | 0
autoanalyze_count | 69
postgresql vacuum Barry
fuente
44
Ver Autovacuum agresivo en PostgreSQL . También sería interesante tener select * from pg_stat_user_tablespara esta tabla (uso \xen psql para una salida bien formateada)
Daniel Vérité
2
Ese enlace es útil y tal vez responde la pregunta: la mesa está demasiado ocupada para que funcione la aspiradora automática. @ DanielVérité He actualizado la pregunta con el resultado que solicitó.
Barry
3
¡Son muchas tuplas muertas! Si es posible, considere la posibilidad de particionar la tabla marcando la hora y soltando las particiones antiguas en lugar de eliminarlas. La advertencia principal es que el índice único en las particiones no es compatible.
Daniel Vérité
1
¿El archivo de registro tiene mensajes sobre el vacío automático en esta tabla que se cancela?
jjanes
@jjanes No: no había ninguna indicación en los registros de que alguna vez se iniciara el vacío automático.
Barry

Respuestas:

2

Me gustaría ver en la partición . Si está particionado por día, puede soltar toda la partición una vez que sea demasiado vieja. Es posible que ya no tenga que pasar la aspiradora.

Además, el rendimiento general puede aumentar, ya que no está insertando donde está eliminando. Solo necesitaría escribir el código para crear nuevas particiones y eliminar las antiguas.

Para eso es exactamente el particionamiento.

SQB
fuente