Resourcebeheer in dichte elastische pools

Van toepassing op: Azure SQL Database

Elastische pools van Azure SQL Database is een rendabele oplossing voor het beheren van veel databases met verschillende resourcegebruik. Alle databases in een elastische pool delen dezelfde toewijzing van resources, zoals CPU, geheugen, werkthreads, opslagruimte, tempdbwaarbij wordt aangenomen dat op elk gewenst moment slechts een subset van databases in de pool rekenresources gebruikt. Met deze aanname kunnen elastische pools rendabel zijn. In plaats van te betalen voor alle resources die elke afzonderlijke database mogelijk nodig heeft, betalen klanten voor een veel kleinere set resources, die worden gedeeld met alle databases in de pool.

Resourcebeheer

Voor het delen van resources moet het systeem het resourcegebruik zorgvuldig beheren om het effect 'lawaaierige buren' te minimaliseren, waarbij een database met een hoog resourceverbruik van invloed is op andere databases in dezelfde elastische pool. Azure SQL Database bereikt deze doelen door resourcebeheer te implementeren. Tegelijkertijd moet het systeem voldoende resources bieden voor functies zoals hoge beschikbaarheid en herstel na noodgevallen (HADR), back-up en herstel, bewaking, Query Store, Automatisch afstemmen, enzovoort. om betrouwbaar te functioneren.

Het primaire ontwerpdoel van elastische pools is rendabel. Om deze reden stelt het systeem klanten in staat om dichte pools te maken. Dit zijn pools met het aantal databases dat nadert of maximaal is toegestaan, maar met een gemiddelde toewijzing van rekenresources. Om dezelfde reden reserveert het systeem niet alle mogelijk benodigde resources voor de interne processen, maar staat het delen van resources tussen interne processen en gebruikersworkloads toe.

Met deze aanpak kunnen klanten dichte elastische pools gebruiken om adequate prestaties en grote kostenbesparingen te bereiken. Als de workload voor veel databases in een dichte pool echter voldoende intensief is, wordt resourceconflict aanzienlijk. Resourceconflicten verminderen de prestaties van gebruikersworkloads en kunnen negatieve gevolgen hebben voor interne processen.

Belangrijk

In dichte pools met veel actieve databases is het mogelijk niet haalbaar om het aantal databases in de pool te verhogen tot de maximumlimieten die zijn gedocumenteerd voor elastische DTU - en vCore-pools .

Het aantal databases dat in dichte pools kan worden geplaatst zonder resourceconflicten en prestatieproblemen te veroorzaken, is afhankelijk van het aantal gelijktijdig actieve databases en het resourceverbruik door gebruikersworkloads in elke database. Dit nummer kan na verloop van tijd veranderen wanneer de workloads van gebruikers veranderen.

Als de minimale vCores per database of minimale DTU's per database-instelling is ingesteld op een waarde die groter is dan 0, wordt het maximum aantal databases in de pool impliciet beperkt. Zie Database-eigenschappen voor pool-vCore-databases en Database-eigenschappen voor pool-DTU-databases voor meer informatie.

Wanneer resourceconflicten optreden in een dicht verpakte pool, kunnen klanten een of meer van de volgende acties kiezen om deze te beperken:

• Werkbelasting van query's afstemmen om het resourceverbruik te verminderen of het resourceverbruik over meerdere databases in de loop van de tijd te verdelen.
• Verminder de pooldichtheid door sommige databases naar een andere pool te verplaatsen of door ze zelfstandige databases te maken.
• Schaal de pool omhoog om meer resources te krijgen.

Zie Operationele aanbevelingen verderop in dit artikel voor suggesties over het implementeren van de laatste twee acties. Het verminderen van resourceconflicten biedt zowel gebruikersworkloads als interne processen en zorgt ervoor dat het systeem op betrouwbare wijze het verwachte serviceniveau behoudt.

Resourceverbruik bewaken

