🥇Yes, my old laptop is several times more powerful than your production server

Selliseid väiteid kuulsin meie arendajatelt. Kõige huvitavam on see, et see osutus tõeks, alustades pikaajalist uurimist. Jutt käib SQL serveritest, mis jooksutavad meie VMware'is.

Seetõttu on kerge saavutada, et tootmisserver jääks sülearvutile lootusetult alla. Käivitage (mitte tempdb-s ja mitte andmebaasis, kus on aktiveeritud Delayed Durability) järgnev kood:

set nocount on
create table _t (v varchar(100))
declare @n int=300000
while @n>0 begin 
  insert into _t select 'Milline aeglane!' 
  delete from _t
  set @n=@n-1
  end
GO
drop table _t

Minu töölaual võtab see aega 5 sekundit, tootmisserveris – 28 sekundit. Sest SQL peab ootama tehingulogis kirjutamise füüsilise lõpetamise pärast, ja me teeme siin väga lühikesi tehinguid. Ütleme nii, et me surusime suure võimsa kaubiku linna liiklusesse, ja vaatame, kuidas pizza kullerid oma mootorratastel meid kergelt mööda sõidavad — siin ei loe läbivus, vaid ainult latentsus. Ükski võrgu mäluseade, kui palju nulli ka ei oleks selle hinnas, ei suuda saavutada madalamat latentsust kohaliku SSD ees.

(kommentaarides selgus, et ma valetasime — mul on mõlemas kohas viibinud delayed durability. Ilma delayed durability'ta on tulemused:
Töölaua puhul — 39 sekundit, 15K tr/sec, 0,065 ms /io ümmargune reisi aeg.
PROD — 360 sekundit, 1600 tr/sec, 0,6 ms
Pidin tähele panna, et see on liiga kiire)

Siinkohal on meil tegemist Riemanni funktsiooni triviaalsete nullidega triviaalse näitega. Näites, mille mulle arendajad tõid, oli midagi muud. Ma veendusin, et nad on õiged, ja hakkasin näitest eemaldama nende äri loogikaga seotud spetsiifikat. Mingil hetkel sain aru, et võin täielikult visata nende koodi ära ja kirjutada oma — mis demonstreerib sama probleemi — productionis töötab see 3–4 korda aeglasemalt:

create function dbo.isPrime (@n bigint)
returns int
as
  begin
  if @n = 1 return 0
  if @n = 2 return 1
  if @n = 3 return 1
  if @n % 2 = 0 return 0
  declare @sq int
  set @sq = sqrt(@n)+1 -- kontrolli paarituid numbreid kuni ruudust
  declare @dv int = 1
  while @dv < @sq 
    begin
	set @dv=@dv+2
	if @n % @dv = 0 return 0
	end
  return 1
  end
GO
declare @dt datetime set @dt=getdate()
select dbo.isPrime(1000000000000037)
select datediff(ms,@dt,getdate()) as ms
GO

Kui teil on kõik hästi, siis arvutatakse arvu primitiivsuse kontroll 6–7–8 sekundi jooksul. Nii oli mitmel puhul. serverite. Kuid mõnikord võttis kontroll 25–40 sekundit. Mis on huvitav, ei olnud servereid, kus täitmine oleks kestnud näiteks 14 sekundit — kood töötas kas väga kiiresti või väga aeglaselt, ehkki probleem oli, ütleme nii, must-valge.

Mida ma tegin? Vaatasin VMware'i mõõdikuid. Kõik oli korras — ressurssi oli üle, Ready time = 0, kõike jagus, testimise ajal olid nii kiiretel kui ka aeglastel serveritel CPU=100 ühel vCPU-l. Tehtud test Pi arvestamiseks — test näitas samasid tulemusi igas serveris. Must maa muutus järjest selgemaks.

DEV farmist välja pääsedes hakkasin serveritega katsetama. Selgus, et vMotion hostilt hostile võib serverit 'ravida', aga võib ka vastupidi, 'kiire' server muuta 'aeglaseks'. Tundub, et probleem on olemas — mõnel hostil on probleem... aga... ei. Üks virtuaalmasin pidurdas hostis, ütleme, A, aga töötas kiiresti hostis B. Teine virtuaalmasin vastupidi, töötas kiiresti A-s ja pidurdas B-s! Hostis liiklesid tihti nii 'kiired' kui ka 'aeglased' masinad!

Sellest hetkest alates oli õhus selgelt väävli lõhna. Probleemi ei saanud seostada virtuaalmasinaga (näiteks Windowsi uuendustega) — see muutus ju vMotionil "kiireks". Kuid probleem ei saanud olla seotud ka hostiga — sellel võis olla nii "kiireid" kui "aeglaseid" masinaid. Samuti ei olnud see koormusega seotud — mul õnnestus saada "aeglane" masin hostil, kus peale selle ei olnud üldse midagi.

Häda tõttu käivitasin Sysinternalsi Process Exploreri ja vaatasin SQL-i stacki. Aeglaste masinate puhul jäi mulle kohe silma rida:

ntoskrnl.exe!KeSynchronizeExecution+0x5bf6
ntoskrnl.exe!KeWaitForMultipleObjects+0x109d
ntoskrnl.exe!KeWaitForMultipleObjects+0xb3f
ntoskrnl.exe!KeWaitForSingleObject+0x377
ntoskrnl.exe!KeQuerySystemTimePrecise+0x881 < — !!!
ntoskrnl.exe!ObDereferenceObjectDeferDelete+0x28a
ntoskrnl.exe!KeSynchronizeExecution+0x2de2
sqllang.dll!CDiagThreadSafe::PxlvlReplace+0x1a20
… vahelejätetud
sqldk.dll!SystemThread::MakeMiniSOSThread+0xa54
KERNEL32.DLL!BaseThreadInitThunk+0x14
ntdll.dll!RtlUserThreadStart+0x21

