Parametri del server in Database di Azure per PostgreSQL - Server flessibile

SI APPLICA A: Database di Azure per PostgreSQL - Server flessibile

Database di Azure per PostgreSQL fornisce un subset di parametri configurabili per ogni server. Per altre informazioni sui parametri di Postgres, vedere la documentazione di PostgreSQL.

Tipi di parametro

Database di Azure per PostgreSQL : il server flessibile è preconfigurato con impostazioni predefinite ottimali per ogni parametro. I parametri sono classificati in uno dei tipi seguenti:

• Statico: questi parametri richiedono un riavvio del server per implementare eventuali modifiche.
• Dinamico: questi parametri possono essere modificati senza la necessità di riavviare l'istanza del server. Tuttavia, le modifiche verranno applicate solo alle nuove connessioni stabilite dopo la modifica.
• Sola lettura: questi parametri non sono configurabili dall'utente a causa del loro ruolo critico nella gestione dell'affidabilità, della sicurezza o di altri aspetti operativi del servizio.

Per determinare il tipo di parametro, passare al portale di Azure e aprire il riquadro Parametri del server. I parametri sono raggruppati in schede per facilitare l'identificazione.

Personalizzazione dei parametri

Sono disponibili vari metodi e livelli per personalizzare i parametri in base alle esigenze specifiche.

Livello globale

Per modificare le impostazioni a livello globale a livello di istanza o server, passare al riquadro Parametri del server nel portale di Azure. È anche possibile usare altri strumenti disponibili, ad esempio l'interfaccia della riga di comando di Azure, l'API REST, i modelli di Azure Resource Manager o gli strumenti per i partner.

Nota

Poiché Database di Azure per PostgreSQL è un servizio di database gestito, gli utenti non hanno accesso host o sistema operativo per visualizzare o modificare i file di configurazione, ad esempio postgresql.conf. Il contenuto dei file viene aggiornato automaticamente in base alle modifiche apportate ai parametri.

Livelli granulari

È possibile modificare i parametri a livelli più granulari. Queste modifiche sostituiscono i valori impostati a livello globale. L'ambito e la durata dipendono dal livello in cui vengono eseguite:

• Livello di database: usare il ALTER DATABASE comando per configurazioni specifiche del database.

• Ruolo o livello utente: usare il ALTER USER comando per le impostazioni incentrate sull'utente.

• Funzione, livello di routine: quando si definisce una funzione o una routine, è possibile specificare o modificare i parametri di configurazione che verranno impostati quando viene chiamata la funzione.

• Livello di tabella: ad esempio, è possibile modificare i parametri correlati a autovacuum a questo livello.

• Livello di sessione: per la durata di una singola sessione di database, è possibile modificare parametri specifici. PostgreSQL facilita questa regolazione con i comandi SQL seguenti:

  • Usare il SET comando per apportare modifiche specifiche della sessione. Queste modifiche fungono da impostazioni predefinite durante la sessione corrente. L'accesso a queste modifiche potrebbe richiedere privilegi specifici SET e le limitazioni per i parametri modificabili e di sola lettura descritti in precedenza non si applicano. La funzione SQL corrispondente è set_config(setting_name, new_value, is_local).
  • Usare il SHOW comando per esaminare le impostazioni dei parametri esistenti. L'equivalente della funzione SQL è current_setting(setting_name text).

Parametri importanti

Le sezioni seguenti descrivono alcuni parametri.

shared_buffers

Attributo	valore
Valore predefinito	25% della RAM totale
Valore consentito	10-75% della RAM totale
Type	Statico
Livello	Generale
Note specifiche di Azure	L'impostazione shared_buffers viene dimensionata all'incirca linearmente con l'aumento di vCore in un livello.

Descrizione

Il shared_buffers parametro di configurazione determina la quantità di memoria di sistema allocata al database PostgreSQL per il buffering dei dati. Funge da pool di memoria centralizzato accessibile a tutti i processi di database.

Quando sono necessari i dati, il processo del database controlla prima di tutto il buffer condiviso. Se i dati necessari sono presenti, vengono recuperati rapidamente e ignora una lettura disco che richiede più tempo. Fungendo da intermediario tra i processi di database e il disco, shared_buffers riduce in modo efficace il numero di operazioni di I/O necessarie.

