Migliorare le prestazioni di AlloyDB Omni utilizzando l'accelerazione I/O

Seleziona una versione della documentazione:

Questa pagina descrive come abilitare un insieme di funzionalità di accelerazione I/O in AlloyDB Omni che possono contribuire a migliorare l'utilizzo delle risorse di calcolo e I/O per workload e prestazioni delle query più veloci.

Sono incluse le seguenti funzionalità:

  • Protezione da scritture incomplete
  • Supporto O_DIRECT
  • I/O asincrono (AIO)
  • Lettura dei flussi di dati

Per abilitare queste funzionalità di accelerazione I/O, devi abilitare la configurazione unificata (GUC) alloydb_omni_atomic e configurare AlloyDB Omni in modo che possa utilizzare la GUC.

Funzionalità di accelerazione I/O

Le sezioni seguenti descrivono le funzionalità di accelerazione I/O che la GUC alloydb_omni_atomic abilita.

Protezione da scritture incomplete

Quando abiliti la configurazione alloydb_omni_atomic, disattivi le scritture di pagine complete per evitare il sovraccarico delle prestazioni dovuto alla necessità di generare immagini di pagine complete per la registrazione.

Supporto O_DIRECT

Il supporto O_DIRECT è un prerequisito per le scritture atomiche. O_DIRECT si applica alla directory dei dati di PostgreSQL e alla cache del disco di AlloyDB Omni. Per ulteriori informazioni, consulta Accelerare le prestazioni del database utilizzando la cache del disco.

O_DIRECT offre anche i seguenti vantaggi:

  • L'utilizzo di O_DIRECT consente di evitare il problema del doppio buffering in PostgreSQL. PostgreSQL gestisce la propria cache del buffer e può ignorare la cache del buffer del kernel del sistema operativo.
  • O_DIRECT riduce il sovraccarico della CPU e della memoria del sistema operativo necessario per gestire la cache del buffer del kernel.

I/O asincrono

La configurazione alloydb_omni_atomic fornisce funzionalità di I/O asincrono (AIO) utilizzando le librerie io_uring e libaio. Ti consigliamo di utilizzare io_uring per evitare le limitazioni della libreria libaio precedente. AlloyDB Omni esegue il fallback a libaio quando non viene rilevato il supporto io_uring. Questo approccio supera la perdita dei vantaggi di I/O con buffer, come la lettura anticipata e la combinazione di scritture, e garantisce anche che la larghezza di banda I/O disponibile dello spazio di archiviazione sottostante offerto sia massimizzata.

Lettura dei flussi di dati

AlloyDB Omni utilizza la lettura dei flussi di dati, simile alla funzionalità di PostgreSQL 17, che offre prestazioni migliorate per le scansioni sequenziali, ANALYZE e pg_prewarm utilizzando I/O vettoriale per leggere più blocchi nella cache del buffer. L'I/O vettoriale è un metodo in cui una singola chiamata di procedura può precaricare i dati da più buffer, il che migliora l'efficienza riducendo i cambi di contesto e le chiamate di sistema.

AlloyDB Omni estende il supporto per l'utilizzo della lettura dei flussi di dati per le letture dalla cache del disco di AlloyDB Omni utilizzando AIO per amplificare le prestazioni di lettura. Questo approccio facilita la lettura anticipata efficace dei buffer nel pool di memoria condivisa dallo spazio di archiviazione per l'utilizzo delle query, anziché dover leggere questi blocchi dallo spazio di archiviazione ogni volta che sono necessari.

Prima di iniziare

  1. Controlla il supporto del sistema operativo e del file system.

    1. Per assicurarti che il kernel supporti RWF_ATOMIC, controlla la versione kernel. Nell'esempio seguente, utilizzi una macchina Ubuntu 24.10 che esegue il kernel Linux 6.14 che supporta le scritture atomiche.

      > sudo hostnamectl
       ...
       Operating System: Ubuntu 24.10
            Kernel: Linux 6.14.0-061400rc5-generic
      ...
      
    2. Se il kernel non supporta RWF_ATOMIC, ti consigliamo di eseguire l'aggiornamento a una versione kernel che supporti RWF_ATOMIC.

  2. Per utilizzare le funzionalità di accelerazione I/O di AlloyDB Omni per testare i miglioramenti delle prestazioni con la protezione da scritture incomplete, abilita la configurazione unificata (GUC) alloydb_omni_atomic. Per utilizzare questa GUC, devi disporre di un kernel e di un file system di supporto che forniscano I/O atomico e protezione da scritture incomplete.

    Il flag RWF_ATOMIC viene utilizzato per il supporto delle scritture atomiche. Per impostazione predefinita, la compatibilità con RWF_ATOMIC viene verificata durante l'avvio. PostgreSQL non viene avviato se non è possibile confermare le scritture atomiche con il flag RWF_ATOMIC.

    Puoi ignorare questo comportamento predefinito, ma ti consigliamo di utilizzare una piattaforma supportata e l'opzione force per evitare di ignorare accidentalmente le impostazioni di configurazione ottimali.

    Puoi ignorare il controllo di compatibilità RWF_ATOMIC utilizzando l'opzione force_unsafe, ma la sicurezza dei dati non è garantita con questa sostituzione. Ti consigliamo di non utilizzare questa opzione a meno che tu non stia valutando AlloyDB Omni in un ambiente che non può essere aggiornato per utilizzare il kernel e il file system appropriati.

    La tabella seguente elenca le impostazioni di configurazione alloydb_omni_atomic e i controlli di compatibilità corrispondenti.

    Valore alloydb_omni_atomic Controllo di compatibilità all'avvio Descrizione
    off
    N/D Questo valore disattiva la modalità atomica. La funzionalità è inattiva.
    force
    Esegue il controllo di compatibilità all'avvio. Non viene avviato se la scrittura RWF_ATOMIC non riesce. Imposta le configurazioni della modalità atomica.
    force_unsafe
    Non esegue un controllo di compatibilità all'avvio. Restituisce un avviso, ma continua se RWF_ATOMIC la scrittura non riesce. Imposta le configurazioni della modalità atomica.

    Nella configurazione force/force_unsafe, le configurazioni full_page_writes, io_combine_limit e debug_io_direct vengono impostate automaticamente. Puoi ignorare queste configurazioni utilizzando la configurazione facoltativa on/on_unsafe.

