Resurshantering i kompakta elastiska pooler

GÄLLER FÖR: Azure SQL Database

Azure SQL Database elastiska pooler är en kostnadseffektiv lösning för att hantera många databaser med varierande resursanvändning. Alla databaser i en elastisk pool delar samma allokering av resurser, till exempel processor, minne, arbetstrådar, lagringsutrymme, tempdb, med antagandet att endast en delmängd av databaserna i poolen kommer att använda beräkningsresurser vid en given 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 "störande granne"-effekten, där en databas med hög resursförbrukning påverkar andra databaser i samma elastiska pool. Samtidigt måste systemet tillhandahålla tillräckliga resurser för funktioner som hög tillgänglighet och haveriberedskap (HADR), säkerhetskopiering och återställning, övervakning, Query Store, automatisk justering osv. för att fungera på ett tillförlitligt sätt.

Azure SQL Database uppnår dessa mål genom att använda flera resursstyrningsmekanismer, inklusive Windows-jobbobjekt för resursstyrning på processnivå, Windows File Server Resource Manager (FSRM) för lagringskvothantering och en modifierad och utökad version av SQL Server Resource Governor som ska implementeras resursstyrning i SQL Database.

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

Med den här metoden kan kunder använda kompakta elastiska pooler för att uppnå tillräcklig prestanda och stora kostnadsbesparingar. Men om arbetsbelastningen mot många databaser i en kompakt pool är tillräckligt intensiv blir resurs konkurrens betydande. Resursförseningar minskar prestanda för användararbetsbelastningar och kan påverka interna processer negativt.

När resursknäckning uppstår i en kompakt paketerad pool kan kunder välja en eller flera av följande åtgärder för att åtgärda problemet:

• Finjustera frågearbetsbelastningen för att minska resursförbrukningen eller sprida resursförbrukningen ö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å senaste åtgärderna finns i Driftrekommendationer längre fram i den här artikeln. Att minska resursföruttrycket innebär både användararbetsbelastningar och interna processer och gör att systemet på ett tillförlitligt sätt kan upprätthålla förväntad servicenivå.

Övervaka resursförbrukning

För att undvika prestandaförsämring på grund av resursförsämring bör kunder som använder kompakta elastiska pooler proaktivt övervaka resursförbrukningen och vidta åtgärder i rätt tid om ökad resursförsämring börjar påverka arbetsbelastningar. 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 pooldensitet 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 det rekommenderade genomsnittliga värdet för varje mått överskrids indikerar det resursinnehållet i poolen och bör åtgärdas med någon av de åtgärder som nämns ovan.

Förutom dessa mått ger Azure SQL Database en vy som returnerar faktiska resursstyrningsgränser, samt ytterligare vyer som returnerar statistik om resursutnyttjande på resurspoolsnivå och på arbetsbelastningsgruppsnivå.

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

Förutom att övervaka den aktuella resursanvändningen kan kunder som använder kompakta pooler lagra 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 trender och säsongstrender.

Driftrekommendationer

Lämna tillräckligt med utrymme för resursen. Om resursförsämring och prestandaförsämring inträffar kan åtgärder omfatta att flytta vissa databaser från den berörda elastiska poolen eller skala upp poolen, som nämnts tidigare. Dessa åtgärder kräver dock ytterligare beräkningsresurser för att slutföras. I synnerhet för Premium och Affärskritisk-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 långvarig och resursintensiv åtgärd. Om poolen redan är under hög resurstryck kommer själva åtgärdsåtgärden att försämra prestanda ytterligare. I extrema fall kanske det inte går att lösa resursinnehållet via databasflyttning eller poolskalning eftersom de nödvändiga resurserna inte är tillgängliga. I det här fallet kan en tillfällig minskning av frågearbetsbelastningen i den berörda elastiska poolen vara den enda lösningen.

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

Resursutnyttjandet 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.

Flytta inte "heta" databaser. Om resursinnehållet på poolnivå främst orsakas av ett litet antal högutnyttjade databaser kan det vara lockande att flytta dessa databaser till en mindre utnyttjad pool eller göra dem till fristående databaser. Men att göra detta medan en databas fortfarande används i hög grad rekommenderas inte eftersom flyttåtgärden försämrar prestandan ytterligare, både för databasen som flyttas och för hela poolen. I stället kan du antingen vänta tills hög användning minskar eller flytta mindre använda databaser i stället för att minska resurstrycket på poolnivå. Men att flytta databaser med mycket låg användning ger ingen fördel i det här fallet, eftersom det inte minskar resursutnyttjandet på poolnivå avsevärt.

Skapa nya databaser i en "karantän"-pool. I scenarier där nya databaser skapas ofta, till exempel program som använder klient-per-databas-modellen, finns det risk 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 kvar i den här poolen under en affärscykel, 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 ytterligare resursanvändningen.

Övervaka både använt och allokerat utrymme. När allokerat poolutrymme (total storlek för alla databasfiler i lagringsutrymmet för alla databaser i en pool) når den maximala poolstorleken kan det uppstå utrymmesfel. Om allokerat utrymmestrender är högt och är på väg att nå maximal poolstorlek kan du bland annat välja mellan följande alternativ:

• 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, utan att inkludera tomt utrymme i filer) är trenderna höga och är på väg att nå maximal poolstorlek, omfattar åtgärdsalternativen:

• 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 kompakta servrar. Azure SQL Database har stöd för 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 den gräns som stöds. Servrar med tusentals databaser skapar dock driftutmaningar. Åtgärder som kräver uppräkning av alla databaser på en server, till exempel visning av databaser i portalen, går långsammare. Driftfel, till exempel felaktiga ändringar 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 att återställa databaser på den borttagna servern, vilket leder till ett långvarigt avbrott för alla berörda databaser.

Vi rekommenderar att du begränsar antalet databaser per server till ett lägre antal än det högsta 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

Övervaka minnesanvändning

Den här frågan beräknar oom_per_second måttet för varje resurspool under de senaste 32 minuterna. 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 det aktuella värdet för tempdb_log_used_percent måttet, som visar den relativa användningen av tempdb transaktionsloggen i förhållande till den högsta tillåtna storleken. 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

• En introduktion till elastiska pooler finns i Elastiska pooler som hjälper dig att hantera och skala flera databaser i Azure SQL Database.
• Information om hur du finjusterar frågearbetsbelastningar för att minska resursutnyttjandet finns i Övervakning och justeringsamt Övervakning och prestandajustering.