Comprendre la taille des blocs

11

Ma question s'adresse à Postgres, mais les réponses peuvent être suffisantes venant de n'importe quel arrière-plan de base de données.

Mes hypothèses sont-elles correctes:

  • Les disques ont une taille de bloc fixe?
  • Le contrôleur RAID peut avoir une taille de bloc différente? Un bloc RAID est-il divisé en plusieurs blocs de disque réels?
  • Le système de fichiers a également une taille de bloc indépendante qui est à nouveau divisée en taille de bloc RAID?
  • Postgres fonctionne avec des blocs fixes de 8k. Comment le mappage à la taille de bloc du système de fichiers se produit-il ici? Les blocs Postgres 8k sont-ils groupés par le système de fichiers?

Lors de la configuration d'un système, est-il préférable d'avoir tous les blocs à 8k? Ou les paramètres ne sont-ils pas vraiment importants? Je me demandais également si certains "mauvais" paramètres de taille de bloc pouvaient mettre en danger l'intégrité des données en cas de crash? Peut-être si un bloc Postgres 8k doit être divisé en plusieurs blocs de disque?

Ou rien n'est-il regroupé, et donc je perds de l'espace disque à chaque décalage entre les tailles de bloc définies?

Franz Kafka
la source

Réponses:

16

Secteurs de 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 émuleront des secteurs de 512 octets. Le disque aura des pistes avec un nombre variable de secteurs; les pistes plus proches de l'extérieur du disque ont plus de secteurs car elles ont plus de place 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 512 octets sur un disque moderne.

Certaines structures de formatage peuvent également inclure des informations de correction d'erreur dans les secotrs, qui se manifestent dans les disques formatés de bas niveau avec des secteurs de 520 ou 528 octets. Dans ce cas, le secteur dispose toujours de 512 octets de données utilisateur. Ni Windows ni Linux ne le prennent en charge directement, bien que i5OS (IBM iSeries) et divers contrôleurs SAN le fassent.

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

Taille de bande RAID

Un contrôleur RAID peut avoir une taille de bande pour une baie utilisant une bande (par exemple RAID-5 ou RAID-10). Si la baie possède (par exemple, une bande de 128 Ko), chaque disque a 128 Ko de données contiguës, puis l'ensemble de données suivant se trouve sur le disque suivant. Normalement, vous pouvez vous attendre à obtenir environ une bande par tour de disque, de sorte que la taille de la bande peut affecter les performances de certaines charges de travail.

Alignement de partition

Une partition de disque peut ou non s'aligner exactement avec une bande RAID et peut entraîner une dégradation des performances en raison de lectures fractionnées si elle n'est pas alignée. Certains systèmes (par exemple, le serveur Windows 2008) configurent automatiquement les partitions pour qu'elles s'alignent sur les tailles de bande de volume du disque. Certains (par exemple, le serveur Windows 2003) ne le feront pas, et vous devez utiliser un utilitaire de partition qui prend en charge l'alignement des bandes pour vous en assurer.

Taille de bloc du système de fichiers

Le système de fichiers allouera des blocs de stockage en morceaux d'une certaine taille. Généralement, cela est configurable - par exemple, NTFS prendra en charge les unités d'allocation de (IIRC) 4K à 64K. Un mauvais alignement des partitions et des blocs du système de fichiers sur les bandes RAID peut entraîner la lecture d'un bloc de système de fichiers unique pour générer plusieurs accès au disque où un seul serait nécessaire si les blocs du système de fichiers étaient alignés correctement avec les bandes RAID.

Taille de bloc de base de données

La base de données allouera de l'espace dans une table ou un index dans une certaine taille de bloc donnée. Dans le cas de SQL Server, il s'agit de 8 Ko, et 8 Ko est la valeur par défaut sur de nombreux systèmes. Sur certains systèmes tels qu'Oracle, ceci est configurable et sur PostgreSQL c'est une option au moment de la construction. Sur la plupart des systèmes, l'allocation d'espace aux tables se fait normalement en plus gros morceaux, avec des blocs alloués dans ces morceaux.

Un mauvais alignement du système de fichiers et des blocs d'allocation de données peut générer plusieurs E / S pour une écriture de bloc unique, ce qui peut entraîner une baisse des performances.

E / S de segmentation

Normalement, un SGBD effectuera réellement ses E / S par blocs de plusieurs blocs. Par exemple, sur SQL Server, toutes les E / S sont effectuées en blocs de 8 blocs, 64 Ko au total). Sur Oracle, cela est configurable. Une inspection occasionnelle des documents PostgreSQL ne révèle pas une description spécifique de si PostgreSQL fait cela, donc je ne sais pas comment cela fonctionne sur cette plate-forme.

Lorsque le bloc d'E / S est supérieur à la taille de bloc du système de fichiers ou est mal aligné avec les limites de la bande RAID, une écriture de disque à partir de la base de données peut provoquer plusieurs écritures de disque, ce qui génère une baisse des performances.

Utilisation de l'espace disque

Aucun espace disque n'est gaspillé - les E / S de la base de données utiliseront une ou plusieurs opérations d'E / S physiques sur le disque pour se terminer - mais des E / S mal réglées peuvent générer des inefficacités qui ralentiront la base de données. Les principales choses qui doivent être alignées sont:

  • Bandes et partitions RAID - la partition doit commencer sur une limite de bande RAID.

  • Allocation des E / S du système de fichiers et limites de bande / partition de raid - une limite de bande RAID doit s'aligner sur 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 taille de l'unité d'allocation du système de fichiers. Il doit exister une relation 1: 1 entre les opérations d'E / S de la base de données et les opérations d'E / S du système de fichiers.

Un désalignement ne crée pas un problème d'intégrité des données plus important qu'il ne le serait autrement. La base de données et le système de fichiers ont des mécanismes en place pour garantir que les opérations du système de fichiers sont atomiques. Généralement, un crash de disque entraînera une perte de données mais pas des problèmes d'intégrité des données.

ConcernedOfTunbridgeWells
la source
Très belle réponse. Je me sens mal de ne pouvoir vous donner qu'une seule voix positive ...
Franz Kafka
une dernière question: que voulez-vous dire exactement quand vous parlez d'alignement? S'agit-il d'un multiple de la plus petite taille de bloc? Par exemple, 32k est aligné sur 8k? Ou y a-t-il d'autres facteurs impliqués?
Franz Kafka
@FranzKafka - Non, cela signifie quand quelque chose (généralement une partition de disque) démarre à un emplacement qui n'est pas un multiple entier de ce avec quoi il doit s'aligner. Par exemple, si j'ai une taille de bande RAID de 128 Ko et que la partition ne démarre pas sur un multiple de 128 Ko à partir du «bloc 0», je peux avoir des lectures logiques qui se répartissent sur deux unités d'allocation physique, ce qui nécessite deux opérations de lecture, ce qui provoque un pénalité de performance.
ConcernedOfTunbridgeWells