Om prestatievermindering als gevolg van conflicten tussen resources te voorkomen, moeten klanten die dichte elastische pools gebruiken proactief het resourceverbruik bewaken en tijdig actie ondernemen als het toenemen van resourceconflicten van invloed is op workloads. Continue bewaking is belangrijk omdat het resourcegebruik in een pool na verloop van tijd verandert, vanwege wijzigingen in de gebruikersworkload, wijzigingen in gegevensvolumes en distributie, wijzigingen in pooldichtheid en wijzigingen in de Azure SQL Database-service.

Azure SQL Database biedt verschillende metrische gegevens die relevant zijn voor dit type bewaking. Het overschrijden van de aanbevolen gemiddelde waarde voor elke metriek geeft aan dat er resourceconflicten in de pool zijn en moet worden aangepakt met behulp van een van de eerder genoemde acties.

Als u een waarschuwing wilt verzenden wanneer het resourcegebruik van de pool (CPU, gegevens-IO, logboek-IO, werkrollen, enzovoort) een drempelwaarde overschrijdt, kunt u waarschuwingen maken via Azure Portal of de PowerShell-cmdlet Add-AzMetricAlertRulev2. Overweeg bij het bewaken van elastische pools ook waarschuwingen te maken voor afzonderlijke databases in de pool, indien nodig in uw scenario. Zie Prestaties van Azure SQL Database bewaken en beheren in een SaaS-app met meerdere tenants voor een voorbeeldscenario voor het bewaken van elastische pools.

