Gestione risorse in pool elastici densi

  • Articolo

Si applica a:Database SQL di Azure

I pool elastici del database SQL di Azure sono una soluzione conveniente per la gestione di molti database con un utilizzo variabile delle risorse. Tutti i database in un pool elastico condividono la stessa allocazione di risorse, ad esempio CPU, memoria, thread di lavoro, spazio di archiviazione, tempdb, presupponendo che solo un subset di database nel pool userà risorse di calcolo in qualsiasi momento. Questo presupposto consente ai pool elastici di essere convenienti. Invece di pagare per tutte le risorse di ogni singolo database potrebbe essere potenzialmente necessario, i clienti pagano un set di risorse molto più piccolo, condiviso tra tutti i database nel pool.

Governance delle risorse

La condivisione delle risorse richiede al sistema di controllare attentamente l'utilizzo delle risorse per ridurre al minimo l'effetto "vicino rumoroso", in cui un database con un utilizzo elevato delle risorse influisce su altri database nello stesso pool elastico. Il database SQL di Azure raggiunge questi obiettivi implementando la governance delle risorse. Allo stesso tempo, il sistema deve fornire risorse sufficienti per funzionalità quali disponibilità elevata e ripristino di emergenza (HADR), backup e ripristino, monitoraggio, Query Store, Ottimizzazione automatica e così via. per funzionare in modo affidabile.

L'obiettivo principale della progettazione dei pool elastici è quello di essere conveniente. Per questo motivo, il sistema consente intenzionalmente ai clienti di creare pool densi , ovvero pool con il numero di database che si avvicinano o al massimo consentito, ma con un'allocazione moderata delle risorse di calcolo. Per lo stesso motivo, il sistema non riserva tutte le risorse potenzialmente necessarie per i processi interni, ma consente la condivisione delle risorse tra processi interni e carichi di lavoro utente.

Questo approccio consente ai clienti di usare pool elastici densi per ottenere prestazioni adeguate e un notevole risparmio sui costi. Tuttavia, se il carico di lavoro rispetto a molti database in un pool denso è sufficientemente intenso, la contesa delle risorse diventa significativa. La contesa delle risorse riduce le prestazioni del carico di lavoro dell'utente e può influire negativamente sui processi interni.

Importante

In pool densi con molti database attivi, potrebbe non essere possibile aumentare il numero di database nel pool fino ai massimi documentati per i pool elastici DTU e vCore .

Il numero di database che possono essere inseriti in pool densi senza causare conflitti di risorse e problemi di prestazioni dipende dal numero di database attivi simultaneamente e dal consumo di risorse da parte dei carichi di lavoro utente in ogni database. Questo numero può cambiare nel tempo man mano che cambiano i carichi di lavoro degli utenti.

Inoltre, se l'impostazione min vCore per database o min DTU per database è impostata su un valore maggiore di 0, il numero massimo di database nel pool verrà limitato in modo implicito. Per altre informazioni, vedere Proprietà del database per database vCore in pool e Proprietà database per i database DTU in pool.

Quando si verifica una contesa di risorse in un pool densamente compresso, i clienti possono scegliere una o più delle azioni seguenti per attenuarla:

  • Ottimizzare il carico di lavoro delle query per ridurre l'utilizzo delle risorse o distribuire il consumo di risorse tra più database nel tempo.
  • Ridurre la densità del pool spostando alcuni database in un altro pool o rendendoli database autonomi.
  • Aumentare le prestazioni del pool per ottenere altre risorse.

Per suggerimenti su come implementare le ultime due azioni, vedere Raccomandazioni operative più avanti in questo articolo. La riduzione della contesa delle risorse offre vantaggi sia per i carichi di lavoro degli utenti che per i processi interni e consente al sistema di mantenere in modo affidabile il livello di servizio previsto.

Monitoraggio dell'utilizzo delle risorse

