Denne artikkelen forklarer alle nøkkelpunktene til CPU Affinity Masks i SQL Server.
For å gjøre prosessen med multi-tasking enklere, gjør Microsoft Windows ofte et skifte i prosesstrådene som tilhører forskjellige prosessorer. Dette kan hjelpe når det ses fra et synspunkt av operativsystemet, men dette kan også forsinke ytelsen til applikasjonen når det er stor belastning på systemet. Ettersom prosessorens cache for hver prosess vil bli lastet inn på nytt sammen med dataene. Ytelsen kan forbedres ved å redusere belastningen av prosessorinnlastinger og ved å redusere trådmigreringen som skjer på tvers av prosesser. Denne assosiasjonen som eksisterer mellom en gitt tråd og en prosessor, refereres til en prosessoraffinitet.
Affinitetsmasker for å støtte prosessortilhørighet i SQL Server
In SQL Server prosessoraffinitet støttes av to forskjellige alternativer for affinitetsmasker.
- CPU Affinity Mask (også kalt affinitetsmaske)
- Affinitets I/O-maske
Vi vil i dag holde fokus på Affinity-masker, dvs. CPU Affinity Mask.
Affinitetsmaske
Dette var alternativet som var tilgjengelig i tidligere utgaver av SQL Server som standard og var ansvarlig for dynamisk å kontrollere CPU-tilhørigheten. Dette alternativet i SQL Server kan fortsatt konfigureres selv uten restarting din SQL Server forekomst. Hvis du bruker sp_configure, bør du enten bruke RECONFIGURE eller alternativet RECONFIGURE MED OVERRIDE, når du har satt alternativet for konfigurasjon. Hvis du bruker Express-utgaven av SQL Server da vil du bli pålagt å restart ditt eksempel for å endre affinitetsmasken.
Affinitetsmasker tillater også dynamiske endringer som kan tillate startup og nedleggelse av CPU-planleggere på forespørsel. Disse CPU-planleggerne er ansvarlige for å binde prosesstrådene inne SQL Server. Dette skjer når det er en endring i betingelsene for søknaden; dette kan inkludere tilføyelse av en ny instans. Endringene i affinitetsmaskene er nødvendige også fordi det hjelper med å omfordele belastningen på prosessoren.
Endringer i affinitetsbitmasker
For å introdusere modifikasjoner i Affinity-bitmaskene trenger du SQL Server å gjøre bruk av en helt ny CPU-planlegger og sette den eksisterende på stopp. Denne nye planleggeren vil bare bli brukt for de siste partiene, og de eksisterende partiene vil fortsette å bruke den gamle planleggeren. Arbeiderne må migrere til denne nyopprettede planleggeren.
For å slå av en planlegger må du først sørge for at batchene som for øyeblikket er plassert på denne planleggeren har alle aktivitetene sine fullført. Når en planlegger har blitt stengt, er den merket som frakoblet for å sikre at ingen av de nye batchene er planlagt på den.
Enten du velger å legge til eller fjerne en ny planlegger, vil permanente systemer som sjekkpunkt, låsemonitor, systemoppgavetråd, sammen med signalprosessen fortsette å kjøre på planleggeren når serveren fortsetter å være operativ. Disse permanente systemoppgavene vil ikke migrere dynamisk, for å omfordele prosessorbelastningen for alle disse oppgavene; du må restart forekomsten.
Mens du jobber med komplekse operasjoner eller datamigreringsoppgaver, må du alltid ha et hendig verktøy som kan fikse sql serverdatabase for å håndtere situasjoner.
Forfatterintroduksjon:
Victor Simon er en datagjenopprettingsekspert innen DataNumen, Inc., som er verdensledende innen datagjenopprettingsteknologier, inkludert tilgangsgjenoppretting og sql-programvareprodukter. For mer informasjon besøk www.datanumen. Med
Legg igjen en kommentar