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

Sélectionnez une version de la documentation : 16.9.0

• 17.7.0
• 17.5.0
• 16.11.0
• 16.9.0
• 16.8.0
• 16.3.0

Bêta : 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 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 d'AlloyDB Omni ne sont recommandées qu'à des fins de bac à sable et de développement.

Les fonctionnalités suivantes sont incluses :

• Protection contre les écritures tronquées
• Compatibilité avec O_DIRECT
• E/S asynchrones (AIO)
• Lectures en flux continu

Pour activer ces fonctionnalités d'accélération des E/S, activez la configuration unifiée globale (alloydb_omni_atomic) et configurez AlloyDB Omni pour qu'il puisse l'utiliser.

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 la configuration unifiée globale alloydb_omni_atomic active.

Protection contre les écritures tronquées

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

Compatibilité avec O_DIRECT

La compatibilité avec O_DIRECT est une condition préalable aux écritures atomiques. O_DIRECT s'applique au répertoire de données PostgreSQL et au 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.

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 mémoire tampon et peut contourner le cache de mémoire tampon du noyau du système d'exploitation.
• O_DIRECT réduit la surcharge du processeur et de la mémoire du système d'exploitation nécessaire pour maintenir le cache de mémoire 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 surmonter la perte d'avantages des E/S mises en mémoire tampon, tels que la lecture anticipée et la combinaison d'écritures, et garantit également que la bande passante d'E/S disponible du stockage sous-jacent proposé est maximisée.

Lectures en flux continu

AlloyDB Omni utilise des lectures en flux continu, semblables à la fonctionnalité PostgreSQL 17, qui améliorent les analyses séquentielles, ANALYZE et les performances 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éextraire des données de plusieurs mémoires tampons, ce qui améliore l'efficacité en réduisant les commutations de contexte et les appels système.

AlloyDB Omni étend la compatibilité pour utiliser les lectures en flux continu pour les lectures à partir du cache de disque AlloyDB Omni à l'aide d'AIO afin d'amplifier les performances de lecture. Cette approche facilite la lecture anticipée efficace des mémoires tampons dans le pool de mémoire partagée à partir du stockage pour que les requêtes puissent les utiliser, au lieu 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 compatible avec 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 du 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 tronquées, activez la configuration unifiée globale (alloydb_omni_atomic). Pour utiliser cette configuration unifiée globale, 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 tronquées.

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

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

   Vous pouvez remplacer la vérification de compatibilité RWF_ATOMIC à l'aide de 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 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 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 RWF_ATOMIC l'écriture é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 la page. AlloyDB Omni peut utiliser XFS pour écrire de manière atomique des blocs de 8 Kio avec une compatibilité RWF_ATOMIC complète.

   1. Créez un système de fichiers XFS avec une taille de bloc de 8 Kio et installez-le à l'emplacement du répertoire de données (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 Kio 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 installez-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 assurer des performances optimales 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 d'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 des bases 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 dans le conteneur.
      • HOST_PORT: port TCP sur la machine hôte sur lequel le conteneur doit publier son propre port 5432.

4. Configurez AlloyDB Omni pour qu'il utilise des E/S atomiques.

   Définissez la configuration unifiée globale 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 d'accès qui effectuent des E/S de bloc unique, ce que O_DIRECT ralentit. Les lectures peuvent être plus lentes lors de la récupération de la base de données (chemin de rétablissement), des analyses de nettoyage et du 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 en version bêta.
• 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 des charges de travail accrues, libaio est susceptible de ne pas être disponible. io_uring peut rencontrer des problèmes d'allocation de mémoire lorsque la mémoire système disponible est faible.