Per evitare una riduzione delle prestazioni a causa di conflitti di risorse, i clienti che usano pool elastici densi devono monitorare in modo proattivo il consumo delle risorse e intervenire tempestivamente se l'aumento della contesa delle risorse inizia a influire sui carichi di lavoro. Il monitoraggio continuo è importante perché l'utilizzo delle risorse in un pool cambia nel tempo, a causa delle modifiche apportate al carico di lavoro dell'utente, alle modifiche apportate ai volumi di dati e alla distribuzione, alle modifiche apportate alla densità del pool e alle modifiche nel servizio database SQL di Azure.

Il database SQL di Azure fornisce diverse metriche rilevanti per questo tipo di monitoraggio. Il superamento del valore medio consigliato per ogni metrica indica la contesa di risorse nel pool e deve essere risolto usando una delle azioni indicate in precedenza.

Per inviare un avviso quando l'utilizzo delle risorse del pool (CPU, I/O di dati, I/O di log, ruoli di lavoro e così via) supera una soglia, è consigliabile creare avvisi tramite il portale di Azure o il cmdlet di PowerShell Add-AzMetricAlertRulev2 . Durante il monitoraggio dei pool elastici, è consigliabile creare avvisi anche per singoli database nel pool, se necessario nello scenario. Per uno scenario di esempio di monitoraggio dei pool elastici, vedere Monitorare e gestire le prestazioni del database SQL di Azure in un'app SaaS multi-tenant.

