Gestione risorse in pool elastici densi

Si applica a: Database SQL di Azure

Azure SQL pool elastici di database è una soluzione conveniente per la gestione di molti database con 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, sul presupposto 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 ogni singolo database potrebbe potenzialmente essere 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 utilizzo elevato di risorse influisce su altri database nello stesso pool elastico. Azure SQL Database 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 risparmi importanti sui costi. Tuttavia, se il carico di lavoro su 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 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 quando i carichi di lavoro utente cambiano.

Inoltre, se il numero minimo di vCore per database o min DTU per ogni impostazione di database è impostato su un valore maggiore di 0, il numero massimo di database nel pool sarà implicitamente limitato. Per altre informazioni, vedere Proprietà del database per database vCore in pool e proprietà del database per i databaseDTU in pool.

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

  • Ottimizzare il carico di lavoro di query per ridurre l'utilizzo delle risorse o distribuire il consumo di risorse in più database nel tempo.
  • Ridurre la densità del pool spostando alcuni database in un altro pool o rendendoli database autonomi.
  • Aumentare la scalabilità del pool per ottenere più 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 utente che per i processi interni e consente al sistema di mantenere in modo affidabile il livello previsto di servizio.

Monitoraggio dell'utilizzo delle risorse

Per evitare il degrado delle prestazioni a causa della contesa delle risorse, i clienti che usano pool elastici densi devono monitorare in modo proattivo il consumo delle risorse e intraprendere azioni tempestive se la 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 utente, alle modifiche nei volumi di dati e alla distribuzione, alle modifiche apportate alla densità del pool e alle modifiche apportate al servizio database di Azure SQL.

Azure SQL Database fornisce diverse metriche rilevanti per questo tipo di monitoraggio. Il superamento del valore medio consigliato per ogni metrica indica la contesa delle 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 dati, I/O log, lavoratori e così via) supera una soglia, valutare la possibilità di creare avvisi tramite il portale di Azure o il cmdlet Add-AzMetricAlertRulev2 PowerShell. Quando si monitora pool elastici, è consigliabile creare anche avvisi 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 Azure SQL 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 visualizzazione sys.dm_db_resource_stats in ogni database e nella visualizzazione sys.elastic_pool_resource_stats nel master database. Questa metrica viene anche generata in Monitoraggio di Azure, in cui è denominatasqlserver_process_core_percent e può essere visualizzata in 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 visualizzazione sys.dm_db_resource_stats in ogni database e nella visualizzazione sys.elastic_pool_resource_stats nel master database. Questa metrica viene anche generata in Monitoraggio di Azure, in cui è denominataworkers_percent e può essere visualizzata in portale di Azure. Al di sotto del 80%. I picchi fino al 100% causeranno l'esito negativo dei tentativi di connessione e delle query.
avg_data_io_percent Utilizzo operazioni di I/O al secondo per la lettura e la scrittura di I/O fisiche. 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 visualizzazione sys.dm_db_resource_stats in ogni database e nella visualizzazione sys.elastic_pool_resource_stats nel master database. Questa metrica viene anche generata in Monitoraggio di Azure, in cui è denominataphysical_data_read_percent e può essere visualizzata in portale di Azure. Al di sotto del 80%. I picchi brevi occasionali fino al 100% possono essere accettabili.
avg_log_write_percent Utilizzo della velocità effettiva per L'I/O 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 visualizzazione sys.dm_db_resource_stats in ogni database e nella visualizzazione sys.elastic_pool_resource_stats nel master database. Questa metrica viene anche generata in Monitoraggio di Azure, in cui è denominatalog_write_percent e può essere visualizzata in portale di Azure. Quando questa metrica è vicina al 100%, tutte le modifiche del 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 . Per calcolare questa metrica, vedere Esempi per una query di esempio. Per altre informazioni, vedere Limiti delle risorse per i pool elastici usando DTU o pool elastici usandovCore e Risolvere i problemi relativi agli errori di memoria con Azure SQL Database. 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 visualizzazione sys.elastic_pool_resource_stats nel master database. Questa metrica viene anche generata in Monitoraggio di Azure, in cui è denominatastorage_percent e può essere visualizzata in portale di Azure. Al di sotto del 80%. Può avvicinarsi al 100% per i pool senza una 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 visualizzazione sys.elastic_pool_resource_stats nel master database. Questa metrica viene anche generata in Monitoraggio di Azure, in cui è denominataallocated_data_storage_percent e può essere visualizzata in portale di Azure. Al di sotto del 90%. Può avvicinarsi al 100% per i pool senza una crescita dei dati.
tempdb_log_used_percent Utilizzo dello spazio dei 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 avvio 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 sys.dm_db_log_space_usage e viste sys.database_files . Questa metrica viene anche generata in Monitoraggio di Azure e può essere visualizzata in 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 al 80% sono accettabili.

Oltre a queste metriche, Azure SQL Database offre una visualizzazione che restituisce limiti effettivi di governance delle risorse, nonché viste aggiuntive che restituiscono statistiche sull'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 cumulative del pool di risorse.
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.

Suggerimento

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 conflitti di 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 del 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 la risorsa. 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 da spostare 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 mitigazione stessa renderà ancora più elevate le prestazioni. In casi estremi, potrebbe non essere possibile risolvere i conflitti di risorse tramite lo spostamento del database o l'aumento delle prestazioni del pool perché le risorse necessarie non sono disponibili. In questo caso, la riduzione temporanea del carico di lavoro delle 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 disponibili 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 nei 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 UNA SOMMA di utilizzo dei singoli database. 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 uso elevato, potrebbe essere probabile 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 comporterà un ulteriore peggioramento delle prestazioni, sia per il database in fase di spostamento che per l'intero pool. Attendere invece che l'utilizzo elevato diminuisca 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, è possibile 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 supportare questo utilizzo aggiuntivo delle risorse.

Monitorare sia lo spazio usato che lo spazio 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 pista per 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 massime del pool

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 totale usato
  • Spostare (archiviare) i dati all'esterno del database o eliminare i dati non più necessari
  • Implementare la compressione dei dati
  • Aumentare le prestazioni del pool a un obiettivo di servizio con dimensioni massime massime del pool

Evitare server eccessivamente densi. Azure SQL Database 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 dei 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 da 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 numero 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 logico Azure SQL 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 del database

Usare la sys.dm_db_resource_stats visualizzazione a gestione dinamica per monitorare l'utilizzo delle risorse dei 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 una frequenza inferiore, considerare la query seguente in sys.resource_stats, eseguire nel master database del server logico Azure SQL. Per altre informazioni, vedere sys.resource_stats (database Azure SQL).For more information, see sys.resource_stats (Azure SQL Database). 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 dei 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