Dela via

Resurshantering i kompakta elastiska pooler

  • Artikel

Gäller för:Azure SQL Database

Elastiska Pooler i Azure SQL Database är en kostnadseffektiv lösning för att hantera många databaser med varierande resursanvändning. Alla databaser i en elastisk pool delar samma resursallokering, till exempel CPU, minne, arbetstrådar, lagringsutrymme, tempdb, under antagandet att endast en delmängd av databaserna i poolen använder beräkningsresurser vid en viss tidpunkt. Det här antagandet gör att elastiska pooler kan vara kostnadseffektiva. I stället för att betala för alla resurser som varje enskild databas kan behöva, betalar kunderna för en mycket mindre uppsättning resurser som delas mellan alla databaser i poolen.

Resursstyrning

Resursdelning kräver att systemet noggrant kontrollerar resursanvändningen för att minimera effekten "bullriga grannar", där en databas med hög resursförbrukning påverkar andra databaser i samma elastiska pool. Azure SQL Database uppnår dessa mål genom att implementera resursstyrning. Samtidigt måste systemet tillhandahålla tillräckligt med resurser för funktioner som hög tillgänglighet och haveriberedskap (HADR), säkerhetskopiering och återställning, övervakning, Query Store, automatisk justering osv. att fungera tillförlitligt.

Det primära designmålet för elastiska pooler är att vara kostnadseffektivt. Av den anledningen tillåter systemet avsiktligt kunder att skapa kompakta pooler, dvs. pooler med antalet databaser som närmar sig eller som högsta tillåtna, men med en måttlig allokering av beräkningsresurser. Av samma anledning reserverar systemet inte alla potentiellt nödvändiga resurser för sina interna processer, men tillåter resursdelning mellan interna processer och användararbetsbelastningar.

Med den här metoden kan kunderna använda kompakta elastiska pooler för att uppnå tillräcklig prestanda och stora kostnadsbesparingar. Men om arbetsbelastningen mot många databaser i en tät pool är tillräckligt intensiv blir resurskonkurrationen betydande. Resurskonkurration minskar användarens arbetsbelastningsprestanda och kan påverka interna processer negativt.

Viktigt!

I täta pooler med många aktiva databaser är det kanske inte möjligt att öka antalet databaser i poolen upp till det maximala antal som dokumenterats för elastiska DTU - och vCore-pooler .

Antalet databaser som kan placeras i kompakta pooler utan att orsaka problem med resurskonkurrering och prestanda beror på antalet samtidiga aktiva databaser och på resursförbrukningen för användararbetsbelastningar i varje databas. Det här antalet kan ändras med tiden när användararbetsbelastningarna ändras.

Om inställningen minsta virtuella kärnor per databas eller min DTU:er per databas har angetts till ett värde som är större än 0 begränsas dessutom det maximala antalet databaser i poolen implicit. Mer information finns i Databasegenskaper för pooldatabaser och databasegenskaper för poolade DTU-databaser.

När resurskonkurration inträffar i en tätt packad pool kan kunderna välja en eller flera av följande åtgärder för att minimera den:

  • Justera frågearbetsbelastningen för att minska resursförbrukningen eller sprida resursförbrukning över flera databaser över tid.
  • Minska pooldensiteten genom att flytta vissa databaser till en annan pool eller genom att göra dem till fristående databaser.
  • Skala upp poolen för att få fler resurser.

Förslag på hur du implementerar de två sista åtgärderna finns i Driftrekommendationer senare i den här artikeln. Att minska resurskonkurrationen gynnar både användararbetsbelastningar och interna processer och gör att systemet på ett tillförlitligt sätt kan upprätthålla den förväntade servicenivån.

Övervaka resursförbrukning

För att undvika prestandaförsämring på grund av resurskonkurration bör kunder som använder täta elastiska pooler proaktivt övervaka resursförbrukningen och vidta åtgärder i tid om ökad resurskonkurring börjar påverka arbetsbelastningarna. Kontinuerlig övervakning är viktigt eftersom resursanvändningen i en pool ändras över tid på grund av ändringar i användararbetsbelastningen, ändringar i datavolymer och distribution, ändringar i pooldensiteten och ändringar i Azure SQL Database-tjänsten.