Naam van metrische gegevens	Omschrijving	Aanbevolen gemiddelde waarde
avg_instance_cpu_percent	CPU-gebruik van het SQL-proces dat is gekoppeld aan een elastische pool, zoals gemeten door het onderliggende besturingssysteem. Beschikbaar in de sys.dm_db_resource_stats weergave in elke database en in de sys.elastic_pool_resource_stats weergave in de master database. Deze metrische waarde wordt ook verzonden naar Azure Monitor, waar deze een naamsql_instance_cpu_percent heeft en kan worden weergegeven in Azure Portal. Deze waarde is hetzelfde voor elke database in dezelfde elastische pool.	Onder de 70%. Incidentele korte pieken tot 90% kunnen acceptabel zijn.
max_worker_percent	Gebruik van werkthreads . Opgegeven voor elke database in de pool, evenals voor de pool zelf. Er zijn verschillende limieten voor het aantal werkthreads op databaseniveau en op poolniveau wordt daarom aanbevolen om deze metrische gegevens op beide niveaus te bewaken. Beschikbaar in de sys.dm_db_resource_stats weergave in elke database en in de sys.elastic_pool_resource_stats weergave in de master database. Deze metrische waarde wordt ook verzonden naar Azure Monitor, waar deze een naamworkers_percent heeft en kan worden weergegeven in Azure Portal.	Onder de 80%. Pieken tot 100% zorgen ervoor dat verbindingspogingen en query's mislukken.
avg_data_io_percent	IOPS-gebruik voor het lezen en schrijven van fysieke IO. Opgegeven voor elke database in de pool, evenals voor de pool zelf. Er gelden verschillende limieten voor het aantal IOPS op databaseniveau en op poolniveau, waardoor het bewaken van deze metrische gegevens op beide niveaus wordt aanbevolen. Beschikbaar in de sys.dm_db_resource_stats weergave in elke database en in de sys.elastic_pool_resource_stats weergave in de master database. Deze metrische waarde wordt ook verzonden naar Azure Monitor, waar deze een naamphysical_data_read_percent heeft en kan worden weergegeven in Azure Portal.	Onder de 80%. Soms zijn korte pieken tot 100% acceptabel.
avg_log_write_percent	Doorvoergebruik voor schrijf-IO voor transactielogboeken. Opgegeven voor elke database in de pool, evenals voor de pool zelf. Er zijn verschillende limieten voor de logboekdoorvoer op databaseniveau en op poolniveau. Daarom wordt het aanbevolen om deze metrische waarde op beide niveaus te bewaken. Beschikbaar in de sys.dm_db_resource_stats weergave in elke database en in de sys.elastic_pool_resource_stats weergave in de master database. Deze metrische waarde wordt ook verzonden naar Azure Monitor, waar deze een naamlog_write_percent heeft en kan worden weergegeven in Azure Portal. Wanneer deze metrische waarde dicht bij 100% ligt, worden alle databasewijzigingen (INSERT, UPDATE, DELETE, MERGE-instructies, SELECT... INTO, BULK INSERT, enzovoort) zal langzamer zijn.	Onder de 90%. Soms zijn korte pieken tot 100% acceptabel.
oom_per_second	De snelheid van out-of-memory fouten (OOM) in een elastische pool, wat een indicator van geheugendruk is. Beschikbaar in de sys.dm_resource_governor_resource_pools_history_ex weergave. Zie Voorbeelden voor een voorbeeldquery om deze metrische waarde te berekenen. Zie resourcelimieten voor elastische pools met behulp van DTU's of elastische pools met behulp van vCores en los geheugenfouten met Azure SQL Database op voor meer informatie. Als er onvoldoende geheugenfouten optreden, dan raadpleegt u sys.dm_os_out_of_memory_events.	0
avg_storage_percent	Totale opslagruimte die wordt gebruikt door gegevens in alle databases binnen een elastische pool. Bevat geen lege ruimte in databasebestanden. Beschikbaar in de sys.elastic_pool_resource_stats weergave in de master database. Deze metrische waarde wordt ook verzonden naar Azure Monitor, waar deze een naamstorage_percent heeft en kan worden weergegeven in Azure Portal.	Onder de 80%. Kan 100% benaderen voor pools zonder gegevensgroei.
avg_allocated_storage_percent	Totale opslagruimte die wordt gebruikt door databasebestanden in opslag in alle databases binnen een elastische pool. Bevat lege ruimte in databasebestanden. Beschikbaar in de sys.elastic_pool_resource_stats weergave in de master database. Deze metrische waarde wordt ook verzonden naar Azure Monitor, waar deze een naamallocated_data_storage_percent heeft en kan worden weergegeven in Azure Portal.	Onder de 90%. Kan 100% benaderen voor pools zonder gegevensgroei.
tempdb_log_used_percent	Gebruik van transactielogboekruimte in de tempdb database. Hoewel tijdelijke objecten die in een database zijn gemaakt, niet zichtbaar zijn in andere databases in dezelfde elastische pool, tempdb is dit een gedeelde resource voor alle databases in dezelfde pool. Een langlopende of zwevende transactie die tempdb is gestart vanuit de ene database in de pool, kan een groot deel van het transactielogboek verbruiken en fouten veroorzaken voor query's in andere databases in dezelfde pool. Afgeleid van sys.dm_db_log_space_usage - en sys.database_files weergaven. Deze metrische waarde wordt ook verzonden naar Azure Monitor en kan worden weergegeven in Azure Portal. Zie Voorbeelden voor een voorbeeldquery om de huidige waarde van deze metrische waarde te retourneren.	Onder de 50%. Af en toe pieken tot 80% zijn acceptabel.

Naast deze metrische gegevens biedt Azure SQL Database een weergave die werkelijke limieten voor resourcebeheer retourneert, evenals aanvullende weergaven die statistieken over resourcegebruik retourneren op het niveau van de resourcegroep en op het niveau van de workloadgroep.

