PostgreSQL Long VACUUM

Question

Actualmente estoy limpiando una tabla con 2 índices y 250 millones de filas activas y aproximadamente la misma cantidad de filas muertas (o más). Emití el comando VACCUM FULL ANALYZE desde mi computadora cliente (laptop) a mi servidor. Ha estado haciendo sus negocios 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 Xeon de 2.66 GHz de código cuádruple, 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 de 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 a procinfo , puedo extrapolar que el proceso VACUUM pasa la mayor parte del tiempo (88%) esperando I / 0.

Entonces, ¿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 relación inactiva)? ¿Por qué está esperando E / S si la carga de E / S no es alta? ¿Por qué no va más rápido con todo este poder / recursos al alcance de la mano? ¡Me parece que VACUUM puede y debe ser multiproceso, especialmente si está trabajando en una mesa enorme y es la única que funciona!

Además, ¿es su forma de configurar postgresql.conf para permitirle multiprocesar tales VACUUM? ¿Puedo matarlo y aun así beneficiarme de su limpieza parcial? Necesito trabajar en esa mesa.

[Estoy usando PostgreSQL 8.1]

Gracias de nuevo

Answer 1

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

Tuve exactamente el mismo escenario. Lo mejor de ti:

• matar el vacío
• haga una copia de seguridad de la tabla con la opción pg_dump -t
• soltar la mesa
• restaurar la tabla

Si está utilizando 8.x, mire las opciones de autovacuum. El vacío es de un solo subproceso, no hay nada que pueda hacer para que use varios subprocesos.

Answer 2

Algunos consejos rápidos:

• Ejecute VACUUM FULL VERBOSE para que pueda ver lo que está sucediendo.
• Descarte todos los índices antes del VACÍO. Es más rápido reconstruirlos que aspirarlos. También debe reconstruirlos de vez en cuando porque VACUUM FULL no es lo suficientemente bueno (especialmente en un PosgreSQL tan antiguo como 8.1).
• Establezca el maintenance_work_mem realmente alto.
• Use un PostgreSQL más nuevo. Por cierto, 8.4 tendrá una gran mejora en la aspiradora.

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 REINDEX es innecesario.

Answer 3

¿Está seguro de que no tiene nada en curso que pueda bloquear las mesas y evitar que se ejecute el vacío?

(De todos modos, es mejor usar vacuum_cost_delay para que el vacío no sea perjudicial para la producción).

Answer 4

Old VACUUM FULL es un fósil. También es bastante lento, y luego tienes que REINDEX. No lo uses Si realmente desea desfragmentar una tabla, use CLUSTER, o esto:

Digamos que te queda algo de espacio en disco, eso es mucho más rápido que volcar y volver a cargar:

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

Tenga en cuenta que esto no copiará sus restricciones. Puede usar CREATE TABLE LIKE ... para copiarlos.

  

Entonces, ¿por qué no está utilizando más núcleos a través de hilos?

pg no admite esto.