Améliorer les performances d'AlloyDB Omni grâce à l'accélération des E/S

Sélectionnez une version de la documentation : Actuelle (16.8.0)

• Actuel (16.8.0)
• 16.8.0
• 16.3.0

Preview — AlloyDB Omni

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Vous pouvez traiter des données à caractère personnel lorsque vous utilisez cette fonctionnalité, comme indiqué dans l'Avenant relatif au traitement des données dans le cloud, sous réserve de respecter les obligations et restrictions décrites dans le contrat en vertu duquel vous accédez à Google Cloud. Les fonctionnalités de pré-DG sont disponibles "en l'état" et peuvent avoir une prise en charge limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Cette page explique comment activer un ensemble de fonctionnalités d'accélération des E/S dans AlloyDB Omni. Ces fonctionnalités peuvent vous aider à améliorer l'utilisation de vos ressources de calcul et d'E/S pour accélérer les charges de travail et les performances des requêtes.

Remarque : Les fonctionnalités d'accélération des E/S AlloyDB/Omni sont recommandées uniquement pour les bacs à sable et le développement.

Les fonctionnalités suivantes sont incluses :

• Protection en écriture déchirée
• Assistance O_DIRECT
• E/S asynchrones (AIO)
• Lectures en streaming

Pour activer ces fonctionnalités d'accélération des E/S, vous devez activer la configuration unifiée générale (GUC, Grand Unified Configuration) alloydb_omni_atomic et configurer AlloyDB Omni pour qu'il puisse utiliser la GUC.

Fonctionnalités d'accélération des E/S

Les sections suivantes décrivent les fonctionnalités d'accélération des E/S que le GUC alloydb_omni_atomic permet.

Protection en écriture déchirée

Lorsque vous activez la configuration alloydb_omni_atomic, vous désactivez les écritures de page entière pour éviter la surcharge de performances liée à la génération d'images de page entière pour la journalisation.

Compatibilité avec O_DIRECT

La prise en charge de O_DIRECT est une condition préalable aux écritures atomiques. O_DIRECT s'applique au répertoire de données PostgreSQL et au cache disque AlloyDB Omni. Pour en savoir plus, consultez Accélérer les performances des bases de données à l'aide du cache de disque.

O_DIRECT offre également les avantages suivants :

• L'utilisation de O_DIRECT vous permet d'éviter le problème de double mise en mémoire tampon dans PostgreSQL. PostgreSQL gère son propre cache de tampons et peut contourner le cache de tampons du noyau du système d'exploitation.
• O_DIRECT réduit la surcharge de processeur et de mémoire du système d'exploitation nécessaire pour gérer le cache de tampon du noyau.

E/S asynchrones

La configuration alloydb_omni_atomic fournit des fonctionnalités d'E/S asynchrones (AIO) à l'aide des bibliothèques io_uring et libaio. Nous vous recommandons d'utiliser io_uring pour éviter les limites de l'ancienne bibliothèque libaio. AlloyDB Omni revient à libaio lorsque la compatibilité avec io_uring n'est pas détectée. Cette approche permet de compenser la perte des avantages des E/S mises en mémoire tampon, tels que la lecture anticipée et la combinaison d'écritures. Elle garantit également que la bande passante d'E/S disponible du stockage sous-jacent proposé est maximisée.

Lectures en streaming

AlloyDB Omni utilise des lectures par flux, semblables à la fonctionnalité PostgreSQL 17, qui améliorent les performances des analyses séquentielles, ANALYZE et pg_prewarm en utilisant des E/S vectorisées pour lire plusieurs blocs dans le cache de mémoire tampon. Les E/S vectorisées sont une méthode dans laquelle un seul appel de procédure peut précharger des données à partir de plusieurs tampons, ce qui améliore l'efficacité en réduisant les commutations de contexte et les appels système.

AlloyDB Omni permet d'utiliser des lectures en flux continu pour les lectures à partir du cache disque AlloyDB Omni à l'aide d'AIO afin d'améliorer les performances de lecture. Cette approche facilite la lecture anticipée efficace des tampons dans le pool de mémoire partagée à partir du stockage pour que les requêtes puissent les utiliser, plutôt que d'avoir à lire ces blocs à partir du stockage chaque fois qu'ils sont nécessaires.