huge_pages

Attributo	valore
Valore predefinito	TRY
Valore consentito	TRY, ON, OFF
Type	Statico
Livello	Generale
Note specifiche di Azure	Per i server con quattro o più vCore, le pagine di grandi dimensioni vengono allocate automaticamente dal sistema operativo sottostante. La funzionalità non è disponibile per i server con meno di quattro vCore. Il numero di pagine enormi viene modificato automaticamente se vengono modificate impostazioni di memoria condivisa, incluse le modifiche a shared_buffers.

Descrizione

Le pagine enormi sono una funzionalità che consente la gestione della memoria in blocchi più grandi. In genere è possibile gestire blocchi fino a 2 MB, anziché le pagine standard da 4 KB.

L'uso di pagine enormi può offrire vantaggi in termini di prestazioni che consentono di eseguire in modo efficace l'offload della CPU:

• Riducono il sovraccarico associato alle attività di gestione della memoria, ad esempio un minor numero di mancati riscontri nel buffer di ricerca della traduzione (TLB).
• Riducono il tempo necessario per la gestione della memoria.

In particolare, in PostgreSQL è possibile usare grandi pagine solo per l'area di memoria condivisa. Una parte significativa dell'area di memoria condivisa viene allocata per i buffer condivisi.

Un altro vantaggio è che grandi pagine impediscono lo scambio dell'area di memoria condivisa su disco, che stabilizza ulteriormente le prestazioni.

Consigli

• Per i server con risorse di memoria significative, evitare di disabilitare grandi pagine. La disabilitazione di grandi pagine potrebbe compromettere le prestazioni.
• Se si inizia con un server più piccolo che non supporta pagine di grandi dimensioni, ma si prevede di aumentare le prestazioni fino a un server che lo fa, mantenere l'impostazione huge_pages su TRY per una transizione senza interruzioni e prestazioni ottimali.

work_mem

Attributo	valore
Valore predefinito	4MB
Valore consentito	4MB-2GB
Type	Dynamic
Livello	Globale e granulare

Descrizione

Il work_mem parametro in PostgreSQL controlla la quantità di memoria allocata per determinate operazioni interne all'interno dell'area di memoria privata di ogni sessione del database. Esempi di queste operazioni sono l'ordinamento e l'hashing.

A differenza dei buffer condivisi, che si trovano nell'area di memoria condivisa, work_mem vengono allocati in uno spazio di memoria privata per sessione o per query. Impostando dimensioni adeguate work_mem , è possibile migliorare significativamente l'efficienza di queste operazioni e ridurre la necessità di scrivere dati temporanei su disco.

Punti chiave

• Memoria di connessione privata: work_mem fa parte della memoria privata usata da ogni sessione di database. Questa memoria è distinta dall'area shared_buffers di memoria condivisa usata.
• Utilizzo specifico delle query: non tutte le sessioni o query usano work_mem. È improbabile che le query semplici, ad esempio SELECT 1 , richiedano work_mem. Tuttavia, query complesse che coinvolgono operazioni come l'ordinamento o l'hashing possono utilizzare uno o più blocchi di work_mem.
• Operazioni parallele: per le query che si estendono su più back-end paralleli, ogni back-end potrebbe potenzialmente usare uno o più blocchi di work_mem.

Monitoraggio e regolazione delle work_mem

È essenziale monitorare continuamente le prestazioni del sistema e regolare work_mem in base alle esigenze, soprattutto se i tempi di esecuzione delle query correlati all'ordinamento o alle operazioni di hashing sono lenti. Ecco i modi per monitorare le prestazioni usando gli strumenti disponibili nel portale di Azure:

• Informazioni dettagliate sulle prestazioni delle query: controllare la scheda Query principali in base ai file temporanei per identificare le query che generano file temporanei. Questa situazione suggerisce una potenziale necessità di aumentare work_mem.
• Guide alla risoluzione dei problemi: usare la scheda File temporanei elevati nelle guide alla risoluzione dei problemi per identificare le query problematiche.

Regolazione granulare

