PostgreSQL Long VACUUM

Question

Actualmente estoy limpiando una tabla con 2 índices y 250 millones de filas activas y aproximadamente tantas filas muertas (o más). Emití el comando VACCUM FULL ANALYZE desde mi computadora cliente (computadora portátil) a mi servidor. Ha estado funcionando durante los últimos 3-4 días más o menos; Me pregunto si terminará pronto porque tengo mucho trabajo por hacer.

El servidor tiene un procesador cuádruple Xeon a 2,66 GHz, 12 GB o RAM y un controlador RAID conectado a 2 x 10K rpm 146 GB SAS HD en una configuración RAID 1; está ejecutando Suse Linux. Me pregunto ...

Ahora, en primer lugar, el proceso del postmaster VACUUM parece estar haciendo uso de un solo núcleo. En segundo lugar, no veo una escritura de E/S muy alta en la relación de tiempo de inactividad de E/S. En tercer lugar, al llamar al procinfo, puedo extrapolar que el proceso VACUUM pasa la mayor parte del tiempo (88%) esperando I/0.

¿Por qué no está utilizando más núcleos a través de subprocesos para sobrecargar el controlador RAID (obtener altas escrituras de E/S en la relación de inactividad)? ¿Por qué está esperando E/S si la carga de E/S no es alta? ¿Por qué no va más rápido con toda esta potencia/recursos en sus dedos? Me parece que VACUUM puede y debe ser multiproceso, especialmente si está trabajando en una mesa enorme y ¡es el único que funciona!

Además, ¿es una forma de configurar postgresql.conf para dejarlo multihilo en tales VACUUM? ¿Puedo matarlo y aún así beneficiarme de su limpieza parcial? Necesito trabajar en esa mesa.

[estoy usando PostgreSQL 8.1]

Thx de nuevo

Answer 1

Usted no dice qué versión de PostgreSQL que está utilizando. ¿Es posible que sea anterior a la 8.0?

Tuve este mismo escenario. Su mejor mejor:

• matar al vacío
• copia de seguridad de la tabla con pg_dump opción -t
• eliminar la tabla
• restaurar la tabla

Si está utilizando 8.x , mira las opciones de autovacío. El vacío tiene un solo hilo, no hay nada que pueda hacer para que use múltiples hilos.

Answer 2

Algunos consejos rápidos:

• Run VACÍO VERBOSE completo para que pueda se lo que está pasando.
• Coloque todos los índices antes del VACÍO. Es más rápido reconstruirlos que aspirarlos. También necesita reconstruirlos de vez en cuando porque VACUUM FULL no es lo suficientemente bueno (especialmente en un PosgreSQL tan antiguo como 8.1).
• Establezca maintenance_work_mem realmente alto.
• Utilice un PostgreSQL más nuevo. Por cierto, 8.4 tendrá una gran mejora en la aspiración.

Una alternativa a VACUUM es volcar y restaurar.

Editar: Desde 9.0 VACUUM FULL reescribe toda la tabla. Básicamente es lo mismo que hacer un volcado + restauración, por lo que ejecutar REINDICE es innecesario.

Answer 3

¿Estás seguro de que no tienes nada en curso que pueda bloquear las mesas y evitar el funcionamiento de la aspiradora?

(De todos modos, lo mejor es utilizar vacuum_cost_delay de manera que el vacío no es perjudicial para la producción.)

Answer 4

viejo vacío total es un fósil. También es bastante lento y luego REINDEX. No lo uses Si realmente desea desfragmentar una mesa, el uso del clúster, o esto:

Lettssay usted tiene un poco de espacio en disco a la izquierda, que es mucho más rápido que volcar & recarga:

CREATE TABLE newtable AS SELECT * FROM oldtable; 
CREATE INDEX bla ON newtable(...); 
ALTER TABLE oldtable RENAME TO archive; 
ALTER TABLE newtable RENAME TO oldtable; 

Nota esto no va a copiar sus limitaciones. Puede usar CREATE TABLE LIKE ... para copiarlos.

Así que por qué no es la utilización de más núcleos a través de hilos

pg no soporta esto.