Nome metrica Descrizione Valore medio consigliato
avg_instance_cpu_percent Utilizzo della CPU del processo SQL associato a un pool elastico, misurato dal sistema operativo sottostante. Disponibile nella vista sys.dm_db_resource_stats in ogni database e nella vista sys.elastic_pool_resource_stats del master database. Questa metrica viene generata anche in Monitoraggio di Azure, dove è denominatasql_instance_cpu_percent e può essere visualizzata nel portale di Azure. Questo valore è lo stesso per ogni database nello stesso pool elastico. Al di sotto del 70%. I picchi brevi occasionali fino al 90% possono essere accettabili.
max_worker_percent Utilizzo del thread di lavoro. Fornito per ogni database nel pool, nonché per il pool stesso. Esistono limiti diversi per il numero di thread di lavoro a livello di database e a livello di pool, pertanto è consigliabile monitorare questa metrica a entrambi i livelli. Disponibile nella vista sys.dm_db_resource_stats in ogni database e nella vista sys.elastic_pool_resource_stats del master database. Questa metrica viene generata anche in Monitoraggio di Azure, dove è denominataworkers_percent e può essere visualizzata nel portale di Azure. Sotto l'80%. I picchi fino al 100% causeranno l'esito negativo dei tentativi di connessione e delle query.
avg_data_io_percent Utilizzo delle operazioni di I/O al secondo per operazioni di I/O fisiche in lettura e scrittura. Fornito per ogni database nel pool, nonché per il pool stesso. Esistono limiti diversi per il numero di operazioni di I/O al secondo a livello di database e a livello di pool, pertanto è consigliabile monitorare questa metrica a entrambi i livelli. Disponibile nella vista sys.dm_db_resource_stats in ogni database e nella vista sys.elastic_pool_resource_stats del master database. Questa metrica viene generata anche in Monitoraggio di Azure, dove è denominataphysical_data_read_percent e può essere visualizzata nel portale di Azure. Sotto l'80%. I picchi brevi occasionali fino al 100% possono essere accettabili.
avg_log_write_percent Utilizzo della velocità effettiva per operazioni di I/O di scrittura del log delle transazioni. Fornito per ogni database nel pool, nonché per il pool stesso. Esistono limiti diversi per la velocità effettiva del log a livello di database e a livello di pool, pertanto è consigliabile monitorare questa metrica a entrambi i livelli. Disponibile nella vista sys.dm_db_resource_stats in ogni database e nella vista sys.elastic_pool_resource_stats del master database. Questa metrica viene generata anche in Monitoraggio di Azure, dove è denominatalog_write_percent e può essere visualizzata nel portale di Azure. Quando questa metrica è vicina al 100%, tutte le modifiche al database (INSERT, UPDATE, DELETE, istruzioni MERGE, SELECT ... INTO, BULK INSERT e così via) sarà più lento. Al di sotto del 90%. I picchi brevi occasionali fino al 100% possono essere accettabili.
oom_per_second Frequenza di errori di memoria insufficiente (OOM) in un pool elastico, che è un indicatore della pressione di memoria. Disponibile nella visualizzazione sys.dm_resource_governor_resource_pools_history_ex . Vedere Esempi per una query di esempio per calcolare questa metrica. Per altre informazioni, vedere Limiti delle risorse per i pool elastici tramite DTU o pool elastici con vCore e Risolvere gli errori di memoria insufficiente con il database SQL di Azure. Se si verificano errori di memoria insufficiente, esaminare sys.dm_os_out_of_memory_events. 0
avg_storage_percent Spazio di archiviazione totale usato dai dati in tutti i database all'interno di un pool elastico. Non include spazio vuoto nei file di database. Disponibile nella vista sys.elastic_pool_resource_stats nel master database. Questa metrica viene generata anche in Monitoraggio di Azure, dove è denominatastorage_percent e può essere visualizzata nel portale di Azure. Sotto l'80%. Può avvicinarsi al 100% per i pool senza crescita dei dati.
avg_allocated_storage_percent Spazio di archiviazione totale usato dai file di database nell'archiviazione in tutti i database all'interno di un pool elastico. Include spazio vuoto nei file di database. Disponibile nella vista sys.elastic_pool_resource_stats nel master database. Questa metrica viene generata anche in Monitoraggio di Azure, dove è denominataallocated_data_storage_percent e può essere visualizzata nel portale di Azure. Al di sotto del 90%. Può avvicinarsi al 100% per i pool senza crescita dei dati.
tempdb_log_used_percent Utilizzo dello spazio del log delle transazioni nel tempdb database. Anche se gli oggetti temporanei creati in un database non sono visibili in altri database nello stesso pool elastico, tempdb è una risorsa condivisa per tutti i database nello stesso pool. Una transazione a esecuzione prolungata o orfana in tempdb avviata da un database nel pool può utilizzare una grande parte del log delle transazioni e causare errori per le query in altri database nello stesso pool. Derivata da viste sys.dm_db_log_space_usage e sys.database_files . Questa metrica viene generata anche in Monitoraggio di Azure e può essere visualizzata nel portale di Azure. Vedere Esempi per una query di esempio per restituire il valore corrente di questa metrica. Al di sotto del 50%. I picchi occasionali fino all'80% sono accettabili.

Oltre a queste metriche, il database SQL di Azure offre una visualizzazione che restituisce limiti effettivi di governance delle risorse, nonché visualizzazioni aggiuntive che restituiscono statistiche di utilizzo delle risorse a livello di pool di risorse e a livello di gruppo del carico di lavoro.

Nome della vista Descrizione
sys.dm_user_db_resource_governance Restituisce le impostazioni di configurazione e capacità effettive usate dai meccanismi di governance delle risorse nel database corrente o nel pool elastico.
sys.dm_resource_governor_resource_pools Restituisce informazioni sullo stato corrente del pool di risorse, sulla configurazione corrente dei pool di risorse e sulle statistiche del pool di risorse cumulative.
sys.dm_resource_governor_workload_groups Restituisce le statistiche del gruppo di carico di lavoro cumulativo e la configurazione corrente del gruppo di carico di lavoro. Questa vista può essere unita a sys.dm_resource_governor_resource_pools nella pool_id colonna per ottenere informazioni sul pool di risorse.
sys.dm_resource_governor_resource_pools_history_ex Restituisce le statistiche di utilizzo del pool di risorse per la cronologia recente, in base al numero di snapshot disponibili. Ogni riga rappresenta un intervallo di tempo. La durata dell'intervallo viene specificata nella duration_ms colonna . Le delta_ colonne restituiscono la modifica in ogni statistica durante l'intervallo.
sys.dm_resource_governor_workload_groups_history_ex Restituisce le statistiche di utilizzo del gruppo di carico di lavoro per la cronologia recente, in base al numero di snapshot disponibili. Ogni riga rappresenta un intervallo di tempo. La durata dell'intervallo viene specificata nella duration_ms colonna . Le delta_ colonne restituiscono la modifica in ogni statistica durante l'intervallo.