Mentre si gestisce il work_mem parametro, spesso è più efficiente adottare un approccio di regolazione granulare anziché impostare un valore globale. Questo approccio garantisce che allocare la memoria in modo succoso in base alle esigenze specifiche di processi e utenti. Riduce inoltre al minimo il rischio di riscontrare problemi di memoria insufficiente. Ecco come procedere:

• Livello utente: se un utente specifico è coinvolto principalmente nelle attività di aggregazione o creazione di report, che richiedono un utilizzo intensivo della memoria, valutare la possibilità di personalizzare il work_mem valore per tale utente. Usare il ALTER ROLE comando per migliorare le prestazioni delle operazioni dell'utente.

• Livello di funzione/routine: se funzioni o routine specifiche generano file temporanei sostanziali, l'aumento del work_mem valore a livello di funzione o routine specifico può essere vantaggioso. Usare il ALTER FUNCTION comando o ALTER PROCEDURE per allocare in modo specifico più memoria a queste operazioni.

• Livello di database: modificare work_mem a livello di database se solo database specifici generano un numero elevato di file temporanei.

• Livello globale: se un'analisi del sistema rivela che la maggior parte delle query genera piccoli file temporanei, mentre solo alcuni creano file di grandi dimensioni, potrebbe essere prudente aumentare il work_mem valore a livello globale. Questa azione facilita la maggior parte delle query da elaborare in memoria, in modo da evitare operazioni basate su disco e migliorare l'efficienza. Tuttavia, prestare sempre attenzione e monitorare l'utilizzo della memoria nel server per assicurarsi che possa gestire il valore aumentato work_mem .

Determinazione del valore minimo work_mem per le operazioni di ordinamento

Per trovare il valore minimo work_mem per una query specifica, in particolare uno che genera file di disco temporanei durante il processo di ordinamento, iniziare considerando le dimensioni temporanee del file generate durante l'esecuzione della query. Ad esempio, se una query genera un file temporaneo di 20 MB:

1. Connessione al database usando psql o il client PostgreSQL preferito.
2. Impostare un valore iniziale work_mem leggermente superiore a 20 MB per tenere conto delle intestazioni aggiuntive durante l'elaborazione in memoria. Usare un comando, ad esempio : SET work_mem TO '25MB'.
3. Eseguire EXPLAIN ANALYZE nella query problematica nella stessa sessione.
4. Esaminare l'output per "Sort Method: quicksort Memory: xkB". Se indica "external merge Disk: xkB", aumentare il work_mem valore in modo incrementale e ripetere fino a quando non "quicksort Memory" viene visualizzato. Aspetto dei "quicksort Memory" segnali che la query funziona ora in memoria.
5. Dopo aver determinato il valore tramite questo metodo, è possibile applicarlo a livello globale o su livelli più granulari (come descritto in precedenza) in base alle esigenze operative.

maintenance_work_mem

Attributo	valore
Valore predefinito	Dipendente dalla memoria del server
Valore consentito	1MB-2GB
Type	Dynamic
Livello	Globale e granulare

Descrizione

maintenance_work_mem è un parametro di configurazione in PostgreSQL. Controlla la quantità di memoria allocata per le operazioni di manutenzione, ad esempio VACUUM, CREATE INDEXe ALTER TABLE. A differenza di work_mem, che influisce sull'allocazione di memoria per le operazioni di query, maintenance_work_mem è riservata alle attività che mantengono e ottimizzano la struttura del database.

Punti chiave

• Limite di memoria vuoto: per velocizzare la pulizia delle tuple inattivi aumentando maintenance_work_mem, tenere presente che VACUUM presenta una limitazione predefinita per la raccolta di identificatori di tupla non recapitabili. Può usare fino a 1 GB di memoria per questo processo.
• Separazione della memoria per autovacuum: è possibile usare l'impostazione autovacuum_work_mem per controllare la memoria usata dalle operazioni autovacuum in modo indipendente. Questa impostazione funge da subset di maintenance_work_mem. È possibile decidere la quantità di memoria usata dall'autovacuum senza influire sull'allocazione di memoria per altre attività di manutenzione e operazioni di definizione dei dati.

Passaggi successivi

Per informazioni sulle estensioni PostgreSQL supportate, vedere Estensioni PostgreSQL in Database di Azure per PostgreSQL - Server flessibile.