Avant de commencer

1. Vérifiez la compatibilité de votre système d'exploitation et de votre système de fichiers.

   1. Pour vous assurer que le noyau est compatible avec RWF_ATOMIC, vérifiez la version du noyau. Dans l'exemple suivant, vous utilisez une machine Ubuntu 24.10 exécutant le noyau Linux 6.14 qui prend en charge les écritures atomiques.

      > sudo hostnamectl
       ...
       Operating System: Ubuntu 24.10
            Kernel: Linux 6.14.0-061400rc5-generic
      ...
      

   2. Si votre noyau n'est pas compatible avec RWF_ATOMIC, nous vous recommandons de passer à une version de noyau compatible avec RWF_ATOMIC.

2. Pour utiliser les fonctionnalités d'accélération des E/S d'AlloyDB Omni afin de tester les gains de performances avec la protection contre les écritures partielles, activez la alloydb_omni_atomic configuration d'unification générale (GUC). Pour utiliser ce GUC, vous devez disposer d'un noyau et d'un système de fichiers compatibles qui fournissent des E/S atomiques et protègent contre les écritures partielles.

   L'option RWF_ATOMIC est utilisée pour la prise en charge de l'écriture atomique. Par défaut, la compatibilité de RWF_ATOMIC est vérifiée au démarrage. PostgreSQL ne démarre pas si les écritures atomiques avec l'indicateur RWF_ATOMIC ne peuvent pas être confirmées.

   Vous pouvez ignorer ce comportement par défaut, mais nous vous recommandons d'utiliser une plate-forme compatible et l'option force pour éviter d'ignorer accidentellement les paramètres de configuration optimaux.

   Vous pouvez remplacer la vérification de compatibilité RWF_ATOMIC en utilisant l'option force_unsafe, mais la sécurité des données n'est pas garantie avec ce remplacement. Nous vous recommandons de ne pas utiliser cette option, sauf si vous évaluez AlloyDB Omni dans un environnement qui ne peut pas être mis à niveau pour utiliser le noyau et le système de fichiers appropriés.

   Le tableau suivant répertorie les paramètres de configuration alloydb_omni_atomic et les vérifications de compatibilité correspondantes.

   Valeur alloydb_omni_atomic	Vérification de la compatibilité au démarrage	Description
   off	N/A	Cette valeur désactive le mode atomique. La fonctionnalité est inactive.
   force	Effectue une vérification de la compatibilité au démarrage. Le démarrage échoue si l'écriture RWF_ATOMIC échoue.	Définit les configurations du mode atomique.
   force_unsafe	N'effectue pas de vérification de compatibilité au démarrage. Renvoie un avertissement, mais continue si l'écriture RWF_ATOMIC échoue.	Définit les configurations du mode atomique.

   Dans la configuration force/force_unsafe, les configurations full_page_writes, io_combine_limit et debug_io_direct sont définies automatiquement. Vous pouvez remplacer ces configurations à l'aide de la configuration facultative on/on_unsafe.

Configurer les fonctionnalités d'accélération des E/S d'AlloyDB Omni

1. Configurez le système de fichiers XFS pour le répertoire de données. XFS est utilisé, car il est compatible avec une taille de bloc de système de fichiers supérieure à la taille de page. AlloyDB Omni peut utiliser XFS pour écrire de manière atomique des blocs de 8 kio avec une prise en charge complète de RWF_ATOMIC.

   1. Créez un système de fichiers XFS avec une taille de bloc de 8 Kio et montez-le à l'emplacement du répertoire de données souhaité (DATA_DIR).

      sudo mkfs.xfs -f -b size=8k /dev/$DEVICE
      sudo mount /dev/$DEVICE DATA_DIR
      

      Effectuez le remplacement suivant :

      • DATA_DIR : emplacement du répertoire de données.

   2. Consultez les journaux du noyau pour vous assurer que des blocs de 8 k sont utilisés :

      > sudo journalctl -f
      ...
      kernel: XFS (sdc): EXPERIMENTAL large block size feature enabled.  Use at your own risk!
      kernel: XFS (sdc): Mounting V5 Filesystem 350aa26a-7555-4566-94c1-74e54ddc9250
      ...
      

