Por que é PostgreSQL comer todo o meu precioso espaço HD?

Question

Acabei de transferir o máximo de dados link-estrutura, referente wikipedia (Inglês) quanto eu poderia. Basicamente, eu baixei um monte de SQL despejos de wikipedia mais recente repositório despejo . Desde que eu estou usando PostgreSQL em vez do MySQL, eu decidi carregar todas estas lixeiras em meu db usando comandos .

De qualquer forma, uma dessas tabelas tem 295 milhões de linhas: o pagelinks mesa; ele contém todos os hiperlinks intra-wiki. Do meu laptop, usando pgAdmin III, enviei o seguinte comando para o meu servidor de banco de dados (outro computador):

SELECT pl_namespace, COUNT(*) FROM pagelinks GROUP BY (pl_namespace);

A sua sido para ele por uma hora ou assim agora. A coisa é que o postmaster parece estar comendo mais e mais do meu espaço muito limitado HD. Eu acho que comeu cerca de 20 GB a partir de agora. Eu já tinha jogado ao redor com o arquivo postgresql.conf, a fim de dar-lhe mais flexibilidade desempenho (ou seja, deixá-lo usar mais recursos) para ele está sendo executado com 12 GB de RAM. Eu acho que, basicamente quadruplicou a maioria dos bytes e tais variáveis ??relacionadas deste arquivo pensando que iria usar mais memória RAM para fazer a sua coisa.

No entanto, o db não parece usar muito RAM. Usando o monitor do sistema Linux, eu sou capaz de ver que o servidor está usando 1.6 GB de memória compartilhada (RAM). Enfim, eu estava querendo saber se vocês poderiam me ajudar a entender melhor o que está fazendo para ele parece que eu realmente não entendo como o PostgreSQL utiliza recursos HD .

Em relação à meta-estrutura de bases de dados wikipedia, eles fornecem uma boa esquema que podem ser de uso ou mesmo, mas de interesse para você.

Sinta-se livre para perguntar-me para mais detalhes, thx.

Answer 1

É provavelmente o GROUP BY que está causando o problema. Para fazer agrupamento, o banco de dados tem para classificar as linhas de colocar itens duplicados juntos. Um índice provavelmente não vai ajudar. Um cálculo back-of-the-envelope:

Assumindo que cada linha tem 100 bytes de espaço, que é 29,500,000,000 bytes, ou cerca de 30 GB de armazenamento. Ele não pode caber tudo o que na memória, para que o seu sistema está se debatendo, o que retarda as operações para baixo por um fator de 1000 ou mais. Seu espaço de HD podem ser desaparecendo no espaço de troca, se ele está usando arquivos de swap.

Se você só precisa fazer este cálculo uma vez, tentar quebrar o diferencia em subconjuntos menores de dados. Assumindo pl_namespace é numérico e varia de 1-295million, tentar algo como isto:

SELECT pl_namespace, COUNT(*)
FROM pagelinks
WHERE pl_namespace between 1 and 50000000
GROUP BY (pl_namespace);

Em seguida, faça o mesmo para 50.000.001-100.000.000 e assim por diante. Combine suas respostas em conjunto, utilizando UNION ou simplesmente tabular os resultados com um programa externo. Esqueça o que eu escrevi sobre um índice não ajudar GROUP BY; aqui, um índice vai ajudar a cláusula WHERE.

Answer 2

O exatamente está reivindicando que ele só está tomando 9.5MB de memória RAM? Isso parece improvável para mim - a memória compartilhada quase certamente é RAM que está sendo compartilhado entre diferentes processos Postgres. (Pelo que me lembro, cada cliente acaba como um processo separado, embora Tem sido um tempo para que eu pudesse estar muito errado.)

Você tem um índice na coluna pl_namespace? Se há uma enorme quantidade de resultados distintos, eu poderia imaginar que consulta a ser bastante pesado em uma mesa de 295 milhões de linhas sem índice. Dito isto, 10GB é uma enorme quantidade de engolir. Você sabe quais arquivos ele está escrevendo para?

Answer 3

Ok, então aqui é a essência dele:

a cláusula GROUP BY fez o inválido index', de modo que o postmaster (processo do servidor PostgreSQL) decidiu criar um grupo de mesas (23Gb de tabelas) que foram localizados no diretório $ PGDATA / base / 16384 / pgsql_tmp.

Ao modificar o arquivo postgresql.conf, eu tinha dado permissão para PostgreSQL para usar 1,6 GB de RAM (que eu vou agora duplo para ele tem acesso a 11,7 GB de RAM); o processo postmaster estava realmente usando até 1,6 GB de RAM, mas isso não foi suficiente, assim o diretório pgsql_tmp.

Como foi apontado por Barry Brown, já que eu só estava executando este comando SQL para obter algumas informações estatísticas sobre a distribuição das ligações entre o pagelinks.namespaces , eu poderia ter consultado um subconjunto de a 296 milhões pagelinks (isto é o que eles fazem para pesquisas).

Quando o comando retornar o conjunto de resultado, todas as tabelas temporárias foram excluídas automaticamente como se nada tivesse acontecido.

Thx para rapazes da sua ajuda!