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

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!

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!

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.

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.

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.

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.

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.

He visto que he recordado que un FreeBSD ajustado le dará un poco más de rendimiento en comparación con otros sistemas operativos. Aunque estoy seguro de que esta información está desactualizada y probablemente sea un mito en primer lugar. Sin embargo, puede probarlo, consulte esta guía para la configuración del kernel: http://developer.postgresql.org/pgdocs/postgres/kernel-resources.html