Cette page décrit la version 17.5.0 d'AlloyDB Omni à l'aide de l'option de déploiement Conteneurs. Choisissez une autre option de déploiement.

Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

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

Sélectionnez une version de la documentation :

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 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 qui 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.

Les fonctionnalités suivantes sont incluses :

Protection en écriture endommagée
Assistance O_DIRECT
E/S asynchrones (AIO)
Lectures en flux continu

Pour activer ces fonctionnalités d'accélération des E/S, vous devez activer la configuration GUC (Grand Unified Configuration) alloydb_omni_atomic et configurer AlloyDB Omni pour qu'il puisse utiliser la configuration 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 activées par le GUC alloydb_omni_atomic.

Protection en écriture endommagée

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

Compatibilité avec O_DIRECT

La compatibilité avec O_DIRECT est un prérequis pour les écritures atomiques. O_DIRECT s'applique au répertoire de données PostgreSQL et au cache du disque AlloyDB Omni. Pour en savoir plus, consultez Accélérer les performances des bases de données à l'aide du cache du 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 maintenir le cache de mémoire tampon du kernel.

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 utilise 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'écriture, 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 streaming, qui améliorent les performances des analyses séquentielles, de ANALYZE et de pg_prewarm en utilisant des E/S vectorisées pour lire plusieurs blocs dans le cache de 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 changements de contexte et les appels système.

AlloyDB Omni étend la compatibilité pour utiliser les lectures en streaming pour les lectures à partir du cache du 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 les requêtes, plutôt que d'avoir à lire ces blocs à partir du stockage chaque fois qu'ils sont nécessaires.

Avant de commencer

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 est 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 de noyau compatible avec RWF_ATOMIC.

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 incomplètes, activez la configuration GUC (Grand Unification Configuration) alloydb_omni_atomic. 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 incomplètes.

L'option RWF_ATOMIC est utilisée pour la compatibilité avec l'écriture atomique. 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 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 ignorer 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 kernel et le système de fichiers appropriés.

Le tableau suivant liste 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. Échec du démarrage si l'écriture de `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

Configurez le système de fichiers XFS pour le répertoire de données. XFS est utilisé, car il accepte 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 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 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. Vérifiez les journaux du noyau pour vous assurer que des blocs de 8 ko 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
...
```
Facultatif : Configurez le cache du disque AlloyDB Omni.

Utilisez l'exemple suivant pour créer un système de fichiers à l'aide de ext4,, puis installez le système de fichiers.
```
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 du disque AlloyDB Omni. Pour en savoir plus, consultez Accélérer les performances des bases de données à l'aide du cache du disque.

Remarque : Le cache du disque n'a pas besoin de prendre en charge les écritures atomiques, car les données qu'il contient 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.
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 du disque, suivez les instructions de la section Accélérer les performances de la base de données à l'aide du cache du 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:17
```
  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 du disque dans le conteneur.
  - HOST_PORT : port TCP sur la machine hôte sur lequel le conteneur doit publier son propre port 5432.
Configurez AlloyDB Omni pour qu'il utilise des E/S atomiques.

Définissez le 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 17 contient des chemins d'accès qui effectuent des E/S de bloc unique, ce qui ralentit O_DIRECT. Les lectures peuvent être plus lentes lors de la récupération de la base de données (chemin de restauration), des analyses de nettoyage et du préchauffage du cache du disque Omni.
Les fonctionnalités d'accélération des E/S d'AlloyDB Omni dans les instances répliquées avec accès en lecture ne sont pas compatibles avec la version preview.
En cas de charges de travail importantes, les systèmes ARM peuvent présenter des performances inférieures en raison de différences architecturales.
En raison de ses limites liées à l'augmentation des charges de travail, libaio est susceptible de rencontrer des problèmes d'indisponibilité des ressources. io_uring peut rencontrer des problèmes d'allocation de mémoire lorsque la mémoire système disponible est faible.