Weergavenaam	Omschrijving
sys.dm_user_db_resource_governance	Retourneert de werkelijke configuratie- en capaciteitsinstellingen die worden gebruikt door mechanismen voor resourcebeheer in de huidige database of elastische pool.
sys.dm_resource_governor_resource_pools	Retourneert informatie over de huidige resourcegroepstatus, de huidige configuratie van resourcegroepen en cumulatieve statistieken van de resourcegroep.
sys.dm_resource_governor_workload_groups	Hiermee worden cumulatieve statistieken van werkbelastinggroepen en de huidige configuratie van de workloadgroep geretourneerd. Deze weergave kan worden samengevoegd met sys.dm_resource_governor_resource_pools in de kolom om informatie over de pool_id resourcegroep op te halen.
sys.dm_resource_governor_resource_pools_history_ex	Retourneert gebruiksstatistieken voor resourcegroepen voor recente geschiedenis, op basis van het aantal beschikbare momentopnamen. Elke rij vertegenwoordigt een tijdsinterval. De duur van het interval wordt opgegeven in de duration_ms kolom. De delta_ kolommen retourneren de wijziging in elke statistiek tijdens het interval.
sys.dm_resource_governor_workload_groups_history_ex	Retourneert statistieken over het gebruik van workloadgroepen voor recente geschiedenis, op basis van het aantal beschikbare momentopnamen. Elke rij vertegenwoordigt een tijdsinterval. De duur van het interval wordt opgegeven in de duration_ms kolom. De delta_ kolommen retourneren de wijziging in elke statistiek tijdens het interval.

Fooi

Als u een query wilt uitvoeren op deze en andere dynamische beheerweergaven met een andere principal dan serverbeheerder, voegt u deze principal toe aan de ##MS_ServerStateReader##serverfunctie.

Deze weergaven kunnen worden gebruikt om resourcegebruik te bewaken en problemen met resourceconflicten in bijna realtime op te lossen. De werkbelasting van de gebruiker op de primaire en leesbare secundaire replica's, inclusief geo-replica's, wordt geclassificeerd in de SloSharedPool1 resourcegroep en UserPrimaryGroup.DBId[N] de workloadgroep, waar N de database-id-waarde staat.

Naast het bewaken van het huidige resourcegebruik kunnen klanten die dichte pools gebruiken historische resourcegebruiksgegevens onderhouden in een afzonderlijk gegevensarchief. Deze gegevens kunnen worden gebruikt in voorspellende analyses om het resourcegebruik proactief te beheren op basis van historische en seizoensgebonden trends.

Operationele aanbevelingen

Laat voldoende ruimte over voor resources. Als er sprake is van conflicten met resources en prestatievermindering, kan beperking betrekking hebben op het verplaatsen van sommige databases uit de betrokken elastische pool of het omhoog schalen van de pool, zoals eerder is aangegeven. Voor deze acties moeten echter extra rekenresources worden voltooid. Met name voor Premium- en Bedrijfskritieke pools moeten voor deze acties alle gegevens worden overgedragen voor de databases die worden verplaatst, of voor alle databases in de elastische pool als de pool omhoog wordt geschaald. Gegevensoverdracht is een langdurige en resource-intensieve bewerking. Als de pool al onder hoge resourcedruk staat, zal de beperkende bewerking zelf de prestaties nog verder verlagen. In extreme gevallen is het misschien niet mogelijk om resourceconflicten op te lossen via databaseverplaatsing of poolschaal, omdat de vereiste resources niet beschikbaar zijn. In dit geval is het tijdelijk verminderen van de queryworkload voor de betrokken elastische pool mogelijk de enige oplossing.

Klanten die dichte pools gebruiken, moeten de trends in resourcegebruik nauwkeurig controleren zoals eerder is beschreven en actie ondernemen terwijl metrische gegevens binnen de aanbevolen bereiken blijven en er nog steeds voldoende resources in de elastische pool zijn.

Resourcegebruik is afhankelijk van meerdere factoren die in de loop van de tijd veranderen voor elke database en elke elastische pool. Het bereiken van een optimale prijs-/prestatieverhouding in dichte pools vereist continue bewaking en herverdeling, waardoor databases van meer gebruikte pools naar minder gebruikte pools worden verplaatst en nieuwe pools worden gemaakt als dat nodig is om een verhoogde werkbelasting mogelijk te maken.

