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

Seleziona una versione della documentazione:

Questa pagina descrive come attivare 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 carichi di lavoro e prestazioni delle query più rapidi.

Sono incluse le seguenti funzionalità:

  • Protezione scrittura strappata
  • Assistenza O_DIRECT
  • I/O asincrono (AIO)
  • Lettura dei flussi di dati

Per attivare queste funzionalità di accelerazione I/O, devi attivare la alloydb_omni_atomic Grand Unified Configuration (GUC) 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 scrittura strappata

Quando abiliti la configurazione alloydb_omni_atomic, disattivi le scritture di pagine intere per evitare l'overhead delle prestazioni dovuto alla generazione di immagini di pagine intere per la registrazione.

Supporto O_DIRECT

Il supporto di O_DIRECT è un prerequisito per le scritture atomiche. O_DIRECT si applica alla directory dei dati PostgreSQL e alla cache su disco di AlloyDB Omni. Per ulteriori informazioni, vedi Migliorare 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ò bypassare la cache del buffer del kernel del sistema operativo.
  • O_DIRECT riduce il sovraccarico di CPU e memoria del sistema operativo necessario per mantenere 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 failover su libaio quando non viene rilevato il supporto di io_uring. Questo approccio supera la perdita dei vantaggi di I/O con buffer, come lettura anticipata e combinazione di scrittura, e garantisce inoltre che la larghezza di banda I/O disponibile dello spazio di archiviazione offerto sottostante venga massimizzata.

Lettura dei flussi di dati

AlloyDB Omni utilizza letture in streaming, simili alla funzionalità di PostgreSQL 17, che forniscono prestazioni migliorate per scansioni sequenziali, ANALYZE e pg_prewarm utilizzando I/O vettoriali per leggere più blocchi nella cache del buffer. Vectored I/O è 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 di letture in streaming per le letture dalla cache del disco AlloyDB Omni utilizzando AIO per migliorare 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 del 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 tuo kernel non supporta RWF_ATOMIC, ti consigliamo di eseguire l'aggiornamento a una versione del kernel che lo supporti.RWF_ATOMIC

  2. Per utilizzare le funzionalità di accelerazione I/O di AlloyDB Omni per testare i miglioramenti delle prestazioni con la protezione dalla scrittura incompleta, attiva la alloydb_omni_atomic Grand Unification Configuration (GUC). Per utilizzare questo GUC, devi disporre di un kernel e di un file system di supporto che forniscano I/O atomici e proteggano da scritture incomplete.

    Il flag RWF_ATOMIC viene utilizzato per il supporto della scrittura atomica. Per impostazione predefinita, la compatibilità per RWF_ATOMIC viene verificata all'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 RWF_ATOMICcontrollo di compatibilità utilizzando l'opzioneforce_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 filesystem appropriati.

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

    Valore alloydb_omni_atomic Controllo della compatibilità all'avvio Descrizione
    off
    N/D Questo valore disattiva la modalità atomica. La funzionalità non è attiva.
    force
    Esegue il controllo di compatibilità all'avvio. L'avvio non riesce se la scrittura di RWF_ATOMIC non va a buon fine. Imposta le configurazioni della modalità atomica.
    force_unsafe
    Non esegue un controllo di compatibilità all'avvio. Restituisce un avviso, ma continua se la scrittura di RWF_ATOMIC 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 eseguire l'override di 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 filesystem superiore alla dimensione della pagina. AlloyDB Omni può utilizzare XFS per scrivere in modo atomico blocchi da 8 KiB con supporto completo di RWF_ATOMIC.

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

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

      Esegui la seguente sostituzione:

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

      > 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 su disco di AlloyDB Omni.

    Utilizza il seguente esempio per creare un filesystem 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
    

    Esegui la seguente sostituzione:

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

    Per supportare le prestazioni ottimali delle funzionalità di accelerazione I/O di AlloyDB Omni quando l'archiviazione primaria non offre operazioni di input/output al secondo (IOPS) più elevate, ti consigliamo di configurare la cache del disco AlloyDB Omni. Per ulteriori informazioni, vedi Migliorare 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 saperne di più, consulta Installare AlloyDB Omni su una VM.
    2. Per utilizzare la cache su disco, segui le istruzioni riportate in Migliorare le prestazioni del database utilizzando la cache su 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 del 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 in modo che utilizzi I/O atomici.

    Imposta il 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, il che O_DIRECT rallenta. Potrebbero verificarsi letture più lente durante il recupero 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 carichi di lavoro elevati, i sistemi basati su ARM potrebbero mostrare prestazioni inferiori a causa di 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.