¿Por qué PostgreSQL está consumiendo todo mi precioso espacio en HD?

Question

Acabo de terminar de transferir todos los datos de la estructura de enlaces relacionados con wikipedia (inglés) que pude. Básicamente, descargué un montón de volcados de SQL del último repositorio de volcados de wikipedia. Como estoy usando PostgreSQL en lugar de MySQL, decidí cargar todos estos volcados en mi base de datos usando shell de la tubería comandos .

De todos modos, una de estas tablas tiene 295 millones de filas: la tabla pagelinks ; contiene todos los hipervínculos intra-wiki. Desde mi computadora portátil, utilizando pgAdmin III, envié el siguiente comando a mi servidor de base de datos (otra computadora):

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

Ha estado en ello durante una hora más o menos ahora. La cosa es que el postmaster parece estar consumiendo más y más de mi muy limitado espacio en HD. Creo que comió unos 20 GB a partir de ahora. Anteriormente había jugado con el archivo postgresql.conf para darle más flexibilidad de rendimiento (es decir, dejar que use más recursos) ya que se ejecuta con 12 GB de RAM. Creo que básicamente cuadruplicé la mayoría de los bytes y las variables relacionadas de este archivo pensando que usaría más RAM para hacer su trabajo.

Sin embargo, la base de datos no parece utilizar mucha RAM. Al usar el monitor del sistema Linux, puedo ver que el administrador de correo usa 1.6 GB de memoria compartida (RAM). De todos modos, me preguntaba si ustedes podrían ayudarme a comprender mejor lo que está haciendo porque parece que realmente no entiendo cómo PostgreSQL usa los recursos HD .

En cuanto a la metaestructura de las bases de datos de Wikipedia, proporcionan un buen esquema que puede ser de uso o incluso pero de interés para usted.

No dude en pedirme más detalles, gracias.

Answer 1

Probablemente es el GRUPO POR el que está causando el problema. Para hacer la agrupación, la base de datos tiene que ordenar las filas para juntar los elementos duplicados. Un índice probablemente no ayude. Un cálculo de la parte posterior del sobre: ??

Suponiendo que cada fila ocupa 100 bytes de espacio, eso es 29,500,000,000 bytes, o aproximadamente 30GB de almacenamiento. No puede caber todo eso en la memoria, por lo que su sistema se está agitando, lo que ralentiza las operaciones en un factor de 1000 o más. Es posible que su espacio en el disco duro esté desapareciendo en el espacio de intercambio, si está utilizando archivos de intercambio.

Si solo necesita realizar este cálculo una vez, intente dividirlo en subconjuntos más pequeños de los datos. Suponiendo que pl_namespace es numérico y oscila entre 1-295 millones, intente algo como esto:

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

Luego haga lo mismo para 50000001-100000000 y así sucesivamente. Combine sus respuestas usando UNION o simplemente tabule los resultados con un programa externo. Olvida lo que escribí sobre un índice que no ayuda a GROUP BY; Aquí, un índice ayudará a la cláusula WHERE.

Answer 2

¿Qué exactamente afirma que solo toma 9.5MB de RAM? Eso me parece poco probable: la memoria compartida casi con toda seguridad es RAM, que se comparte entre diferentes procesos de Postgres. (De lo que recuerdo, cada cliente termina como un proceso separado, aunque ha pasado un tiempo así que podría estar muy equivocado).

¿Tiene un índice en la columna pl_namespace ? Si hay una gran cantidad de resultados distintos, podría imaginar que la consulta es bastante pesada en una tabla de 295 millones de filas sin índice. Habiendo dicho eso, 10GB es una gran cantidad para tragar. ¿Sabes en qué archivos está escribiendo?

Answer 3

Ok, así que aquí está lo esencial:

la cláusula GROUP BY hizo que el índice fuera inválido, por lo que el postmaster (proceso del servidor postgresql) decidió crear un grupo de tablas (23GB de tablas) que estaban ubicadas en el directorio $ PGDATA / base / 16384 / pgsql_tmp.

Al modificar el archivo postgresql.conf, había dado permiso para que postgreSQL usara 1.6 GB de RAM (que ahora duplicaré porque tiene acceso a 11.7 GB de RAM); el proceso de postmaster estaba usando 1.6 GB de RAM, pero eso no fue suficiente, por lo tanto, el directorio pgsql_tmp.

Como lo señaló Barry Brown, ya que solo estaba ejecutando este comando SQL para obtener información estadística sobre la distribución de los enlaces entre pagelinks.namespaces , podría haber consultado un subconjunto de los 296 millones de enlaces de página (esto es lo que hacen para las encuestas).

Cuando el comando devolvió el conjunto de resultados, todas las tablas temporales se eliminaron automáticamente como si nada hubiera pasado.

Gracias por su ayuda, chicos!