See oli juba midagi. Programm oli kirjutatud:

    class Program
    {
        [DllImport("kernel32.dll")]
        static extern void GetSystemTimePreciseAsFileTime(out FILE_TIME lpSystemTimeAsFileTime);

        [StructLayout(LayoutKind.Sequential)]
        struct FILE_TIME
        {
            public int ftTimeLow;
            public int ftTimeHigh;
        }

        static void Main(string[] args)
        {
            for (int i = 0; i < 16; i++)
            {
                int counter = 0;

                var stopwatch = Stopwatch.StartNew();

                while (stopwatch.ElapsedMilliseconds  0)
                {
                    Console.WriteLine("{0}", counter);
                }
            }
        }
    }

See programm demonstreerib veelgi tugevamat aeglust — "kiiretel" masinatel näitab see 16-18 miljonit tsüklit sekundis, samas kui aeglastel — ühe ja poole miljoni või isegi 700 000. See tähendab, et vahe on 10-20 korda (!!!). See oli juba väike võit: igal juhul ei olnud ohtu takerduda Microsofti ja VMware toe vahele, et nad suunaksid üksteisele süüdistusi.

Edasi liikumine peatus — puhkus, tähtsad asjad, viirushaigus ja koormuse järsk tõus. Olen tihti maininud kolleegidele maagilist probleemi, kuid vahel tundus, et nad ei usu mind alati — liiga uskumatud olid väited, et VMware aeglustab koodi 10-20 korda.

Püüdsin ise välja uurida, mis takistab. Vahel tundus, et leidsin lahenduse — kuumplugide sisse ja välja lülitamine, muutmine mälu mahtu või protsessorite arvu tihti muutis masina "kiireks". Kuid mitte igavesti. Siiski selgus, et piisab, kui lihtsalt välja minna ja ratast koputada — st muuta igaühe virtuaalmasina parameetrit

Lõpuks leidsid mu Ameerika kolleegid root cause'i.

Hostid erinevad sageduse poolest!

Reeglina pole see hirmus. Kuid: üleminekul ‘oma’ hostilt ‘teise’ sagedusega hostile peab VMware korrigeerima GetTimePrecise'i tulemusi.
Reeglina pole see hirmus, kui ei satu rakendust, mis küsib täpset aega miljon korda sekundis, nagu SQL server.
Aga isegi see pole hirmus, kuna SQL server ei tee seda sugugi alati (vt Kokkuvõte)

Aga on juhtumeid, kui need lõksud tõeliselt haiget teevad. Jah, kui koputasin ratastele (vahetades midagi VM seadetest), sundisin ma VMware 'ülekalkuleerima' konfiguratsiooni ja aktiivse hosti sagedus muutus 'originaalseks' sageduseks masina jaoks.

Lahendus

www.vmware.com/files/pdf/techpaper/Timekeeping-In-VirtualMachines.pdf

Kui te keelate TSC virtualiseerimise, tagastab TSC lugemine virtuaalmasinast füüsilise masina TSC väärtuse ning TSC kirjutamine virtuaalmasinast ei põhjusta mingit mõju. Virtuaalmasina teisaldamine teisele hostile, selle järsu seiskamise taastamine või hetkeseisule tagasipöördumine põhjustab TSC rikkumist. Mõned külalisoperatsioonisüsteemid ei käivitu või näitavad muid ajahoidmise probleeme, kui TSC virtualiseerimine on keelatud. Minevikus on seda funktsiooni mõnikord soovitatud rakenduste jõudluse parandamiseks, mis loevad TSC-d sageli, kuid virtuaalse TSC jõudlust on praegustes toodetes märkimisväärselt parandatud. Funktsiooni on soovitatud kasutada ka mõõtmiste tegemisel, mis vajavad virtuaalmasinas täpset reaalaega allikat.

Lühidalt öeldes, tuleb lisada parameeter

monitor_control.virtual_rdtsc = FALSE

Kokkuvõte

Te kindlasti küsite: miks SQL kutsub GetTimePrecise nii sageli?

Mul ei ole SQL serveri lähtekoodid, kuid loogika ütleb järgmist. SQL on peaaegu operatsioonisüsteem kooperatiivse konkurentsiga, kus iga lõime peab aeg-ajalt "loomulikult" ootama. Aga kus oleks parem seda teha? Seal, kus on loomulik ooteaeg — lukud või IO. Hästi, aga mis siis, kui me keerame arvutuslikke tsükleid? Siis on ilmne ja peaaegu ainus koht — tõlgendajas (see ei ole päris tõlgendaja), pärast järgmise käsu täitmist.

Reeglina ei kasutata SQL serverit puhaste arvutuste tegemiseks, ning see ei ole probleem. Kuid tsüklid ajutiste tabelitega (mis kohe vahemälustesse salvestatakse) muudavad koodi väga kiiresti täidetavate käskude järjestuseks.

Muide, kui funktsiooni ümbritseda NATIVELY COMPILED, siis see lõpetab ajaküsimise, ja selle kiirus suureneb kümme korda. Aga kuidas on kooperatiivse multitaskinguga? Noh, just natively compiled koodi jaoks tuli SQL-s teha PREEMPTIVE MULTITASKING.

Allikas: habr.com

Jah, minu vana sülearvuti on mitu korda võimsam kui teie tootmisserver.

Lahendus

Kokkuvõte