¿Cuál es el mejor sistema de archivos para el rendimiento de inserción en PostgreSQL?


20

Tengo curiosidad por saber si alguien ha hecho alguna experimentación o comparación entre los sistemas de archivos y el rendimiento de la base de datos. En Linux, me pregunto cuál es el sistema de archivos óptimo para una base de datos postgres. Además, ¿qué ajustes (inodo, etc.) son ideales para ello? ¿Es esto algo que puede diferir drásticamente en función de los datos en la base de datos?

Si está buscando una pregunta relacionada con el rendimiento general del sistema de archivos / base de datos, esta publicación tiene buena información.

Sin embargo, me gustaría obtener tantos consejos sobre el rendimiento de inserción como sea posible frente al rendimiento de lectura. ¡Gracias por todas las excelentes respuestas!


77
¿El mejor sistema de archivos sería más memoria? ;)
Oskar Duveborn

2
+1 para Oskar. Acabamos de pasar de una configuración de servidor donde la RAM era ~ 33% del tamaño total de la base de datos a una nueva máquina donde la RAM total era mayor que el tamaño de la base de datos. Ahora podemos almacenar en caché todo el DB en la memoria. Nuestra consulta SQL más lenta ahora es 2 órdenes de magnitud más rápida.
KevinRae

Respuestas:


14

Compre una copia de "postgresql high performance" de Greg Smith. Es un gran libro y dos o más capítulos tratan sobre hardware de disco y sistemas de archivos. Aprenderás mucho

En resumen: no hay una respuesta corta.

Pero intentaré veranear:

  • no use ext2 hasta que sepa lo que está haciendo.
  • con ext3 tenga cuidado con los picos de puntos de control debido a llamadas fsync, consulte las páginas 113 y 82 y 79
  • usar ext4 o xfs
  • hay otras opciones

Pero como realmente te estás preguntando qué FS usar, ¡deberías leer el libro!


44
De acuerdo, este es el tipo de tema que Greg cubre muy bien. Hay un capítulo de muestra en packtpub.com/sites/default/files/… si desea evaluar antes de pedir prestado o comprar el libro.
sciurus

1
Es curioso, cuando tenía este problema, el libro no existía. Ahora, estoy realmente agradecido por el esfuerzo que Greg puso en ese libro.
Elijah

Compré otra copia solo para honrar este gran trabajo :-)
Janning

6

En primer lugar, primero desea un sistema de archivos confiable y un segundo rápido. Lo que descarta algunas opciones ...

Las pruebas de rendimiento muestran que a menudo XFS ofrece el mejor rendimiento. Hay algunos problemas de estabilidad con él una vez que alcanza escenarios de disco muy cerca de estar lleno, pero siempre que supervise que eso no suceda, le brindará un rendimiento ligeramente mejor.

En teoría, no necesita un sistema de archivos de registro en diario para el directorio pg_xlog, pero la diferencia de velocidad suele ser tan pequeña que simplemente no vale la pena. Para el directorio de datos, siempre debe tener un sistema de archivos de registro de metadatos.


44
Es posible que desee / no / usar XFS para almacenar una base de datos, es decir, porque (cuando sea necesario) cero bloques que no puede recuperar.
Avery Payne

4

Los sistemas de gestión de bases de datos implementan su propio diario a través de los registros de la base de datos, por lo que la instalación de tal DBMS en un sistema de archivos con diario degrada el rendimiento a través de dos mecanismos:

  1. El registro redundante aumenta la cantidad de actividad del disco

  2. El diseño del disco físico puede fragmentarse (aunque algunos sistemas de archivos de diario tienen mecanismos para limpiar esto).

  3. Mucha actividad de disco puede llenar el diario, causando condiciones espurias de "disco lleno".

Hace unos años, vi una instancia en la que esto se hizo en el sistema de archivos LFS en una instalación de Baan en una caja HP ​​/ UX. El sistema tenía problemas persistentes de rendimiento y corrupción de datos que no se diagnosticaron hasta que alguien descubrió que los sistemas de archivos estaban formateados con LFS.

Los volúmenes que contienen archivos de base de datos normalmente tendrán una pequeña cantidad de archivos grandes. Los servidores DBMS normalmente tendrán una configuración que configura cuántos bloques se leen en una sola E / S. Los números más pequeños serían apropiados para sistemas de procesamiento de transacciones de alto volumen, ya que minimizarían el almacenamiento en caché de datos redundantes. Los números más grandes serían apropiados para sistemas como almacenes de datos que hicieron muchas lecturas secuenciales. Si es posible, ajuste el tamaño del bloque de asignación del sistema de archivos para que sea del mismo tamaño que la lectura de bloques múltiples en la que está configurado el DBMS.

Algunos sistemas de administración de bases de datos pueden funcionar con particiones de disco sin procesar. Esto proporciona diversos grados de ganancia de rendimiento, generalmente menos en un sistema moderno con mucha memoria. En sistemas más antiguos con menos espacio para almacenar en caché los metadatos del sistema de archivos, los ahorros en disco de E / S fueron bastante significativos. Las particiones sin formato hacen que el sistema sea más difícil de administrar, pero proporcionan el mejor rendimiento disponible.