2. Facultatif : Configurez le cache de disque AlloyDB Omni.

   Utilisez l'exemple suivant pour créer un système de fichiers à l'aide de ext4,, puis montez-le.

   sudo /sbin/mkfs.ext4 -m 1 -F -E lazy_itable_init=0,lazy_journal_init=0 /dev/DEVICE
   sudo mount --make-shared -o noatime,discard,errors=panic /dev/DEVICE /OMNI_DISK_CACHE_DIRECTORY
   

   Effectuez le remplacement suivant :

   • DEVICE : entité avec laquelle l'application interagit pour effectuer des opérations d'E/S (lecture ou écriture de données).

   Pour optimiser les performances des fonctionnalités d'accélération des E/S d'AlloyDB Omni lorsque le stockage principal n'offre pas un nombre d'opérations d'entrée/sortie par seconde (IOPS) plus élevé, nous vous recommandons de configurer le cache de disque AlloyDB Omni. Pour en savoir plus, consultez Accélérer les performances des bases de données à l'aide du cache de disque.

   Remarque : Le cache de disque n'a pas besoin d'être compatible avec les écritures atomiques, car les données du cache sont éphémères. Toutefois, les fonctionnalités d'accélération des E/S AlloyDB Omni utilisent toujours O_DIRECT pour accéder au cache.

3. Téléchargez et exécutez AlloyDB Omni.

   1. Téléchargez le dernier conteneur Docker AlloyDB Omni. Pour en savoir plus, consultez Installer AlloyDB Omni sur une VM.
   2. Pour utiliser le cache de disque, suivez les instructions de la section Accélérer les performances de la base de données à l'aide du cache de disque.

   3. Pour autoriser io_uring, ajoutez un argument supplémentaire, --security-opts="seccomp:unconfined".

      docker run -d --name CONTAINER_NAME \
         -e POSTGRES_PASSWORD=NEW_PASSWORD \
         -v DATA_DIR:/var/lib/postgresql/data \
         -v /OMNI_DISK_CACHE_DIRECTORY:/CACHE_DIRECTORY_PATH_INSIDE_CONTAINER \  # Only if disk cache is enabled
         -p HOST_PORT:5432 \
         --security-opts="seccomp:unconfined" \
         --restart=always \
         google/alloydbomni:16
      

      Effectuez les remplacements suivants :

      • CONTAINER_NAME : nom du conteneur AlloyDB Omni dans le registre de conteneurs de votre machine hôte.
      • NEW_PASSWORD : mot de passe attribué à l'utilisateur PostgreSQL du conteneur.
      • DATA_DIR : emplacement du répertoire de données.
      • CACHE_DIRECTORY_PATH_INSIDE_CONTAINER : chemin d'accès au répertoire du cache de disque à l'intérieur du conteneur.
      • HOST_PORT : port TCP sur la machine hôte auquel le conteneur doit publier son propre port 5432.

4. Configurez AlloyDB Omni pour utiliser les E/S atomiques.

   Définissez le paramètre GUC alloydb_omni_atomic sur une valeur appropriée et redémarrez le conteneur.

   alter system set alloydb_omni_atomic='force';
   sudo docker restart CONTAINER_NAME;
   

   Effectuez les remplacements suivants :

   • CONTAINER_NAME : nom du conteneur AlloyDB Omni dans le registre de conteneurs de votre machine hôte.

Limites

• PostgreSQL 16 contient des chemins qui effectuent des E/S à bloc unique, ce qui ralentit O_DIRECT. Les lectures peuvent être plus lentes pendant la récupération de la base de données (chemin de rétablissement), les analyses de nettoyage et le préchauffage du cache de disque Omni.
• Les fonctionnalités d'accélération des E/S d'AlloyDB Omni dans les instances dupliquées avec accès en lecture ne sont pas compatibles avec la version preview.
• En cas de charges de travail importantes, les systèmes basés sur ARM peuvent présenter des performances inférieures en raison de différences architecturales.
• En raison de ses limites avec les charges de travail accrues, libaio est susceptible de ne pas disposer de ressources. io_uring peut rencontrer des problèmes d'allocation de mémoire lorsque la mémoire système disponible est faible.