Consiglio

Per eseguire query su queste e altre viste a gestione dinamica usando un'entità diversa dall'amministratore del server, aggiungere questa entità al ruolo del ##MS_ServerStateReader##server.

Queste viste possono essere usate per monitorare l'utilizzo delle risorse e risolvere i problemi di contesa delle risorse quasi in tempo reale. Il carico di lavoro utente nelle repliche secondarie primarie e leggibili, incluse le repliche geografiche, viene classificato nel pool di risorse e UserPrimaryGroup.DBId[N] nel SloSharedPool1 gruppo di carico di lavoro, dove N è l'acronimo del valore id database.

Oltre a monitorare l'utilizzo corrente delle risorse, i clienti che usano pool densi possono mantenere i dati cronologici di utilizzo delle risorse in un archivio dati separato. Questi dati possono essere usati nell'analisi predittiva per gestire in modo proattivo l'utilizzo delle risorse in base alle tendenze cronologiche e stagionali.

Raccomandazioni operative

Lasciare spazio sufficiente per le risorse. Se si verificano conflitti di risorse e riduzione delle prestazioni, la mitigazione può comportare lo spostamento di alcuni database dal pool elastico interessato o l'aumento delle prestazioni, come indicato in precedenza. Tuttavia, queste azioni richiedono il completamento di risorse di calcolo aggiuntive. In particolare, per i pool Premium e Business Critical, queste azioni richiedono il trasferimento di tutti i dati per i database spostati o per tutti i database nel pool elastico se il pool viene ridimensionato. Il trasferimento dei dati è un'operazione a esecuzione prolungata e a elevato utilizzo di risorse. Se il pool è già sottoposto a un utilizzo elevato delle risorse, l'operazione di riduzione delle prestazioni risulterà ancora più elevata. In casi estremi, potrebbe non essere possibile risolvere i conflitti di risorse tramite lo spostamento del database o la scalabilità del pool perché le risorse necessarie non sono disponibili. In questo caso, la riduzione temporanea del carico di lavoro di query nel pool elastico interessato può essere l'unica soluzione.

I clienti che usano pool densi devono monitorare attentamente le tendenze di utilizzo delle risorse come descritto in precedenza ed eseguire azioni di mitigazione mentre le metriche rimangono entro gli intervalli consigliati e nel pool elastico sono ancora presenti risorse sufficienti.

L'utilizzo delle risorse dipende da più fattori che cambiano nel tempo per ogni database e ogni pool elastico. Il raggiungimento di un rapporto prezzo/prestazioni ottimale in pool densi richiede il monitoraggio continuo e il ribilanciamento, ovvero lo spostamento di database da pool più utilizzati a pool meno utilizzati e la creazione di nuovi pool in base alle esigenze per supportare un maggiore carico di lavoro.

Nota

Per i pool elastici DTU, la metrica eDTU a livello di pool non è un valore MAX o SUM di utilizzo singolo del database. ma deriva dall'utilizzo di varie metriche a livello di pool. I limiti delle risorse a livello di pool possono essere superiori ai singoli limiti a livello di database, pertanto è possibile che un singolo database possa raggiungere un limite di risorse specifico (CPU, I/O dei dati, I/O del log e così via), anche quando la creazione di report eDTU per il pool indica che non è stato raggiunto alcun limite.

