Quel est le meilleur système de fichiers pour les performances d'insertion sur PostgreSQL?

20

Je suis curieux de savoir si quelqu'un a fait des expériences ou des comparaisons entre les systèmes de fichiers et les performances des bases de données. Sous Linux, je me demande quel est le système de fichiers optimal pour une base de données postgres. De plus, quels paramètres (inode, etc.) lui conviennent le mieux? Est-ce quelque chose qui peut différer considérablement en fonction des données de la base de données?

Si vous recherchez une question relative aux performances générales du système de fichiers / base de données, ce message contient de bonnes informations.

Cependant, je voudrais obtenir autant de conseils que possible sur les performances d' insertion par rapport aux performances de lecture. Merci pour toutes les bonnes réponses!

Elijah
la source
7
Le meilleur système de fichiers serait plus de mémoire? ;)
Oskar Duveborn
2
+1 pour Oskar. Nous venons de passer d'une configuration de serveur où la RAM représentait environ 33% de la taille totale de la base de données à une nouvelle machine où la RAM totale était supérieure à la taille de la base de données. Nous pouvons maintenant mettre en cache l'intégralité de la base de données en mémoire. Notre requête SQL la plus lente est désormais 2 fois plus rapide.
KevinRae

Réponses:

14

Achetez une copie de "postgresql high performance" de Greg Smith. C'est un excellent livre et deux chapitres ou plus concernent le matériel disque et les systèmes de fichiers. Tu apprendras beaucoup.

En bref: il n'y a pas de réponse courte.

Mais je vais essayer de résumer:

  • n'utilisez pas ext2 tant que vous ne savez pas ce que vous faites.
  • avec ext3 méfiez-vous des pointes de point de contrôle à cause des appels fsync, voir page 113 et 82 et 79
  • utiliser ext4 ou xfs
  • il y a d'autres options

Mais comme vous vous demandez vraiment quel FS utiliser, vous devriez lire le livre!

Janning
la source
4
D'accord, c'est le genre de sujet que Greg couvre très bien. Il y a un exemple de chapitre sur packtpub.com/sites/default/files/… si vous souhaitez évaluer avant d'emprunter ou d'acheter le livre.
sciurus
1
C'est drôle, quand j'avais ce problème, le livre n'existait pas. Maintenant, je suis vraiment reconnaissant pour les efforts que Greg a mis dans ce livre.
Elijah
J'ai acheté un autre exemplaire juste pour rendre hommage à ce superbe travail :-)
Janning
6

Tout d'abord, vous voulez d'abord un système de fichiers fiable et rapide une seconde. Ce qui exclut certaines options ...

Les tests de performances montrent que souvent XFS donne les meilleures performances. Il y a des problèmes de stabilité une fois que vous atteignez des scénarios de disque très proche de saturé, mais tant que vous surveillez que cela ne se produit pas, cela vous donnera des performances légèrement meilleures.

En théorie, vous n'avez pas besoin d'un système de fichiers de journalisation pour le répertoire pg_xlog, mais la différence de vitesse est généralement si petite qu'elle n'en vaut pas la peine. Pour le répertoire de données, vous devriez toujours avoir un système de fichiers de journalisation des métadonnées.

Magnus Hagander
la source
4
Vous voudrez peut-être / ne pas / utiliser XFS pour stocker une base de données, notamment parce qu'il (si nécessaire) mettra à zéro les blocs qu'il ne peut pas récupérer.
Avery Payne
4

Les systèmes de gestion de base de données implémentent leur propre journalisation via les journaux de base de données, donc l'installation d'un tel SGBD sur un système de fichiers journalisé dégrade les performances via deux mécanismes:

  1. La journalisation redondante augmente la quantité d'activité du disque

  2. La disposition du disque physique peut être fragmentée (bien que certains systèmes de fichiers de journalisation aient des mécanismes pour nettoyer cela).

  3. De nombreuses activités sur le disque peuvent remplir le journal, provoquant de fausses conditions de «disque plein».

Il y a quelques années, j'ai vu une instance où cela a été fait sur le système de fichiers LFS sur une installation Baan sur une boîte HP / UX. Le système avait des problèmes persistants de performances et de corruption de données qui n'ont pas été diagnostiqués jusqu'à ce que quelqu'un comprenne que les systèmes de fichiers étaient formatés avec LFS.

Les volumes contenant des fichiers de base de données auront normalement un petit nombre de fichiers volumineux. Les serveurs SGBD auront normalement un paramètre qui configure le nombre de blocs lus dans une seule E / S. Des nombres plus petits seraient appropriés pour les systèmes de traitement de transactions à volume élevé car ils minimiseraient la mise en cache des données redondantes. De plus grands nombres seraient appropriés pour des systèmes tels que les entrepôts de données qui effectuaient beaucoup de lectures séquentielles. Si possible, réglez la taille du bloc d'allocation de votre système de fichiers pour qu'elle soit identique à la lecture multi-bloc sur laquelle le SGBD est défini.

Certains systèmes de gestion de base de données peuvent fonctionner sur des partitions de disque brutes. Cela donne divers degrés de gain de performances, généralement moins sur un système moderne avec beaucoup de mémoire. Sur les systèmes plus anciens disposant de moins d'espace pour mettre en cache les métadonnées du système de fichiers, les économies d'E / S disque étaient assez importantes. Les partitions brutes rendent le système plus difficile à gérer, mais offrent les meilleures performances disponibles.

