Liberando espaço em disco após a queda do banco de dados


12

Estou trabalhando em um sistema de desenvolvimento e tenho restaurado em um banco de dados, digamos "foo", que estou usando para fins de desenvolvimento. Enquanto estou trabalhando nas dobras, acabei de executar o DROP DATABASE foo. No entanto, percebi rapidamente que comi todo o espaço do meu disco. Porcaria.

O VACUUM FULL, de um banco de dados lógico diferente, libera espaço do banco de dados que eu soltei anteriormente (foo)? Eu tentei isso de um banco de dados lógico diferente e o espaço livre foi recuperado, mas acho que não foi o suficiente para dar conta de todas as chamadas CREATE DATABASE / DROP DATABASE que fiz. Pode ter apenas VACUUM'ed o banco de dados lógico do qual eu corri.

Deve haver uma maneira de recuperar esse espaço sem executar um init total do banco de dados?

EDITAR

Então, reinicializei o banco de dados a partir de um backup, seguindo aproximadamente essas etapas . Após a restauração, recuperei uma tonelada de espaço em disco! Isso funciona por enquanto, mas qualquer ajuda sobre como limpar um banco de dados descartado ainda seria útil.

EDIT 2

Então, eu consegui coletar mais informações sobre esse problema ... Aqui está o que eu criei como exemplo:

Initial partition size:
                       Size   Used  Avail Use% Mounted on
                        25G   8.1G    16G  35% /apps1

After creating my new database and populating it:
                        25G    18G   6.4G  73% /apps1

After Dropping the database using "DROP database mydb" from a separate logical DB:
                        25G    13G    11G  56% /apps1

Portanto, parece-me que o novo banco de dados ocupou ~ 9,6 GB no disco. No entanto, depois de descartá-lo, o espaço em disco recuperado cresceu apenas ~ 4.6G. Então, existem aproximadamente 5 GB de espaço que me fazem pensar no que está acontecendo !?

E continua esse ciclo quando eu recrio, preenche e solto novamente.

Alguém tem alguma idéia do que resta depois que um comando "DROP DATABASE" é emitido?


Talvez também seja interessante notar que o arquivamento foi ativado. Parece que o local em que os arquivos do WAL estão sendo gravados é bastante grande. Eu não tenho monitorado de perto. Talvez eu tente o mesmo procedimento listado acima e execute um "du" nesse diretório para ver se todo o espaço é recuperado. Vou relatar de volta.
Jmoney38

Presumo que o vácuo não ajuda, então?
Rogerdpack

Respostas:


6

Experimente sudo lsof| grep deletede verifique se algum processo do PostgreSQL aparece. Este comando procura por arquivos que foram excluídos, mas seus descritores de arquivos ainda estão abertos por qualquer processo. Outro efeito colateral é isso df -he du -sh /difere. Isso ocorre porque duexamina o sistema de arquivos e resume o tamanho de todos os arquivos e dfo dispositivo físico.

Acabei de ter um problema com um banco de dados que não liberava espaço após um DROP tablee essa foi a causa.

A única solução que eu sei é reiniciar o banco de dados. Talvez você possa tentar enviar uma recarga (SIGHUP).


2
A lsof | grep deleteddica foi boa; para isso, adicione que você só precisa determinar quais sessões do postgresql ainda estão ativas e eliminá-las para liberar os arquivos. No meu caso, das mais de 500 conexões ativas, quase todas em IDLE ou COMMIT, matando uma única, encontrada SELECT * FROM pg_stat_activitye presa em um ANALYZE, foram suficientes para liberar os arquivos excluídos. ! 00 GB liberados.
Alex norte-Keys

5

Meu entendimento é que, quando você solta um banco de dados, ele e seus arquivos desaparecem.

A menos que você esteja usando espaços de tabela, cada banco de dados deve ter seus dados em seu próprio subdiretório em $ PGDATA / base. Usando um dos meus servidores como exemplo (como usuário do postgres):

-bash-3.2$ cd $PGDATA/base

-bash-3.2$ ls | wc -l
9

-bash-3.2$ du -sh `ls`
6.9M    1
6.7M    12690
6.9M    12698
11M     16391
341M    17339
3.8G    17341
11M     17343
6.8M    19047
8.0K    pgsql_tmp

Agora, se criarmos um novo banco de dados, deverá haver mais um subdiretório em $ PGDATA / base:

-bash-3.2$ createdb foo

-bash-3.2$ ls | wc -l
10

-bash-3.2$ du -sh `ls`
6.9M    1
6.7M    12690
6.9M    12698
11M     16391
341M    17339
3.8G    17341
11M     17343
6.8M    19047
6.9M    83637
8.0K    pgsql_tmp

O que vemos ($ PGDATA / base / 83637 é o subdiretório do novo banco de dados).

A eliminação desse banco de dados também deve excluir os arquivos de dados:

-bash-3.2$ dropdb foo

-bash-3.2$ ls wc -l
9

-bash-3.2$ du -sh `ls`
6.9M    1
6.7M    12690
6.9M    12698
11M     16391
341M    17339
3.8G    17341
11M     17343
6.8M    19047
8.0K    pgsql_tmp

O que é de se esperar: o diretório $ PGDATA / base / 83637 se foi, não deve haver nada a ser aspirado.

Tem certeza de que não há mais nada ocupando seu espaço em disco? Um dos seus outros bancos de dados? arquivos de log?

Algo que você poderia tentar seria:

-bash-3.2$ cd $PGDATA
-bash-3.2$ du -sh `ls` > ../pre_sizes

faça suas várias coisas no banco de dados, crie, solte etc. e depois:

-bash-3.2$ du -sh `ls` > ../post_sizes

para ter uma idéia de onde está indo o espaço em disco.


Eu vejo os mesmos resultados que você - ou seja, quando adiciono a tabela, o novo banco de dados aparece no diretório base e, quando removo, desaparece. No entanto, esse diretório não parece conter toda a diferença no tamanho (. Ie ~ 9.6GB)
Jmoney38

@ Jmoney38 - É por isso que eu recomendo fazer o "du -sh ls" no diretório $ PGDATA antes e depois de adicionar / soltar o banco de dados, pois isso deve indicar quais outros diretórios estão crescendo rapidamente.
gsiems

@ Jmoney38 - Se eu tivesse que adivinhar, diria que a diferença está nos diretórios $ PGDATA / pg_log e / ou $ PGDATA / pg_xlog. Os arquivos de log são do cluster e não são truncados quando você solta um banco de dados.
gsiems
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.