Non spostare i database "ad accesso frequente". Se la contesa di risorse a livello di pool è causata principalmente da un numero ridotto di database a utilizzo elevato, potrebbe essere difficile spostare questi database in un pool meno utilizzato o renderli database autonomi. Questa operazione, tuttavia, mentre un database rimane altamente utilizzato non è consigliato, perché l'operazione di spostamento degraderà ulteriormente le prestazioni, sia per il database in fase di spostamento che per l'intero pool. Attendere invece che l'utilizzo elevato venga limitato o spostare database meno utilizzati per alleviare la pressione delle risorse a livello di pool. Tuttavia, lo spostamento di database con un utilizzo molto basso non offre alcun vantaggio in questo caso, perché non riduce materialmente l'utilizzo delle risorse a livello di pool.

Creare nuovi database in un pool di "quarantena". Negli scenari in cui vengono creati frequentemente nuovi database, ad esempio le applicazioni che usano il modello tenant per database, esiste il rischio che un nuovo database inserito in un pool elastico esistente utilizzi in modo imprevisto risorse significative e influisca su altri database e processi interni nel pool. Per attenuare questo rischio, creare un pool di "quarantena" separato con un'ampia allocazione di risorse. Usare questo pool per i nuovi database con modelli di utilizzo delle risorse sconosciuti. Una volta che un database è rimasto in questo pool per un ciclo aziendale, ad esempio una settimana o un mese, e il relativo consumo di risorse è noto, può essere spostato in un pool con capacità sufficiente per soddisfare questo utilizzo aggiuntivo delle risorse.