Les volumes RAID-5 entraînent plus de surcharge d'écriture que les volumes RAID-10, donc une base de données occupée avec beaucoup de trafic d'écriture fonctionnera mieux (souvent beaucoup mieux) sur un RAID-10. Les journaux doivent être placés des volumes de disque physiquement séparés dans les données. Si votre base de données est volumineuse et principalement en lecture seule (par exemple, un entrepôt de données), il peut être judicieux de la placer sur des volumes RAID-5 si cela ne ralentit pas indûment le processus de chargement.

La mise en cache en écriture différée sur un contrôleur peut vous permettre de gagner en performances au détriment de la création de certains modes de défaillance (raisonnablement improbables mais possibles) où les données pourraient être corrompues. La plus grande victoire en termes de performances est liée aux charges d'accès hautement aléatoires. Si vous souhaitez le faire, envisagez de placer les journaux sur un contrôleur distinct et de désactiver la mise en cache en écriture différée sur les volumes de journaux. Les journaux auront alors une meilleure intégrité des données et une seule défaillance ne peut pas supprimer à la fois le volume du journal et des données. Cela vous permet de restaurer à partir d'une sauvegarde et d'effectuer une restauration à partir des journaux.

ConcernedOfTunbridgeWells
la source
La journalisation des données dégrade les performances; les métadonnées de journalisation devraient au pire avoir un impact minimal, et très probablement presque aucun. Il n'est pas conseillé de ne pas journaliser les métadonnées.
niXar
Je pense que vous avez mal compris l'article. Tout système de fichiers contient des métadonnées de système de fichiers et tout trafic sur disque impliquera de les lire ou de les écrire. Les ordinateurs modernes ont généralement suffisamment de RAM pour mettre en cache facilement les métadonnées de ce système de fichiers, mais pas les machines plus anciennes. Cela signifiait que les accès au disque entraînaient des frais d'E / S supplémentaires importants (le chiffre souvent cité pour Oracle était un gain de performances de 30% sur les partitions brutes) pour la lecture ou la mise à jour des métadonnées du système de fichiers. Sur un système moderne avec plus de RAM, les métadonnées du système de fichiers sont plus susceptibles d'être mises en cache, donc la surcharge est plus faible.
ConcernedOfTunbridgeWells
Cela contient de bons conseils généraux, mais j'ai rétrogradé car il contient également des informations non pertinentes ou incorrectes pour les systèmes de fichiers journalisés postgresql et modernes.
sciurus
3

J'ai fait un rapport si détaillé, mais ce n'est qu'en français . Si vous lisez le français ou êtes satisfait des outils de traduction automatique ... Vous pouvez réutiliser la méthodologie et l'exécuter par vous-même.

Résumé: j'ai utilisé pgbench. Le planificateur d'E / S Linux a très peu d'importance pour les performances et le système de fichiers seulement un peu. Donc, si vous êtes pressé, choisissez simplement la valeur par défaut. J'ai choisi JFS.

bortzmeyer
la source
2

Le système de fichiers n'est qu'une partie du problème. Vous pouvez améliorer considérablement les performances en modifiant votre planificateur d'E / S. Heureusement, cela est assez facile à tester car vous pouvez changer le planificateur d'E / S à la volée. Je suggère d'essayer chacun d'eux pendant quelques jours sous une charge typique et de voir ce qui donne les meilleures performances.

David Pashley
la source
Mes repères ont montré très peu de changement lors du changement du planificateur d'E / S, probablement parce que chaque SGBD a déjà son propre planificateur.
bortzmeyer
MySQL se débrouille beaucoup mieux sous une charge élevée en utilisant le planificateur de délais.
David Pashley
2

J'ai fait quelques tests il y a quelques mois:

J'ai eu un petit programme de test qui a créé 50 threads, où chaque thread a inséré 1000 (ou si c'était 10000) lignes dans la même table.

  • Avec la base de données sur EXT3 et un RAID5 à 4 disques, cela a pris 50 secondes.
  • Avec la table sur le disque virtuel (en utilisant l'espace disque logique), cela a quand même pris 50 secondes. La raison pour laquelle cela n'a pas été plus rapide est que tout est enregistré dans le répertoire pg_xlog qui se trouvait toujours sur le même RAID 5.
  • J'ai déplacé le pg_xlog vers un RAID0 4 disques (stripe) et le même programme exécuté en 40 secondes.
  • À des fins de test, j'ai déplacé le pg_xlog vers le ramdisk et j'avais tout le reste sur le disque RAID EXT3 4. Le programme s'est terminé après moins de 5 secondes.

Mais avoir pg___xlog sur un disque virtuel logiciel n'est pas une option: si vous perdez le contenu du répertoire pg_xlog, postgres ne démarrera pas. (Mais il existe des disques virtuels matériels avec batterie de secours qui pourraient être intéressants.)

À mon humble avis: Utilisez le système de fichiers avec lequel vous êtes le plus à l'aise pour les fichiers de base de données. Déplacez le pg_xlog (avec un lien symbolique, voir la documentation) vers le périphérique le plus rapide possible dont vous disposez.

certains
la source
1
pgbench fait quelque chose de similaire et est inclus avec la plupart des installations.
Avery Payne
0

J'ai vu que je me suis souvenu qu'un FreeBSD modifié vous donnera un peu plus de performances par rapport à d'autres OS. Bien que je sois sûr que cette information est obsolète et probablement un mythe en premier lieu. Mais vous pouvez néanmoins l'essayer, consultez cette directive pour les paramètres du noyau: http://developer.postgresql.org/pgdocs/postgres/kernel-resources.html

Martin P. Hellwig
la source