Azure SQL Database innehåller flera mått som är relevanta för den här typen av övervakning. Om du överskrider det rekommenderade genomsnittsvärdet för varje mått indikerar det resurskonkurration i poolen och bör åtgärdas med någon av de åtgärder som nämnts tidigare.

Om du vill skicka en avisering när resursutnyttjandet för poolen (CPU, data-I/O, logg-I/O, arbetare osv.) överskrider ett tröskelvärde kan du överväga att skapa aviseringar via Azure-portalen eller PowerShell-cmdleten Add-AzMetricAlertRulev2 . När du övervakar elastiska pooler bör du även överväga att skapa aviseringar för enskilda databaser i poolen om det behövs i ditt scenario. Ett exempelscenario för övervakning av elastiska pooler finns i Övervaka och hantera prestanda för Azure SQL Database i en SaaS-app med flera klientorganisationer.

Måttnamn Beskrivning Rekommenderat genomsnittsvärde
avg_instance_cpu_percent CPU-användning av SQL-processen som är associerad med en elastisk pool, mätt med det underliggande operativsystemet. Tillgänglig i vyn sys.dm_db_resource_stats i varje databas och i sys.elastic_pool_resource_stats-vyn i master databasen. Det här måttet skickas också till Azure Monitor, där det hetersql_instance_cpu_percent, och kan visas i Azure-portalen. Det här värdet är detsamma för varje databas i samma elastiska pool. Under 70 %. Enstaka korta toppar upp till 90 % kan vara acceptabla.
max_worker_percent Användning av arbetstråd . Tillhandahålls för varje databas i poolen samt för själva poolen. Det finns olika gränser för antalet arbetstrådar på databasnivå, och på poolnivå rekommenderas därför övervakning av det här måttet på båda nivåerna. Tillgänglig i vyn sys.dm_db_resource_stats i varje databas och i sys.elastic_pool_resource_stats-vyn i master databasen. Det här måttet skickas också till Azure Monitor, där det heterworkers_percent, och kan visas i Azure-portalen. Under 80 %. Toppar på upp till 100 % gör att anslutningsförsök och frågor misslyckas.
avg_data_io_percent IOPS-användning för fysisk I/O för läsning och skrivning. Tillhandahålls för varje databas i poolen samt för själva poolen. Det finns olika gränser för antalet IOPS på databasnivå, och på poolnivå rekommenderas därför övervakning av det här måttet på båda nivåerna. Tillgänglig i vyn sys.dm_db_resource_stats i varje databas och i sys.elastic_pool_resource_stats-vyn i master databasen. Det här måttet skickas också till Azure Monitor, där det heterphysical_data_read_percent, och kan visas i Azure-portalen. Under 80 %. Enstaka korta toppar upp till 100 % kan vara acceptabla.
avg_log_write_percent Användning av dataflöde för transaktionsloggens skriv-I/O. Tillhandahålls för varje databas i poolen samt för själva poolen. Det finns olika gränser för loggdataflödet på databasnivå, och på poolnivå rekommenderas därför övervakning av det här måttet på båda nivåerna. Tillgänglig i vyn sys.dm_db_resource_stats i varje databas och i sys.elastic_pool_resource_stats-vyn i master databasen. Det här måttet skickas också till Azure Monitor, där det heterlog_write_percent, och kan visas i Azure-portalen. När det här måttet är nära 100 %, alla databasändringar (INSERT, UPDATE, DELETE, MERGE-instruktioner, SELECT ... IN I, MASSINFOGNING osv.) blir långsammare. Under 90 %. Enstaka korta toppar upp till 100 % kan vara acceptabla.
oom_per_second Frekvensen för OOM-fel (out-of-memory) i en elastisk pool, vilket är en indikator på minnesbelastning. Tillgänglig i vyn sys.dm_resource_governor_resource_pools_history_ex . Se Exempel för en exempelfråga för att beräkna det här måttet. Mer information finns i resursbegränsningar för elastiska pooler med DTU:er eller elastiska pooler med virtuella kärnor och Felsöka minnesfel med Azure SQL Database. Om det uppstår minnesfel kan du läsa sys.dm_os_out_of_memory_events. 0
avg_storage_percent Totalt lagringsutrymme som används av data i alla databaser i en elastisk pool. Innehåller inte tomt utrymme i databasfiler. Tillgänglig i sys.elastic_pool_resource_stats-vyn i master databasen. Det här måttet skickas också till Azure Monitor, där det heterstorage_percent, och kan visas i Azure-portalen. Under 80 %. Kan närma sig 100 % för pooler utan datatillväxt.
avg_allocated_storage_percent Totalt lagringsutrymme som används av databasfiler i lagring i alla databaser i en elastisk pool. Innehåller tomt utrymme i databasfiler. Tillgänglig i sys.elastic_pool_resource_stats-vyn i master databasen. Det här måttet skickas också till Azure Monitor, där det heterallocated_data_storage_percent, och kan visas i Azure-portalen. Under 90 %. Kan närma sig 100 % för pooler utan datatillväxt.
tempdb_log_used_percent Användning av transaktionsloggutrymme i tempdb databasen. Även om temporära objekt som skapats i en databas inte visas i andra databaser i samma elastiska pool, tempdb är en delad resurs för alla databaser i samma pool. En tidskrävande eller överbliven transaktion som tempdb startats från en databas i poolen kan förbruka en stor del av transaktionsloggen och orsaka fel för frågor i andra databaser i samma pool. Härledd från sys.dm_db_log_space_usage - och sys.database_files vyer. Det här måttet skickas också till Azure Monitor och kan visas i Azure-portalen. Se Exempel för en exempelfråga för att returnera det aktuella värdet för det här måttet. Under 50 %. Enstaka toppar upp till 80 % är acceptabla.