Monitorare sia lo spazio usato che quello allocato. Quando lo spazio del pool allocato (dimensioni totali di tutti i file di database nell'archiviazione per tutti i database in un pool) raggiunge le dimensioni massime del pool, possono verificarsi errori di spazio insufficiente. Se le tendenze dello spazio allocato sono elevate ed è in grado di raggiungere le dimensioni massime del pool, le opzioni di mitigazione includono:

  • Spostare alcuni database all'esterno del pool per ridurre lo spazio totale allocato
  • Compattare i file di database per ridurre lo spazio allocato vuoto nei file
  • Aumentare le prestazioni del pool a un obiettivo di servizio con dimensioni massime del pool maggiori

Se lo spazio del pool usato (dimensioni totali dei dati in tutti i database in un pool, non incluso lo spazio vuoto nei file) è elevato ed è in grado di raggiungere le dimensioni massime del pool, le opzioni di mitigazione includono:

  • Spostare alcuni database all'esterno del pool per ridurre lo spazio usato totale
  • Spostare (archiviare) dati all'esterno del database o eliminare dati non più necessari
  • Implementare la compressione dei dati
  • Aumentare le prestazioni del pool a un obiettivo di servizio con dimensioni massime del pool maggiori

Evitare server eccessivamente densi. Il database SQL di Azure supporta fino a 5000 database per server. I clienti che usano pool elastici con migliaia di database possono prendere in considerazione l'inserimento di più pool elastici in un singolo server, con il numero totale di database fino al limite supportato. Tuttavia, i server con molte migliaia di database creano problemi operativi. Le operazioni che richiedono l'enumerazione di tutti i database in un server, ad esempio la visualizzazione di database nel portale, saranno più lente. Gli errori operativi, ad esempio la modifica errata degli account di accesso a livello di server o delle regole del firewall, influiranno su un numero maggiore di database. L'eliminazione accidentale del server richiederà assistenza dal supporto tecnico Microsoft per ripristinare i database nel server eliminato e causerà un'interruzione prolungata per tutti i database interessati.

Limitare il numero di database per server a un numero inferiore rispetto al massimo supportato. In molti scenari, l'uso di un massimo di 1000-2000 database per server è ottimale. Per ridurre la probabilità di eliminazione accidentale del server, inserire un blocco di eliminazione nel server o nel relativo gruppo di risorse.

Esempi

Visualizzare le impostazioni di capacità dei singoli database

Usare la sys.dm_user_db_resource_governance visualizzazione a gestione dinamica per visualizzare le impostazioni di configurazione e capacità effettive usate dalla governance delle risorse nel database corrente o nel pool elastico. Per altre informazioni, vedere sys.dm_user_db_resource_governance.

Eseguire questa query in qualsiasi database in un pool elastico. Tutti i database nel pool hanno le stesse impostazioni di governance delle risorse.

SELECT * FROM sys.dm_user_db_resource_governance AS rg
WHERE database_id = DB_ID();

Monitoraggio dell'utilizzo complessivo delle risorse del pool elastico

Usare la sys.elastic_pool_resource_stats vista del catalogo di sistema per monitorare l'utilizzo delle risorse dell'intero pool. Per altre informazioni, vedere sys.elastic_pool_resource_stats.

Questa query di esempio per visualizzare gli ultimi 10 minuti deve essere eseguita nel master database del server SQL di Azure logico contenente il pool elastico desiderato.

SELECT * FROM sys.elastic_pool_resource_stats AS rs
WHERE rs.start_time > DATEADD(mi, -10, SYSUTCDATETIME()) 
AND rs.elastic_pool_name = '<elastic pool name>';

Monitoraggio dell'utilizzo delle singole risorse di database

Usare la sys.dm_db_resource_stats visualizzazione a gestione dinamica per monitorare l'utilizzo delle risorse di singoli database. Per altre informazioni, vedere sys.dm_db_resource_stats. Esiste una riga per ogni 15 secondi, anche se non è presente alcuna attività. I dati cronologici vengono mantenuti per circa un'ora.

Questa query di esempio per visualizzare gli ultimi 10 minuti di dati deve essere eseguita nel database desiderato.

SELECT * FROM sys.dm_db_resource_stats AS rs
WHERE rs.end_time > DATEADD(mi, -10, SYSUTCDATETIME());

Per un periodo di conservazione più lungo con minore frequenza, prendere in considerazione la query seguente in sys.resource_stats, eseguire nel master database del server logico SQL di Azure. Per altre informazioni, vedere sys.resource_stats (database SQL di Azure). Esiste una riga ogni cinque minuti e i dati cronologici vengono mantenuti per due settimane.

SELECT * FROM sys.resource_stats
WHERE [database_name] = 'sample'
ORDER BY [start_time] desc;

Monitoraggio dell'utilizzo della memoria

Questa query calcola la oom_per_second metrica per ogni pool di risorse per la cronologia recente, in base al numero di snapshot disponibili. Questa query di esempio consente di identificare il numero medio recente di allocazioni di memoria non riuscite nel pool. Questa query può essere eseguita in qualsiasi database in un pool elastico.

SELECT pool_id,
       name AS resource_pool_name,
       IIF(name LIKE 'SloSharedPool%' OR name LIKE 'UserPool%', 'user', 'system') AS resource_pool_type,
       SUM(CAST(delta_out_of_memory_count AS decimal))/(SUM(duration_ms)/1000.) AS oom_per_second
FROM sys.dm_resource_governor_resource_pools_history_ex
GROUP BY pool_id, name
ORDER BY pool_id;

Monitoraggio dell'utilizzo tempdb dello spazio del log

Questa query restituisce il valore corrente della tempdb_log_used_percent metrica, che mostra l'utilizzo relativo del tempdb log delle transazioni rispetto alle dimensioni massime consentite. Questa query può essere eseguita in qualsiasi database in un pool elastico.

SELECT (lsu.used_log_space_in_bytes / df.log_max_size_bytes) * 100 AS tempdb_log_space_used_percent
FROM tempdb.sys.dm_db_log_space_usage AS lsu
CROSS JOIN (
           SELECT SUM(CAST(max_size AS bigint)) * 8 * 1024. AS log_max_size_bytes
           FROM tempdb.sys.database_files
           WHERE type_desc = N'LOG'
           ) AS df
;

Passaggi successivi