Los volúmenes RAID-5 generan más gastos generales de escritura que los volúmenes RAID-10, por lo que una base de datos ocupada con mucho tráfico de escritura funcionará mejor (a menudo mucho mejor) en un RAID-10. Los registros deben colocarse volúmenes de disco físicamente separados en los datos. Si su base de datos es grande y en su mayoría es de solo lectura (por ejemplo, un almacén de datos), puede haber un caso para colocarla en volúmenes RAID-5 si esto no ralentiza indebidamente el proceso de carga.

El almacenamiento en caché de reescritura en un controlador puede brindarle una ganancia de rendimiento a expensas de crear algunos modos de falla (razonablemente improbables pero posibles) donde los datos podrían corromperse. La mayor ganancia de rendimiento para esto es en cargas de acceso altamente aleatorio. Si desea hacer esto, considere colocar los registros en un controlador separado y deshabilitar el almacenamiento en caché de reescritura en los volúmenes de registro. Los registros tendrán una mejor integridad de datos y una sola falla no puede eliminar tanto el volumen de registro como el de datos. Esto le permite restaurar desde una copia de seguridad y avanzar desde los registros.


El registro de datos degrada el rendimiento; los metadatos diarios deberían tener, en el peor de los casos, un impacto mínimo y, muy probablemente, casi ninguno. No registrar metadatos no es aconsejable.
niXar

Creo que entendiste mal el artículo. Cualquier sistema de archivos tiene metadatos del sistema de archivos y cualquier tráfico de disco implicará leer o escribir esto. Las computadoras modernas generalmente tienen suficiente RAM para almacenar en caché fácilmente los metadatos de este sistema de archivos, pero las máquinas más antiguas no. Esto significó que los accesos al disco incurrieron en una sobrecarga de E / S adicional significativa (la cifra citada con frecuencia para Oracle fue un impacto de rendimiento del 30% sobre las particiones sin formato) para leer o actualizar los metadatos del sistema de archivos. En un sistema moderno con más RAM, es más probable que los metadatos del sistema de archivos se almacenen en caché, por lo que la sobrecarga es menor.
ConcernedOfTunbridgeWells

Esto contiene algunos buenos consejos generales, pero rechacé porque también contiene información que es irrelevante o incorrecta para los sistemas de archivos de postgresql y modernos.
sciurus

3

Hice un informe tan detallado pero solo está en francés . Si lees francés o estás contento con las herramientas de traducción automática ... Puedes reutilizar la metodología y ejecutarla por ti mismo.

Resumen ejecutivo: utilicé pgbench. El planificador de E / S de Linux tiene muy poca importancia para las actuaciones y el sistema de archivos solo un poco. Entonces, si tiene prisa, simplemente elija el valor predeterminado. Elegí JFS.


2

El sistema de archivos es solo una parte del problema. Puede obtener un aumento significativo del rendimiento cambiando su planificador de IO. Afortunadamente, esto es bastante fácil de probar, ya que puede cambiar el planificador de IO sobre la marcha. Sugeriría probar cada uno durante un par de días bajo una carga típica y ver cuál ofrece el mejor rendimiento.


Mis puntos de referencia mostraron muy pocos cambios al cambiar el planificador de E / S, probablemente porque cada DBMS ya tiene su propio planificador.
bortzmeyer

MySQL se las arregla mucho mejor bajo una gran carga al usar el programador de fecha límite.
David Pashley

2

Hice algunas pruebas hace unos meses:

Tenía un pequeño programa de prueba que creaba 50 hilos, donde cada hilo insertaba 1000 (o si era 10000) filas en la misma tabla.

  • Con la base de datos en EXT3 y un RAID5 de 4 discos, tardó 50 segundos.
  • Con la tabla en ramdisk (usando tablespace) todavía tardó 50 segundos. La razón por la que no fue más rápido es que todo está registrado en el directorio pg_xlog que todavía estaba en el mismo RAID 5.
  • Moví el pg_xlog a un RAID0 de 4 discos (stripe) y el mismo programa se ejecutó en 40 segundos.
  • Con fines de prueba, moví el pg_xlog al ramdisk y tenía todo lo demás en el disco RAID EXT3 4. El programa finalizó después de menos de 5 segundos.

Pero tener el pg___xlog en un disco RAM de software no es una opción: si pierde el contenido del directorio pg_xlog, postgres no se iniciará. (Pero existen discos de hardware con respaldo de batería que pueden ser de interés).

En mi humilde opinión: Utilice el sistema de archivos con el que se sienta más cómodo para los archivos de la base de datos. Mueva el pg_xlog (con un enlace simbólico, consulte la documentación) al dispositivo más rápido posible que tenga.


1
pgbench hace algo similar y se incluye con la mayoría de las instalaciones.
Avery Payne

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.