Notitie

Voor elastische DTU-pools is de eDTU-metrische waarde op poolniveau geen MAX of een SOM van het individuele databasegebruik. Deze wordt afgeleid van het gebruik van verschillende metrische gegevens op poolniveau. Resourcelimieten op groepsniveau kunnen hoger zijn dan limieten op individuele databaseniveau, dus het is mogelijk dat een afzonderlijke database een specifieke resourcelimiet kan bereiken (CPU, gegevens-IO, logboek-IO, enzovoort), zelfs wanneer de eDTU-rapportage voor de pool aangeeft dat er geen limiet is bereikt.

Verplaats 'dynamische' databases niet. Als resourceconflicten op poolniveau voornamelijk worden veroorzaakt door een klein aantal maximaal gebruikte databases, kan het verleidelijk zijn om deze databases te verplaatsen naar een minder gebruikte pool of om zelfstandige databases te maken. Dit doet u echter terwijl een database sterk wordt gebruikt, wordt niet aanbevolen, omdat de verplaatsingsbewerking de prestaties verder verslechtert, zowel voor de database die wordt verplaatst als voor de hele pool. Wacht in plaats daarvan totdat het hoge gebruik afgaat of verplaats minder gebruikte databases in plaats daarvan om de resourcedruk op poolniveau te verlichten. Maar het verplaatsen van databases met een zeer laag gebruik biedt in dit geval geen voordeel, omdat het resourcegebruik op poolniveau niet wezenlijk vermindert.

Maak nieuwe databases in een quarantainegroep. In scenario's waarin nieuwe databases vaak worden gemaakt, zoals toepassingen die gebruikmaken van het tenant-per-databasemodel, bestaat het risico dat een nieuwe database in een bestaande elastische pool onverwacht aanzienlijke resources verbruikt en invloed heeft op andere databases en interne processen in de pool. Maak een afzonderlijke quarantainegroep met voldoende toewijzing van resources om dit risico te beperken. Gebruik deze pool voor nieuwe databases met nog onbekende patronen voor resourceverbruik. Zodra een database in deze pool is gebleven voor een bedrijfscyclus, zoals een week of een maand, en het resourceverbruik ervan bekend is, kan deze worden verplaatst naar een pool met voldoende capaciteit om aan dit extra resourcegebruik te voldoen.

Bewaak zowel gebruikte als toegewezen ruimte. Wanneer toegewezen poolruimte (totale grootte van alle databasebestanden in opslag voor alle databases in een pool) de maximale poolgrootte bereikt, kunnen er out-of-space-fouten optreden. Als toegewezen ruimtetrends hoog zijn en op schema zijn om de maximale poolgrootte te bereiken, zijn de risicobeperkingsopties:

• Sommige databases uit de pool verplaatsen om de totale toegewezen ruimte te verminderen
• Databasebestanden verkleinen om lege toegewezen ruimte in bestanden te verminderen
• De pool omhoog schalen naar een servicedoelstelling met een grotere maximale poolgrootte

Als de gebruikte poolruimte (totale grootte van gegevens in alle databases in een pool, niet inclusief lege ruimte in bestanden) hoog is en op schema staat om de maximale poolgrootte te bereiken, zijn risicobeperkingsopties:

• Sommige databases uit de pool verplaatsen om de totale gebruikte ruimte te verminderen
• Gegevens buiten de database verplaatsen (archiveren) of niet meer benodigde gegevens verwijderen
• Gegevenscompressie implementeren
• De pool omhoog schalen naar een servicedoelstelling met een grotere maximale poolgrootte

