Question

Mes cibles question Postgres, mais des réponses peut-être juste assez bon venant de tous les milieux de base de données.

sont mes hypothèses correctes:

  • Les disques ont une taille de bloc fixe?
  • contrôleur RAID peut avoir une taille de bloc differnt? Est-ce un bloc RAID get divisé sur plusieurs blocs de disque réel?
  • Le système de fichiers a également une taille de bloc indépendant qui obtient à nouveau divisé sur la taille du bloc RAID?
  • Postgres fonctionne avec fixes 8k blocs. Comment la mise en correspondance de la taille du bloc du système de fichiers se produire ici? Postgres sont 8k blocs par le traitement par lots de système de fichiers?

Lors de la mise en place d'un système est-il préférable d'avoir tous les blocs à 8k? Ou les réglages pas réel problème? Je me demandais aussi si certains paramètres de taille de bloc « mauvais » pourraient mettre en danger l'intégrité des données en cas d'accident? Peut-être que si un bloc Postgres 8k doit être divisé sur plusieurs blocs de disque?

Ou ne soit rien traitement par lots de, et donc je lâche l'espace disque avec chaque décalage entre les tailles de blocs définies?

Était-ce utile?

La solution

Secteurs disque

Un disque a une taille de secteur fixe, normalement 512 octets ou 4096 octets sur certains disques modernes; ces disques auront également un mode où ils émulent secteurs de 512 octets. Le disque aura des pistes avec un nombre variable de secteurs; pistes plus étroites à l'extérieur du disque ont plus de secteurs car ils ont plus d'espace pour une densité de bits donnée. Cela permet une utilisation plus efficace de l'espace disque; généralement une piste aura quelque chose comme 1.000 secteurs de 512 octets sur un disque moderne.

Certaines structures de mise en forme peut également comprendre des informations de correction d'erreurs dans les secotrs, qui se manifeste dans les disques étant formatage de bas niveau avec 520 ou 528 octets par secteur. Dans ce cas, le secteur a encore 512 octets de données utilisateur. Ni de Windows ni Linux prennent en charge directement, bien que i5OS (IBM iSeries) et divers contrôleurs SAN font.

Normalement, le secteur / tête / piste est traduite en une adresse de bloc logique; en raison de problèmes historiques avec rétrocompatibilité la géométrie (têtes x secteurs x pistes) vu par le système d'exploitation (en particulier sur les disques IDE et SATA) a normalement peu à voir avec sa structure physique.

bande RAID Taille

Un contrôleur RAID peut avoir une taille de bande d'un réseau utilisant l'entrelacement (par exemple RAID-5 ou RAID-10). Si le tableau a (pour exmaple) une bande de 128k, chaque disque a 128k de données contiguës, puis la prochaine série de données est sur le disque suivant. Normalement, vous pouvez vous attendre à obtenir environ une bande par tour du disque, de sorte que la taille de la bande peut affecter les performances sur certaines charges de travail.

Alignement Partition

Une partition de disque peut aligner ou non exactement avec une bande RAID, et peut causer une dégradation des performances en raison de lectures partielles si elle n'est pas aligné. Certains systèmes (par exemple serveur Windows 2008) seront les partitions configure automatiquement pour aligner les tailles de bande de volume de disque. Certains (par exemple serveur Windows 2003) ne sera pas, et vous devez utiliser un utilitaire de partition qui prend en charge l'alignement de bande pour assurer qu'ils font.

système de fichiers Taille du bloc

Le système de fichiers attribuera des blocs de stockage en morceaux d'une certaine taille. En général, cela est configurable - par exemple NTFS soutiendra les unités d'allocation de (IIRC) 4 à 64 K. Désalignement des partitions et des blocs de système de fichiers à bandes RAID peut provoquer un seul bloc de système de fichiers lecture pour générer plusieurs accès au disque où une seule serait nécessaire si les blocs du système de fichiers correctement alignés avec les bandes RAID.

Base de données Taille du bloc

La base de données allouer de l'espace dans une table ou un index dans une taille de bloc donné. Dans le cas de SQL Server est ce 8K et 8K est la valeur par défaut sur de nombreux systèmes. Sur certains systèmes tels que Oracle, il est configurable, et PostgreSQL est une option à la compilation. Sur la plupart des systèmes allocation d'espace aux tables est normalement fait en gros morceaux, avec des blocs alloués dans ces morceaux.

désalignement des blocs allocation système de fichiers et de données peut générer multiple E / S pour une écriture de bloc unique, ce qui peut entraîner une perte de performance.

E / S Chunking

Normalement, un SGBD fait faire son E / S en morceaux de plus d'un bloc. Par exemple, sur SQL Server, toutes les E / S est fait en morceaux de 8 blocs, 64k au total). Sur Oracle il est configurable. inspection occasionnelle des documents PostgreSQL ne révèle pas une description précise de savoir si PostgreSQL fait cela, donc je ne sais pas comment cela fonctionne sur cette plate-forme.

Quand le E / S morceau plus grand que la taille du bloc du système de fichiers ou est mal aligné avec les limites de bande RAID une écriture sur le disque de la base de données peut provoquer des écritures de disques multiples, qui génère une pénalité de performance.

utilisation de l'espace disque

Pas d'espace disque est perdu - la base de données E / S utilisera une ou plusieurs opérations d'E / S physique sur le disque complet - mais incorrectly E / S réglé peut générer des inefficacités qui ralentissent la base de données. Les principales choses qui doivent être alignés sont:

  • bandes RAID et les partitions -. La partition doit commencer sur une limite de bande RAID

  • Filesystem allocation d'E / S et une bande de raid / limites de partition -. Un must limite bande RAID align avec une unité d'allocation de système de fichiers, et doit être un multiple de la taille de l'unité d'allocation de système de fichiers

  • Taille d'écriture du disque et la taille de l'unité d'allocation du système de fichiers. Il devrait y avoir 1: 1. Relation entre les opérations d'E / S et la base de données du système de fichiers opérations E / S

désalignement ne crée pas un plus grand problème de l'intégrité des données que fréquenteraient autrement. La base de données et système de fichiers ont des mécanismes en place pour assurer opearations du système de fichiers sont atomiques. En général, un crash de disque entraînera la perte de données, mais pas de problèmes d'intégrité des données.

Licencié sous: CC-BY-SA avec attribution
Non affilié à dba.stackexchange
scroll top