¿Cuál es el mejor sistema de archivos para el rendimiento de las inserciones en PostgreSQL?

Compre una copia de "postgresql high performance" por Greg Smith. Es un gran libro y dos o más capítulos son sobre el hardware del disco y los sistemas de archivos. Usted aprenderá mucho.

En resumen: no hay una respuesta corta.

Pero intentaré veranear:

• no uses ext2 hasta que sepas lo que estás haciendo.
• con ext3 tenga cuidado con los picos de puntos de control debido a las llamadas fsync, vea la página 113 y 82 y 79
• utilizar ext4 o xfs
• hay otras opciones

Pero como realmente te estás preguntando que FS usar, deberías leer el libro.

En primer lugar, quieres un sistema de archivos fiable en primer lugar, y uno rápido en segundo lugar. 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 se llega a escenarios de disco muy cerca de estar lleno, pero siempre que se controle que eso no ocurra, le dará un rendimiento ligeramente mejor.

En teoría no se 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 no merece la pena. Para el directorio de datos, siempre debería tener un sistema de archivos de metadatos con registro en el diario.

Los sistemas de gestión de bases de datos implementan su propio journalling a través de los logs de la base de datos, por lo que instalar un DBMS de este tipo en un sistema de archivos journalled degrada el rendimiento a través de dos mecanismos:

1. El diario redundante aumenta la actividad del disco

2. La disposición del disco físico puede estar fragmentada (aunque algunos sistemas de archivos de registro tienen mecanismos para limpiar esto).

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

He visto un caso hace algunos años en el que esto se hizo en el sistema de archivos LFS en una instalación 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 bases de datos normalmente tendrán un pequeño número de archivos grandes. Los servidores de DBMS normalmente tendrán un ajuste que configura cuántos bloques se leen en una sola E/S. Los números más pequeños serían apropiados para los sistemas de procesamiento de transacciones de alto volumen, ya que minimizarían el almacenamiento en caché de los datos redundantes. Los números más grandes serían apropiados para sistemas como los almacenes de datos que hacen muchas lecturas secuenciales. Si es posible, ajuste el tamaño del bloque de asignación de su sistema de archivos para que sea del mismo tamaño que la lectura multi-bloque que el SGBD está configurado.

Algunos sistemas de gestión de bases de datos pueden trabajar con particiones de disco en bruto. Esto proporciona diversos grados de mejora del rendimiento, normalmente menos en un sistema moderno con mucha memoria. En los sistemas más antiguos, con menos espacio para almacenar en caché los metadatos del sistema de archivos, el ahorro en la E/S del disco era bastante significativo. Las particiones en bruto hacen que el sistema sea más difícil de gestionar, pero proporcionan el mejor rendimiento disponible.

Los volúmenes RAID-5 incurren en más sobrecarga 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 deberían colocarse en volúmenes de disco físicamente separados de los datos. Si tu base de datos es grande y en su mayoría de sólo lectura (por ejemplo, un almacén de datos) puede haber un caso para ponerla en volúmenes RAID-5 si esto no ralentiza excesivamente el proceso de carga.

El almacenamiento en caché de escritura en un controlador puede ofrecer una ganancia de rendimiento a costa de crear algunos modos de fallo (razonablemente improbables pero posibles) en los que los datos podrían corromperse. La mayor ganancia de rendimiento se da en las cargas de acceso altamente aleatorio. Si quieres hacer esto, considera poner los registros en un controlador separado y deshabilitar el almacenamiento en caché de escritura en los volúmenes de registro. Los registros tendrán entonces una mejor integridad de los datos y un único fallo no podrá acabar con los volúmenes de registro y de datos. Esto le permite restaurar a partir de una copia de seguridad y avanzar a partir de los registros.

Hice un informe tan detallado pero es sólo 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: He utilizado pgbench. El programador de E/S de Linux tiene muy poca importancia para el rendimiento y el sistema de archivos sólo un poco. Así que, si tienes prisa, elige el que viene por defecto. Yo elegí JFS.

El sistema de archivos es sólo una parte del problema. Puedes conseguir un aumento significativo del rendimiento cambiando tu programador de E/S. Afortunadamente esto es bastante fácil de probar ya que puedes cambiar el programador de IO sobre la marcha. Yo sugeriría probar cada uno durante un par de días bajo una carga típica y ver cuál da el mejor rendimiento.