Omedelbar filinitiering:Inverkan under installationen

Nyligen bloggade Erin Stellato (@erinstellato) om prestandapåverkan Instant File Initialization (IFI) kan ha när man skapar eller återställer databaser. Hon förklarar att installationen av SQL Server 2016 nu ger dig möjligheten att ge lämpliga rättigheter till SQL Server-tjänsten under installationen (vi pratade också om detta i avsnittet CTP 3.0 i Senaste byggnaderna av SQL Server 2016):

Nu kan du aktivera omedelbar filinitiering under installationen av SQL Server

Nyckeln är ett nytt alternativ (som du också kan ange i en konfigurationsfil):

Det är trevligt att du verkligen kan minska den tid det tar att skapa eller återställa databaser senare, utan att behöva komma ihåg att gå in i gpedit, tilldela rättigheterna korrekt och starta om tjänsten. Men en mycket större fördel för mig är möjligheten att konfigurera större tempdb-filer under installationen och dra nytta av IFI tidigt.

Nu finns det några begränsningar under installationen; till exempel är antalet tempdb-filer begränsat till 8 (eller antalet kärnor, beroende på vilket som är färre), och storleken på varje fil kan bara nå max 1 024 MB. Dessa gränser upprätthålls i användargränssnittet, och jag tänkte att jag kanske skulle kunna komma runt dem genom att ange högre storlekar i en konfigurationsfil för en obevakad installation, men det fungerade inte heller. (Loggarna sa:"Värdet 8192 för TempDB-filstorleken överstiger 1024 MB och kan påverka installationstiden. Du kan ställa in den till en mindre storlek och ändra den efter installationen.") Personligen tror jag att i dessa dagar och ålder, med hastigheten och storleken på lagringen vi kan få, är ett 1 GB-tak på datafilstorleken artificiellt låg. Så jag lämnade in ett Connect-förslag:

• Anslut #2457759:tempdb-datafiler bör inte begränsas till 1024 MB

Och sedan påpekades det att Brent Ozar (@BrentO) lämnade in ett liknande föremål tidigare i CTP-cykeln, när gränsen faktiskt upprätthölls som 256 MB istället för 1 GB:

• Anslut #1841076:TempDB-inställningens initiala storlek är för låg

Jag har inga monstermaskiner som kan stödja 64 x 1 GB-filer, och det skulle inte heller vara ett realistiskt test, så jag bestämde mig för att testa effekten av IFI på 8 tempdb-datafiler på 1 GB vardera. Jag är typ av gammal skola, så jag byggde fyra olika .ini-filer, och jag har markerat raderna jag skulle ändra för varje test (jag ville basera en minimal installation med 4 x 8 MB datafiler, med hjälp av IFI och inte, och jämför det sedan med 8 x 1 024 MB filer). Eftersom jag skulle köra dessa slingor flera gånger var det viktigt att använda olika instansnamn beroende på om IFI var aktiverat eller inte, för när du väl har beviljat rätten till ett tjänstekonto så tas det inte bort genom att bara ta bort instansen (och jag kunde ha ställt in dessa konton oberoende, men jag ville göra dessa tester lätta att reproducera).

Och här är batchfilen jag använde (placerad i samma mapp som konfigurationsfilerna), som installerade och sedan avinstallerade instansen med varje kombination tre gånger, och loggade inställningstiderna till en textfil – ignorerar avinstallation och rensning.

Några anteckningar:

• Du kan behöva ändra de två raderna från D:\setup.exe till sökvägen till installationskatalogen.
• Du kan behöva starta om systemet innan du kör detta.
• Du vill köra batchfilen från en förhöjd kommandotolk så att UAC inte avbryter dig vid varje iteration.

Jag körde tester på tre olika system:

• En Windows 10 VM med 4 kärnor och SSD-lagring
  Baslinjetest på 4 x 8 MB och sedan 4 x 1 024 MB
• En Windows 10 virtuell dator med 8 kärnor och PCIe-lagring
  Baslinjetest på 4 x 8 MB, 4 x 1 024 MB, 8 x 1 024 MB
• En Windows 2012 R2 VM med 16 kärnor och en dubbelkanals RAID 10-array med 8 10K SAS-enheter
  Baslinjetest på 4 x 8 MB, 4 x 1 024 MB, 8 x 1 024 MB och 16 x 1 024 MB

Utdatafilerna genererade ett gäng insert-satser som jag kunde klistra in här:

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

Här var tiderna för tio test vardera, medelvärde och avrundade (klicka för att förstora):

Förutsägbart blir IFI viktig med större filer på långsammare enheter

Installationen tar lite över en minut över hela linjen (hur trevligt det är att köra installationen utan hanteringsverktyg). Den enda avvikelsen var egentligen när filstorlekarna började bli större på de mekaniska enheterna och med omedelbar filinitiering inaktiverad. Jag kan inte låtsas vara chockad över detta.

Slutsats

Om du är på SSD eller PCIe kan omedelbar filinitiering inte göra saken värre, men det finns ingen tydlig fördel under installationen, så länge som de arkaiska filstorleksbegränsningarna för tempdb-datafiler förblir intakta. Med de nuvarande reglerna verkar det inte vara möjligt att testa denna effekt utöver (1 GB x antalet tillgängliga kärnor). Om du använder långsamma mekaniska enheter finns det dock en märkbar skillnad, även när du bara initierar 8 GB eller 16 GB data – att nollställningen är ganska dyr när diskhuvudena måste flyttas. Som sagt, huruvida installationen tar 75 sekunder eller 2 minuter är ganska oviktiga i det stora hela (såvida du inte installerar hundratals servrar, men inte automatiserar det av någon anledning), så jag tror att den större fördelen här är bekvämlighet – inte måste komma ihåg att ge servicekontot de volymrättigheter som krävs en tid efter att installationen har lyckats. Om du tänker efter kan det här nya konfigurationsalternativet faktiskt löna sig mycket bättre vid automatiska installationer av ett stort antal servrar, utöver den tid som sparas under själva installationen.

• Ladda ner konfigurationsfilerna och batchfilen

(Mitt nästa test kommer att ta en titt på den tid det tar att utöka de befintliga tempdb-filerna till en mycket större storlek än 1 024 MB efter installationen .)