Liberando espacio en disco después de la caída de la base de datos

12

Estoy trabajando en un sistema de desarrollo, y he estado restaurando una base de datos, digamos "foo", que estoy usando para propósitos de desarrollo. Mientras trabajo a través de los problemas, acabo de ejecutar DROP DATABASE foo. Sin embargo, rápidamente me di cuenta de que ocupaba todo el espacio en mi disco. Mierda.

¿VACUUM FULL, desde una base de datos lógica diferente, libera espacio de la base de datos que eliminé anteriormente (foo)? Intenté esto desde una base de datos lógica diferente, y se recuperó el espacio libre, pero no creo que sea suficiente para dar cuenta de todas las llamadas CREATE DATABASE / DROP DATABASE que hice. Es posible que haya VACUUM 'la base de datos lógica que ejecuté.

Debe haber una manera de reclamar ese espacio sin hacer un inicio total de la base de datos?

EDITAR

Así que reinicialicé la base de datos desde una copia de seguridad, siguiendo aproximadamente estos pasos . ¡Después de la restauración, recuperé una TONELADA de espacio en el disco! Esto funciona por ahora, pero cualquier ayuda con respecto a cómo limpiar una base de datos descartada aún sería útil.

EDITAR 2

Así que me las arreglé para recopilar más información sobre este problema ... Esto es lo que he encontrado como ejemplo:

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

Entonces, me parece que el nuevo DB tomó ~ 9.6 GB en el disco. Sin embargo, después de soltarlo, el espacio en disco recuperado solo creció ~ 4.6G. Entonces, ¿hay aproximadamente 5 GB de espacio que me hacen preguntarme qué está pasando?

Y continúa este ciclo cuando vuelvo a crear, poblar y soltar.

¿Alguien tiene alguna idea de lo que persiste después de emitir un comando "DROP DATABASE"?

postgresql disk-space Jmoney38
fuente
Tal vez también valga la pena señalar que tengo el archivo activado. Parece que la ubicación en la que se escriben los archivos WAL es bastante grande. No lo he estado monitoreando de cerca. Tal vez intente el mismo procedimiento mencionado anteriormente y ejecute un "du" en ese directorio para ver si se recupera todo el espacio. Informaré de nuevo.
Jmoney38
¿Asumo que el vacío no ayuda entonces?
rogerdpack

Respuestas:

6

Pruebe sudo lsof| grep deletedy verifique si aparece algún proceso de PostgreSQL. Este comando busca archivos que han sido eliminados pero sus descriptores de archivo aún están abiertos por cualquier proceso. Otro efecto secundario es eso df -hy du -sh /difiere. Esto se debe a que dumira el sistema de archivos y resume el tamaño de todos los archivos, y dfmira el dispositivo físico.

Acabo de tener un problema con una base de datos que no liberó espacio después de una DROP tabley esa fue la causa.

La única solución que conozco es reiniciar la base de datos. Quizás pueda intentar enviar una recarga (SIGHUP).

charli
fuente
2
La lsof | grep deletedpropina fue buena; a eso, agregue que solo necesita determinar qué sesiones de postgresql siguen activas y elimínelas para liberar los archivos. En mi caso, de más de 500 conexiones activas, casi todas en IDLE o COMMIT, matar una sola, encontrada SELECT * FROM pg_stat_activityy atrapada en un ANALYZE, fue suficiente para liberar los archivos eliminados. ! 00 GB liberados.
Alex North-Keys el
5

Tengo entendido que cuando sueltas una base de datos, entonces, y sus archivos, desaparecen.

A menos que esté utilizando espacios de tabla, cada base de datos debe tener sus datos en su propio subdirectorio bajo $ PGDATA / base. Usando uno de mis servidores como ejemplo (como usuario de 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

Ahora, si creamos una nueva base de datos, entonces debería haber un subdirectorio más bajo $ 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

Que es lo que vemos ($ PGDATA / base / 83637 es el subdirectorio para la nueva base de datos).

Eliminar esa base de datos también debería eliminar los archivos de datos:

-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

Que es lo que esperaríamos: el directorio $ PGDATA / base / 83637 se ha ido, no debería haber nada para aspirar.

¿Estás seguro de que no hay nada más que esté consumiendo tu espacio en disco? ¿Una de tus otras bases de datos? ¿archivos de registro?

Algo que podría intentar sería:

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

hacer varias cosas de la base de datos, crear, soltar, etc. y luego:

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

para tener una idea de hacia dónde va el espacio en disco.

gsiems
fuente
Veo los mismos resultados que usted, es decir, cuando agrego la tabla, el nuevo DB aparece en el directorio base, y cuando lo elimino, desaparece. Sin embargo, ese directorio no parece comprender toda la diferencia de tamaño (es decir, ~ 9.6GB)
Jmoney38
@ Jmoney38 - Es por eso que recomendé hacer el "du -sh ls" en el directorio $ PGDATA antes y después de agregar / soltar la base de datos, ya que eso debería indicar qué otros directorios están creciendo a pasos agigantados.
gsiems
@ Jmoney38: si tuviera que adivinar, diría que la diferencia se encuentra en los directorios $ PGDATA / pg_log y / o $ PGDATA / pg_xlog. Los archivos de registro son para el clúster y no se truncan cuando suelta una base de datos.
gsiems