Questa pagina documenta la versione 17.5.0 di AlloyDB Omni utilizzando l'opzione di deployment container. Scegli un'altra opzione di implementazione.

Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

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 aiutarti 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 scrittura parziale
Assistenza O_DIRECT
I/O asincrono (AIO)
Lettura dei flussi di dati

Per attivare queste funzionalità di accelerazione I/O, attiva la alloydb_omni_atomic Grand Unified Configuration (GUC) e configura AlloyDB Omni in modo che possa utilizzare la GUC.

Funzionalità di accelerazione I/O

Le sezioni seguenti descrivono le funzionalità di accelerazione I/O abilitate dalla GUC alloydb_omni_atomic.

Protezione da scrittura parziale

Quando attivi 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 il logging.

Supporto di O_DIRECT

Il supporto di O_DIRECT è un prerequisito per le scritture atomiche. O_DIRECT si applica alla directory di dati PostgreSQL e alla cache del disco di AlloyDB Omni. Per saperne di più, consulta Accelera le prestazioni del database utilizzando la cache del disco.

O_DIRECT offre anche i seguenti vantaggi:

L'utilizzo di O_DIRECT ti 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 l'overhead 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 fallback a libaio quando non viene rilevato il supporto di io_uring. Questo approccio supera la perdita dei vantaggi dell'I/O con buffer, come la lettura anticipata e la combinazione di scrittura, e garantisce inoltre che la larghezza di banda di I/O disponibile dello spazio di archiviazione offerto sottostante sia massimizzata.

Lettura dei flussi di dati

AlloyDB Omni utilizza letture in streaming, che offrono prestazioni migliorate per scansioni sequenziali, ANALYZE e pg_prewarm utilizzando l'I/O vettoriale per leggere più blocchi nella cache del buffer. L'I/O vettorizzato è un metodo in cui una singola chiamata di procedura può eseguire il pre-caricamento dei dati da più buffer, migliorando l'efficienza riducendo i cambi di contesto e le chiamate di sistema.

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

Prima di iniziare

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 tuo kernel non supporta RWF_ATOMIC, ti consigliamo di eseguire l'aggiornamento a una versione kernel che supporti RWF_ATOMIC.

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

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

Puoi eseguire l'override di questo comportamento predefinito, ma ti consigliamo di utilizzare una piattaforma supportata e l'opzione force per evitare di eseguire l'override accidentale delle impostazioni di configurazione ottimali.

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

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

Valore `alloydb_omni_atomic`	Controllo di compatibilità per le startup	Descrizione
off	N/D	Questo valore disattiva la modalità atomica. La funzionalità non è attiva.
force	Esegue il controllo della 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 va a buon fine.	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.

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

Configura il file system XFS per la directory di 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 di RWF_ATOMIC.
1. Crea un file system XFS con una dimensione del blocco di 8 KiB e montalo nella posizione della directory di dati (DATA_DIR) desiderata.
```
sudo mkfs.xfs -f -b size=8k /dev/$DEVICE
sudo mount /dev/$DEVICE DATA_DIR
```
  Sostituisci quanto segue:
  - DATA_DIR: la posizione della directory di 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
...
```
(Facoltativo) Configura la cache del disco di AlloyDB Omni.

Utilizza l'esempio seguente per creare un file system utilizzando ext4,, quindi montalo.
```
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
```
Sostituisci quanto segue:
- 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 un numero maggiore di operazioni di I/O al secondo (IOPS), ti consigliamo di configurare la cache del disco di AlloyDB Omni. Per saperne di più, consulta Accelera le prestazioni del database utilizzando la cache del disco.

Nota: la cache del disco non deve supportare le scritture atomiche perché i dati nella cache sono temporanei. Tuttavia, le funzionalità di accelerazione I/O di AlloyDB Omni utilizzano comunque O_DIRECT per accedere alla cache.
Scarica ed esegui AlloyDB Omni.
1. Scarica il container Docker di AlloyDB Omni più recente. Per ulteriori informazioni, consulta Installa AlloyDB Omni su una VM.
2. Per utilizzare la cache del disco, segui le istruzioni riportate in Accelera 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:17
```
  Effettua le seguenti sostituzioni:
  - CONTAINER_NAME: il nome del container AlloyDB Omni nel registry dei container della macchina host.
  - NEW_PASSWORD: la password assegnata all'utente PostgreSQL del container.
  - DATA_DIR: la posizione della directory di 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 su cui il container deve pubblicare la propria porta 5432.
Configura AlloyDB Omni per utilizzare l'I/O atomico.

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 registry dei container della macchina host.

Limitazioni

PostgreSQL 17 contiene percorsi che eseguono I/O di un singolo blocco, il che rallenta O_DIRECT. Le letture potrebbero essere più lente durante il recupero del database (percorso di ripetizione), le scansioni di vacuum e il preriscaldamento 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 di architettura.
A causa delle sue limitazioni con workload maggiori, libaio è suscettibile alla non disponibilità delle risorse. io_uring potrebbe riscontrare problemi di allocazione della memoria quando la memoria di sistema disponibile è in esaurimento.