Vermijd te veel dichte servers. Azure SQL Database ondersteunt maximaal 5000 databases per server. Klanten die elastische pools met duizenden databases gebruiken, kunnen overwegen om meerdere elastische pools op één server te plaatsen, met het totale aantal databases tot de ondersteunde limiet. Servers met vele duizenden databases zorgen echter voor operationele uitdagingen. Bewerkingen waarvoor alle databases op een server moeten worden opgesomd, bijvoorbeeld het weergeven van databases in de portal, zijn langzamer. Operationele fouten, zoals een onjuiste wijziging van aanmeldingen op serverniveau of firewallregels, zijn van invloed op een groter aantal databases. Onbedoeld verwijderen van de server vereist hulp van Microsoft Ondersteuning om databases op de verwijderde server te herstellen en veroorzaakt een langdurige storing voor alle betrokken databases.

Beperk het aantal databases per server tot een lager aantal dan het maximum dat wordt ondersteund. In veel scenario's is het gebruik van maximaal 1000-2000 databases per server optimaal. Als u de kans op onbedoeld verwijderen van de server wilt verminderen, plaatst u een verwijderingsvergrendeling op de server of de bijbehorende resourcegroep.

Voorbeelden

Instellingen voor de capaciteit van afzonderlijke databases weergeven

Gebruik de sys.dm_user_db_resource_governance dynamische beheerweergave om de werkelijke configuratie- en capaciteitsinstellingen weer te geven die worden gebruikt door resourcebeheer in de huidige database of elastische pool. Zie sys.dm_user_db_resource_governance voor meer informatie.

Voer deze query uit in een database in een elastische pool. Alle databases in de pool hebben dezelfde instellingen voor resourcebeheer.

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

Het totale resourceverbruik van elastische pools bewaken

Gebruik de sys.elastic_pool_resource_stats systeemcatalogusweergave om het resourceverbruik van de hele pool te bewaken. Zie sys.elastic_pool_resource_stats voor meer informatie.

Deze voorbeeldquery om de afgelopen tien minuten weer te geven, moet worden uitgevoerd in de master database van de logische Azure SQL-server die de gewenste elastische pool bevat.

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>';

Het verbruik van afzonderlijke databaseresources bewaken

Gebruik de sys.dm_db_resource_stats weergave dynamisch beheer om het resourceverbruik van afzonderlijke databases te bewaken. Zie sys.dm_db_resource_stats voor meer informatie. Er bestaat één rij voor elke 15 seconden, zelfs als er geen activiteit is. Historische gegevens worden ongeveer één uur bijgehouden.

Deze voorbeeldquery om de laatste 10 minuten aan gegevens weer te geven, moet worden uitgevoerd in de gewenste database.

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

Voor langere bewaartijd met minder frequentie kunt u de volgende query uitvoeren sys.resource_statsin de master database van de logische Azure SQL-server. Zie sys.resource_stats (Azure SQL Database) voor meer informatie. Er bestaat om de vijf minuten één rij en historische gegevens worden twee weken bewaard.

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

Geheugengebruik bewaken

Deze query berekent de oom_per_second metrische gegevens voor elke resourcegroep voor de recente geschiedenis, op basis van het aantal beschikbare momentopnamen. Deze voorbeeldquery helpt bij het identificeren van het recente gemiddelde aantal mislukte geheugentoewijzingen in de pool. Deze query kan worden uitgevoerd in elke database in een elastische pool.

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;

Gebruik van logboekruimte bewaken tempdb

Deze query retourneert de huidige waarde van de tempdb_log_used_percent metrische waarde, met het relatieve gebruik van het transactielogboek ten opzichte van de tempdb maximale toegestane grootte. Deze query kan worden uitgevoerd in elke database in een elastische pool.

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
;

Volgende stappen

• Zie Elastische pools voor een inleiding tot elastische pools om meerdere databases in Azure SQL Database te beheren en te schalen.
• Zie Bewaking en afstemming en prestaties voor meer informatie over het afstemmen van queryworkloads om het resourcegebruik te verminderen.