PostgreSQL longo VÁCUO

Question

PostgreSQL longo VÁCUO

votos

5

Atualmente, estou limpando uma mesa com 2 índices e 250 milhões de linhas ativas e aproximadamente quantas linhas mortos (ou mais). I emitiu o comando VACCUM CHEIA ANALISAR do meu computador cliente (laptop) para o meu servidor. Foi indo sobre seu negócio para os últimos 3-4 dias ou mais; Eu estou querendo saber se ele vai acabar tão cedo, pois tenho muito trabalho a fazer!

O servidor tem um Xeon 2,66 processador quad-código GHz, 12 GB ou RAM e um controlador RAID ligado a 2 x 10K rpm 146 GB SAS HDS em uma configuração RAID 1; ele está sendo executado Suse Linux. Estou pensando...

Agora, em primeiro lugar o processo postmaster VÁCUO parece estar fazendo uso de apenas um núcleo. Em segundo lugar, eu não estou vendo um muito alto I / O escreve para I / O rácio de tempo ocioso. Em terceiro lugar, de chamar procinfo, eu posso extrapolar que o processo de vácuo passa a maior parte de seu tempo (88%) à espera de I / 0.

Então, por que não está utilizando mais núcleos através de tópicos, a fim de sobrecarregar o controlador RAID (obter alto I / O escreve para a marcha lenta ratio)? Por que é à espera de I / O se a carga I / O não é alta? Por que não ir mais rápido com todo esse poder / recursos em seus dedos? Parece-me que o vácuo pode e deve ser multithreaded, especialmente se ele está trabalhando em uma enorme mesa e é o único a trabalhar!

Além disso, é a sua maneira de configurar postgresql.conf para deixá-lo multithread tais VACUUM? Eu posso matá-lo e ainda beneficiar da sua parcial clean-up? Eu preciso trabalhar nessa tabela.

[Eu estou usando PostgreSQL 8.1]

Thx novamente

postgresql rdbms vacuum

Publicado 11/01/2009 em 22:22
fonte usuário Nicholas Leonard

Em outras línguas...

4 respostas

votos

4

Algumas dicas rápidas:

Executar VACUUM FULL VERBOSE para que você possa se o que está acontecendo.
Solte todos os índices antes do vácuo. É mais rápido para reconstruí-las de vácuo-los. Você também precisa reconstruir-los agora e, em seguida, porque VACUUM FULL não é bom o suficiente (especialmente em um velho PosgreSQL tais como 8,1).
Defina o maintenance_work_mem muito alto.
Use um PostgreSQL mais recente. Btw, 8,4 terá uma grande melhoria na aspiração.

Uma alternativa a vácuo é para despejar e restaurar.

Edit: Desde 9,0 VACUUM FULL reescreve a tabela inteira. É basicamente a mesma coisa que fazer um despejo + restaurar, portanto executar REINDEX é desnecessário.

Respondeu 12/01/2009 em 02:15
fonte usuário Martin Torhage

votos

0

Tem certeza de que não tem nada em andamento que poderiam bloquear tabelas e evitar vácuo de correr?

(De qualquer forma, é melhor usar vacuum_cost_delay de modo que o vácuo não é prejudicial para a produção.)

Respondeu 24/01/2009 em 01:49
fonte usuário user57991

votos

0

Old VACUUM FULL é um fóssil. É muito lento também, e você tem que reindexar depois. Não usá-lo. Se você realmente deseja desfragmentar uma tabela, uso do cluster, ou esta:

Lettssay você tem algum espaço livre em disco, isso é muito mais rápido do despejo e de 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;

Note que este não irá copiar suas limitações. Você pode usar CREATE TABLE como ... para copiá-los.

Então, por que não está utilizando mais núcleos através de tópicos

não pg não suporta isso.

Respondeu 04/05/2011 em 17:05
fonte usuário peufeu

Mark Harrison · Accepted Answer · 2009-01-12 00:39

votos

5

O autor da pergunta observou essa resposta como a melhor.

Você não diz qual a versão do PostgreSQL você está usando. É possível, é pré-8.0?

Eu tive esse mesmo cenário exato. Sua melhor melhor:

matar o vácuo
volta-se à mesa com opção -t pg_dump
remover a tabela
restaurar a tabela

Se você estiver usando 8.x, olhar para as opções autovacuum. Vácuo é único segmento, não há nada que você pode fazer para torná-lo usar vários segmentos.

Respondeu 12/01/2009 em 00:39
fonte usuário Mark Harrison