Configurare le funzionalità di accelerazione I/O di AlloyDB Omni

  1. Configura il file system XFS per la directory dei dati. XFS viene utilizzato perché supporta una dimensione del blocco del file system maggiore della dimensione della pagina. AlloyDB Omni può utilizzare XFS per scrivere in modo atomico blocchi da 8 KiB con supporto completo RWF_ATOMIC.

    1. Crea un file system XFS con una dimensione del blocco di 8 KiB e montalo nella posizione della directory dei dati (DATA_DIR).

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

      Effettua la seguente sostituzione:

      • DATA_DIR: la posizione della directory dei dati.
    2. Controlla i log del kernel per assicurarti che vengano utilizzati blocchi da 8k:

      > 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. (Facoltativo) Configura la cache del disco di AlloyDB Omni.

    Utilizza l'esempio seguente per creare un file system utilizzando ext4, e poi montarlo.

    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
    

    Effettua la seguente sostituzione:

    • DEVICE: l'entità con cui l'applicazione interagisce per eseguire operazioni di I/O (lettura o scrittura di dati).

    Per supportare prestazioni ottimali delle funzionalità di accelerazione I/O di AlloyDB Omni quando lo spazio di archiviazione principale non offre operazioni di I/O al secondo (IOPS) più elevate, ti consigliamo di configurare la cache del disco di AlloyDB Omni. Per ulteriori informazioni, consulta Accelerare le prestazioni del database utilizzando la cache del disco.

  3. Scarica ed esegui AlloyDB Omni.

    1. Scarica l'ultimo container Docker di AlloyDB Omni. Per ulteriori informazioni, consulta Installare AlloyDB Omni su una VM.
    2. Per utilizzare la cache del disco, segui le istruzioni riportate in Accelerare le prestazioni del database utilizzando la cache del disco.
    3. Per consentire io_uring, aggiungi un argomento aggiuntivo, --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
      

      Effettua le seguenti sostituzioni:

      • CONTAINER_NAME: il nome del container AlloyDB Omni nel registro dei container della macchina host.
      • NEW_PASSWORD: la password assegnata all'utente PostgreSQL del container.
      • DATA_DIR: la posizione della directory dei dati.
      • CACHE_DIRECTORY_PATH_INSIDE_CONTAINER: il percorso della directory della cache su disco all'interno del container.
      • HOST_PORT: la porta TCP sulla macchina host a cui il container deve pubblicare la propria porta 5432.
  4. Configura AlloyDB Omni per utilizzare I/O atomico.

    Imposta la GUC alloydb_omni_atomic su un valore appropriato e riavvia il container.

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

    Effettua le seguenti sostituzioni:

    • CONTAINER_NAME: il nome del container AlloyDB Omni nel registro dei container della macchina host.

Limitazioni

  • PostgreSQL 16 contiene percorsi che eseguono I/O a blocco singolo, che O_DIRECT rallenta. Potrebbero verificarsi letture più lente durante il ripristino del database (percorso di ripetizione), le scansioni di vacuum e il pre-riscaldamento della cache del disco Omni.
  • Le funzionalità di accelerazione I/O di AlloyDB Omni nelle repliche di lettura non sono supportate in anteprima.
  • In caso di workload elevati, i sistemi basati su ARM potrebbero mostrare prestazioni inferiori a causa delle differenze architetturali.
  • A causa delle limitazioni con l'aumento dei workload, libaio è soggetto a indisponibilità delle risorse. io_uring potrebbe riscontrare problemi di allocazione della memoria quando la memoria di sistema disponibile è in esaurimento.