Utöver dessa mått tillhandahåller Azure SQL Database en vy som returnerar faktiska resursstyrningsgränser, samt ytterligare vyer som returnerar resursanvändningsstatistik på resurspoolsnivå och på arbetsbelastningsgruppsnivå.

Vynamn Beskrivning
sys.dm_user_db_resource_governance Returnerar faktiska konfigurations- och kapacitetsinställningar som används av resursstyrningsmekanismer i den aktuella databasen eller den elastiska poolen.
sys.dm_resource_governor_resource_pools Returnerar information om det aktuella resurspooltillståndet, den aktuella konfigurationen av resurspooler och kumulativ resurspoolsstatistik.
sys.dm_resource_governor_workload_groups Returnerar kumulativ statistik för arbetsbelastningsgrupper och den aktuella konfigurationen av arbetsbelastningsgruppen. Den här vyn kan kopplas till sys.dm_resource_governor_resource_pools i pool_id kolumnen för att hämta information om resurspoolen.
sys.dm_resource_governor_resource_pools_history_ex Returnerar resurspoolens användningsstatistik för den senaste historiken, baserat på antalet tillgängliga ögonblicksbilder. Varje rad representerar ett tidsintervall. Varaktigheten för intervallet anges i duration_ms kolumnen. Kolumnerna delta_ returnerar ändringen i varje statistik under intervallet.
sys.dm_resource_governor_workload_groups_history_ex Returnerar arbetsbelastningsgruppens användningsstatistik för den senaste historiken, baserat på antalet tillgängliga ögonblicksbilder. Varje rad representerar ett tidsintervall. Varaktigheten för intervallet anges i duration_ms kolumnen. Kolumnerna delta_ returnerar ändringen i varje statistik under intervallet.

Dricks

Om du vill köra frågor mot dessa och andra dynamiska hanteringsvyer med ett annat huvudnamn än serveradministratören lägger du till det här huvudkontot i serverrollen##MS_ServerStateReader##.

Dessa vyer kan användas för att övervaka resursutnyttjande och felsöka resurskonkurrering nästan i realtid. Användararbetsbelastningen på de primära och läsbara sekundära replikerna, inklusive geo-repliker, klassificeras i resurspoolen SloSharedPool1 och UserPrimaryGroup.DBId[N] arbetsbelastningsgruppen, där N står för databas-ID-värdet.

