Øjeblikkelig filinitialisering:Virkning under opsætning

For nylig bloggede Erin Stellato (@erinstellato) om den præstationsindvirkning, Instant File Initialization (IFI) kan have, når der oprettes eller gendannes databaser. Hun forklarer, at SQL Server 2016-opsætningen nu giver dig mulighed for at give de relevante rettigheder til SQL Server-tjenesten under installationen (vi talte også om dette i afsnittet CTP 3.0 i Seneste Builds of SQL Server 2016):

Nu kan du aktivere øjeblikkelig filinitialisering under opsætning af SQL Server

Nøglen er en ny mulighed (som du også kan angive i en konfigurationsfil):

Det er rart, at du virkelig kan reducere den tid, det tager at oprette eller gendanne databaser senere, uden at skulle huske at gå ind i gpedit, tildele rettighederne korrekt og genstarte tjenesten. Men en meget større fordel for mig er evnen til at konfigurere større tempdb-filer under opsætningen ved at drage tidlig fordel af IFI.

Nu er der nogle begrænsninger under opsætningen; for eksempel er antallet af tempdb-filer begrænset til 8 (eller antallet af kerner, alt efter hvad der er færrest), og størrelsen af ​​hver fil kan kun nå et max på 1.024 MB. Disse grænser håndhæves i brugergrænsefladen, og jeg tænkte, at jeg måske kunne komme uden om dem ved at angive højere størrelser i en konfigurationsfil til en uovervåget installation, men det virkede heller ikke. (Loggene sagde:"Værdien 8192 for TempDB-filstørrelsen overstiger 1024 MB og kan have indflydelse på installationstiden. Du kan indstille den til en mindre størrelse og ændre den efter installationen.") Personligt tror jeg, at i dag og alder, med hastigheden og størrelsen af ​​det lager, vi kan opnå, er en 1 GB-grænse for datafilstørrelse kunstigt lav. Så jeg indsendte et Connect-forslag:

• Forbind #2457759:tempdb-datafiler bør ikke begrænses til 1024 MB

Og så blev det påpeget, at Brent Ozar (@BrentO) indgav et lignende element tidligere i CTP-cyklussen, hvor grænsen faktisk blev håndhævet som 256 MB i stedet for 1 GB:

• Forbind #1841076 :TempDB-opsætningens begyndelsesstørrelse er for lav

Jeg har ikke nogen monstermaskiner, der kunne understøtte 64 x 1 GB filer, og det ville heller ikke være en realistisk test, så jeg besluttede mig for at teste virkningen af ​​IFI på 8 tempdb datafiler på 1 GB hver. Jeg er en slags old school, så jeg byggede fire forskellige .ini-filer, og jeg har fremhævet de linjer, jeg ville ændre for hver test (jeg ønskede at baseline en minimal installation med 4 x 8 MB datafiler ved hjælp af IFI og ikke, og sammenlign det derefter med 8 x 1.024 MB filer). Da jeg ville køre disse sløjfer flere gange, var det vigtigt at bruge forskellige instansnavne afhængigt af om IFI var aktiveret eller ej, for når du først giver retten til en servicekonto, bliver den ikke fjernet ved blot at fjerne instansen (og jeg kunne have oprettet disse konti uafhængigt, men jeg ønskede at gøre disse tests nemme at reproducere).

Og her er batchfilen, jeg brugte (placeret i samme mappe som konfigurationsfilerne), som installerede og derefter afinstallerede forekomsten ved at bruge hver kombination tre gange, og loggede opsætningstiderne til en tekstfil – ignorerer afinstallation og oprydning.

Et par bemærkninger:

• Du skal muligvis ændre de to linjer fra D:\setup.exe til stien til installationsbiblioteket.
• Du skal muligvis genstarte dit system, før du kører dette.
• Du vil gerne køre batchfilen fra en forhøjet kommandoprompt, så UAC ikke afbryder dig ved hver iteration.

Jeg kørte test på tre forskellige systemer:

• En Windows 10 VM med 4 kerner og SSD-lager
  Basislinjetest på 4 x 8 MB og derefter 4 x 1.024 MB
• En Windows 10 VM med 8 kerner og PCIe-lager
  Basislinjetest på 4 x 8 MB, 4 x 1.024 MB, 8 x 1.024 MB
• En Windows 2012 R2 VM med 16 kerner og et dual-channel RAID 10-array af 8 10K SAS-drev
  Basislinjetest på 4 x 8 MB, 4 x 1.024 MB, 8 x 1.024 MB og 16 x 1.024 MB

Outputfilerne genererede en masse insert-sætninger, jeg kunne indsætte her:

CREATE TABLE #x
(
  [server] varchar(32),
  [test]   varchar(32),
  [start]  time(2),
  [end]    time(2)
);
 
-- inserts pasted here
 
SELECT [server],[test],AVG(DATEDIFF(SECOND,[start],[end])*1.0)
FROM #x
GROUP BY [server],[test];

Her var tiderne på tværs af ti test hver, gennemsnittet og afrundet (klik for at forstørre):

Forudsigeligt bliver IFI vigtig med større filer på langsommere drev

Opsætningen tager lidt over et minut over hele linjen (hvor er det rart at køre opsætning uden administrationsværktøjer). Den eneste afvigelse var egentlig, da filstørrelserne begyndte at blive større på de mekaniske drev og med øjeblikkelig filinitialisering deaktiveret. Jeg kan ikke foregive at være chokeret over dette.

Konklusion

Hvis du er på SSD eller PCIe, kan øjeblikkelig filinitialisering ikke gøre tingene værre, men der er ingen klar fordel under opsætningen, så længe de arkaiske filstørrelsesbegrænsninger for tempdb-datafiler forbliver intakte. Med de nuværende regler synes det ikke muligt at teste denne effekt ud over (1 GB x antallet af tilgængelige kerner). Hvis du er på langsomme mekaniske drev, er der dog en mærkbar forskel, selv når du kun initialiserer 8 GB eller 16 GB data - at nulstilling er ret dyrt, når diskhovederne skal flyttes. Når det er sagt, om opsætningen tager 75 sekunder eller 2 minutter er ret ligegyldigt i den store sammenhæng (medmindre du installerer hundredvis af servere, men ikke automatiserer det af en eller anden grund), så jeg tror, ​​at den største fordel her er bekvemmelighed – ikke at skulle huske at gå, give servicekontoen de nødvendige volumenrettigheder et stykke tid efter, at installationen er lykkedes. Hvis du tænker over det, kan denne nye konfigurationsmulighed faktisk betale sig meget bedre ved automatiserede installationer af et stort antal servere, uden for den tid, der spares under selve installationen.

• Download konfigurationsfilerne og batchfilen

(Min næste test vil tage et kig på den tid, det tager at udvide de eksisterende tempdb-filer til en meget større størrelse end 1.024 MB efter installation .)