Förutom att övervaka aktuell resursanvändning kan kunder som använder täta pooler underhålla historiska resursanvändningsdata i ett separat datalager. Dessa data kan användas i förutsägelseanalys för att proaktivt hantera resursutnyttjande baserat på historiska och säsongsmässiga trender.

Driftrekommendationer

Lämna tillräckligt med resursutrymme. Om resurskonkurration och prestandaförsämring inträffar kan det innebära att vissa databaser flyttas från den berörda elastiska poolen eller att poolen skalas upp, som tidigare nämnts. Dessa åtgärder kräver dock ytterligare beräkningsresurser för att slutföras. I synnerhet för premium- och affärskritiska pooler kräver dessa åtgärder överföring av alla data för de databaser som flyttas, eller för alla databaser i den elastiska poolen om poolen skalas upp. Dataöverföring är en tidskrävande och resursintensiv åtgärd. Om poolen redan är under högt resurstryck försämrar själva åtgärdsåtgärden prestanda ytterligare. I extrema fall kanske det inte går att lösa resurskonkurrensen via databasflytt eller uppskalning av pool eftersom de resurser som krävs inte är tillgängliga. I det här fallet kan det vara den enda lösningen att tillfälligt minska frågearbetsbelastningen i den berörda elastiska poolen.

Kunder som använder kompakta pooler bör noggrant övervaka resursanvändningstrender enligt beskrivningen tidigare och vidta åtgärder medan måtten ligger kvar inom de rekommenderade intervallen och det fortfarande finns tillräckligt med resurser i den elastiska poolen.

Resursanvändningen beror på flera faktorer som ändras över tid för varje databas och varje elastisk pool. För att uppnå optimalt pris-/prestandaförhållande i kompakta pooler krävs kontinuerlig övervakning och ombalansering, som flyttar databaser från mer använda pooler till mindre använda pooler och skapar nya pooler efter behov för att hantera ökad arbetsbelastning.

Kommentar

För elastiska DTU-pooler är eDTU-måttet på poolnivå inte max eller summa för individuell databasanvändning. Det härleds från användningen av olika mått på poolnivå. Resursgränser på poolnivå kan vara högre än enskilda databasnivågränser så det är möjligt att en enskild databas kan UPPnå en specifik resursgräns (CPU, data-I/O, logg-I/O osv.), även när eDTU-rapporteringen för poolen anger att ingen gräns har uppnåtts.

Flytta inte "heta" databaser. Om resurskonkurrens på poolnivå främst orsakas av ett litet antal databaser med hög användning kan det vara frestande att flytta dessa databaser till en mindre utnyttjad pool eller göra dem till fristående databaser. Detta rekommenderas dock inte när en databas fortfarande är mycket utnyttjad, eftersom flyttåtgärden försämrar prestandan ytterligare, både för databasen som flyttas och för hela poolen. Vänta i stället tills hög användning avtar eller flytta mindre använda databaser i stället för att minska resursbelastningen på poolnivå. Men att flytta databaser med mycket låg användning ger ingen fördel i det här fallet, eftersom det inte väsentligt minskar resursanvändningen på poolnivå.

Skapa nya databaser i en "karantänpool". I scenarier där nya databaser skapas ofta, till exempel program som använder modellen klient-per-databas, finns det risk för att en ny databas som placeras i en befintlig elastisk pool oväntat förbrukar betydande resurser och påverkar andra databaser och interna processer i poolen. För att minska den här risken skapar du en separat "karantänpool" med omfattande allokering av resurser. Använd den här poolen för nya databaser med ännu okända resursförbrukningsmönster. När en databas har stannat i den här poolen under en konjunkturcykel, till exempel en vecka eller en månad, och dess resursförbrukning är känd, kan den flyttas till en pool med tillräcklig kapacitet för att hantera den här extra resursanvändningen.

Övervaka både använt och allokerat utrymme. När allokerat poolutrymme (total storlek för alla databasfiler i lagring för alla databaser i en pool) når den maximala poolstorleken, kan fel med out-of-space uppstå. Om allokerade utrymmestrender är höga och är på rätt spår för att nå maximal poolstorlek, inkluderar alternativ för minskning:

  • Flytta vissa databaser från poolen för att minska det totala allokerade utrymmet
  • Krymp databasfiler för att minska det tomma allokerade utrymmet i filer
  • Skala upp poolen till ett tjänstmål med en större maximal poolstorlek

Om använt poolutrymme (total storlek på data i alla databaser i en pool, inte inklusive tomt utrymme i filer) trender hög och är på rätt spår för att nå maximal poolstorlek, inkluderar minskningsalternativ:

  • Flytta vissa databaser från poolen för att minska det totala använda utrymmet
  • Flytta (arkivera) data utanför databasen eller ta bort data som inte längre behövs
  • Implementera datakomprimering
  • Skala upp poolen till ett tjänstmål med en större maximal poolstorlek

Undvik alltför täta servrar. Azure SQL Database stöder upp till 5 000 databaser per server. Kunder som använder elastiska pooler med tusentals databaser kan överväga att placera flera elastiska pooler på en enda server, med det totala antalet databaser upp till gränsen som stöds. Servrar med tusentals databaser skapar dock driftsutmaningar. Åtgärder som kräver uppräkning av alla databaser på en server, till exempel att visa databaser i portalen, blir långsammare. Driftfel, till exempel felaktig ändring av inloggningar på servernivå eller brandväggsregler, påverkar ett större antal databaser. Oavsiktlig borttagning av servern kräver hjälp från Microsoft Support för att återställa databaser på den borttagna servern och orsakar ett långvarigt avbrott för alla berörda databaser.

Begränsa antalet databaser per server till ett lägre antal än det högsta antal som stöds. I många scenarier är det optimalt att använda upp till 1 000–2 000 databaser per server. Om du vill minska sannolikheten för oavsiktlig serverborttagning placerar du ett borttagningslås på servern eller dess resursgrupp.

Exempel

Visa kapacitetsinställningar för enskilda databaser

sys.dm_user_db_resource_governance Använd vyn dynamisk hantering för att visa de faktiska konfigurations- och kapacitetsinställningarna som används av resursstyrning i den aktuella databasen eller den elastiska poolen. Mer information finns i sys.dm_user_db_resource_governance.

Kör den här frågan i valfri databas i en elastisk pool. Alla databaser i poolen har samma inställningar för resursstyrning.

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

Övervaka övergripande resursförbrukning för elastisk pool

sys.elastic_pool_resource_stats Använd systemkatalogvyn för att övervaka resursförbrukningen för hela poolen. Mer information finns i sys.elastic_pool_resource_stats.

Den här exempelfrågan för att visa de senaste 10 minuterna ska köras i databasen för master den logiska Azure SQL-servern som innehåller den önskade elastiska poolen.

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

Övervaka resursförbrukning för enskilda databaser

sys.dm_db_resource_stats Använd vyn dynamisk hantering för att övervaka resursförbrukningen för enskilda databaser. Mer information finns i sys.dm_db_resource_stats. Det finns en rad var 15:e sekund, även om det inte finns någon aktivitet. Historiska data bevaras i ungefär en timme.

Den här exempelfrågan för att visa de senaste 10 minuterna av data ska köras i den önskade databasen.

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

För längre kvarhållningstid med mindre frekvens bör du överväga följande fråga på sys.resource_stats, kör i master databasen för den logiska Azure SQL-servern. Mer information finns i sys.resource_stats (Azure SQL Database). En rad finns var femte minut och historiska data bevaras i två veckor.

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

Övervaka minnesanvändning

Den här frågan beräknar måttet oom_per_second för varje resurspool för den senaste historiken, baserat på antalet tillgängliga ögonblicksbilder. Den här exempelfrågan hjälper dig att identifiera det senaste genomsnittliga antalet misslyckade minnesallokeringar i poolen. Den här frågan kan köras i valfri databas i en elastisk 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;

Övervaka tempdb loggutrymmesanvändning

Den här frågan returnerar måttets tempdb_log_used_percent aktuella värde, som visar den relativa användningen av transaktionsloggen tempdb i förhållande till dess maximala tillåtna storlek. Den här frågan kan köras i valfri databas i en elastisk 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
;

Nästa steg