🥇Môj starý laptop je niekoľkokrát výkonnejší ako váš produkčný server

Takéto obavy som počul od našich vývojárov. Najzaujímavejšie je, že sa to ukázalo ako pravda, čo viedlo k dlhému vyšetrovaniu. Hovoríme o SQL serveroch, ktoré bežia na našom VMware.

V skutočnosti je veľmi jednoduché dosiahnuť, aby production server úplne zaostával za laptopom. Spustite (nie na tempdb a nie na databáze s povolenou oneskorenou trvanlivosťou) kód:

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

Na mojom desktopu to trvá 5 sekúnd, zatiaľ čo na production serveri 28 sekúnd. Pretože SQL musí čakať na fyzické dokončenie zápisu do transakčného logu a my tu robíme veľmi krátke transakcie. Zjednodušene povedané, dostali sme veľký silný kamión do mestského premávky a sledujeme, ako ho rýchlo predbehujú kuriéri na skutroch - tu nie je dôležitý throughput, dôležitá je len latencia. A žiadne sieťové úložisko, nech je jeho cena akokoľvek vysoká, nemôže vyhrať v latencii proti miestnemu SSD.

(v komentároch sa ukázalo, že som klamal - v oboch miestach mám oneskorenú trvanlivosť. Bez oneskorenej trvanlivosti to vychádza:
Desktop - 39 sekúnd, 15K tr/sec, 0.065ms /io roundtrip
PROD - 360 sekúnd, 1600 tr/sec, 0.6ms
Mal som si všimnúť, že bolo príliš rýchlo)

V tomto prípade však máme dočinenia s triviálnymi nulami z tejto Riemannovej funkcie s triviálnym príkladom. V tom príklade, ktorý mi priniesli vývojári, bolo niečo iné. Uistil som sa, že majú pravdu, a začal som čistiť z príkladu všetku ich špecifickosť súvisiacu s obchodnou logikou. V istom momente som si uvedomil, že môžem úplne vyhodiť ich kód a napísať svoj - ktorý demonštruje rovnaký problém - na production beží 3-4 krát pomalšie:

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 -- controluj nepárne čísla až do sqrt
  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

Ak máte všetko v poriadku, kontrola prvočísel bude trvať 6-7-8 sekúnd. Tak to bolo na niekoľkých serverov. Ale na niektorých trvala kontrola 25-40 sekúnd. Zaujímavé je, že neexistovali servery, na ktorých by vykonávanie trvalo napríklad 14 sekúnd - kód fungoval buď veľmi rýchlo, alebo úplne pomaly, to znamená, že problém bol, povedzme, čierno-biely.

Čo som urobil? Pozrel som do metriky VMware. Všetko vyzeralo v poriadku – zdroje boli dostatočné, Ready time = 0, všetko stačilo, počas testu na rýchlych aj pomalých serveroch CPU=100 na jednom vCPU. Vzal som test na výpočet čísla Pi – test ukazoval rovnaké výsledky na akýchkoľvek serveroch. Čoraz viac to vonia po čiernej mágii.

Keď som sa dostal na DEV farmu, začal som experimentovať so servermi. Zistilo sa, že vMotion z hostiteľa na hostiteľa dokáže "vyliečiť" server, ale môže aj naopak, "rýchly" server premeniť na "pomalý". Zjavne toto bude – niektoré hostiteľské servery majú problém... ale... nie. Nejaká virtuálka spomaľovala na hostiteľovi, povedzme A, ale na hostiteľovi B fungovala rýchlo. A iná virtuálka naopak, fungovala rýchlo na A a pomaly na B! Na hostiteľovi často rotovali aj "rýchle" aj "pomalé" mašinky!

Od tohto momentu vzduch jasne zapáchal sírou. Veď problém nemohol byť pripísaný žiadnej virtuálke (napríklad windows patchy) – veď sa stala "rýchlou" pri vMotion. Ale problém nemohol byť ani na hostiteľovi – veď na ňom mohli byť ako "rýchle", tak aj "pomalé" mašinky. Taktiež to nebolo spojené s zaťažením – podarilo sa mi získať "pomalú" mašinu na hostiteľovi, kde okrem nej nebolo nič.

Z beznádeje som spustil Process Explorer od Sysinternals a pozrel som sa na zásobník SQL. Na pomalých mašinkách mi hneď padla do očí táto línia:

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
… preskočené
sqldk.dll!SystemThread::MakeMiniSOSThread+0xa54
KERNEL32.DLL!BaseThreadInitThunk+0x14
ntdll.dll!RtlUserThreadStart+0x21

To už bolo niečo. Program bol napísaný:

    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);
                }
            }
        }
    }

Tento program ukázal ještě výraznější zpomalení - na 'rychlých' strojích ukazuje 16-18 milionů cyklů za sekundu, zatímco na pomalých - jeden a půl milionu, ne-li 700 tisíc. To znamená, že rozdíl činí 10-20krát (!!!). To byla malá výhra: v každém případě tu nebyla hrozba uváznout mezi podporou Microsoftu a VMware, tak aby se vzájemně obviňovali.

Dále pokrok zastavil - dovolená, důležité záležitosti, virusová hysterie a náhlé zvýšení zátěže. Často jsem zmiňoval magický problém kolegům, ale občas se zdálo, že mi ani nevěří - příliš monstruózní bylo tvrzení, že VMware zpomaluje kód 10-20krát.

Snažil jsem se sám zjistit, co zpomaluje. Občas jsem měl pocit, že jsem našel řešení - zapnutí a vypnutí hot plugů, změna velikosti paměti nebo počtu procesorů často proměnila stroj v 'rychlý'. Ale ne navždy. Ale co se ukázalo jako pravda - stačilo vyjít a zaklepat na kolo - to znamená změnit ktokoľvek parametr virtuálního stroje

Nakonec moji američtí kolegové náhle našli hlavní příčinu.

Hostitelé se lišili frekvencí!

Obvykle to není děsivé. Ale: při přesunu z 'domovského' hostitele na hostitele s 'jinou' frekvencí musí VMware upravit výsledek GetTimePrecise.
Obvykle to není problém, pokud nedochází k aplikaci, která žádá přesný čas milionykrát za sekundu, jako SQL server.
Ale ani to není problém, protože SQL server to nedělá vždy (viz Závěr)

Ale jsou případy, kdy tyto pastičky bolestivě udeří. A ano, zaklepáním na kolo (změnou něčeho v nastavení VM) jsem donutil VMware 'přepočítat' konfiguraci a frekvence aktuálního hostitele se stala 'domovskou' frekvencí stroje.

Riešenie

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

Když deaktivujete virtualizaci TSC, čtení TSC z virtuálního stroje vrací hodnotu TSC fyzického stroje a zapisování TSC z virtuálního stroje nemá žádný účinek. Migrace virtuálního stroje na jiný hostitel, obnovení ze zadržovacího stavu nebo návrat k snímku způsobí, že TSC nepřetržitě vyskočí. Některé hostitelské operační systémy se nespustí nebo vykazují další problémy s časoměřením, když je virtualizace TSC zakázána. V minulosti byla tato funkce někdy doporučována k zlepšení výkonu aplikací, které často čtou TSC., ale výkon virtuální TSC byl v aktuálních produktech výrazně zlepšen. Tato funkce byla také doporučena pro měření, která vyžadují přesný zdroj reálného času ve virtuálním stroji.

Stručně řečeno, je potřeba přidat parametr

monitor_control.virtual_rdtsc = FALSE

Záver

Určite sa pýtate: prečo je potrebné častejšie volať GetTimePrecise v SQL?

Nemám prístup k zdrojovým kódom SQL servera, ale logika hovorí toto. SQL je takmer operačný systém s kooperatívnym paralelizmom, kde každý vlákno by malo čas od času "ustúpiť". A kde je najlepšie to urobiť? Tam, kde je prirodzené čakanie — pri zámku alebo IO. Dobre, a čo ak vykonávame výpočtové cykly? Potom je evidentné a takmer jediné miesto, kde sa to deje — v interpreteri (to nie je úplne interpreter), po vykonaní nasledujúcej inštrukcie.

Vo všeobecnosti sa SQL server nepoužíva na vykonávanie čisto výpočtových úloh a to nie je problém. Ale cykly s manipuláciou s rôznymi dočasnými tabuľkami (ktoré sú ihneď do cache pamäte) transformujú kód na sekvenciu veľmi rýchlo vykonávaných príkazov.

Mimochodom, ak obalíte funkciu do NATIVELY COMPILED, prestane žiadať čas a jej rýchlosť sa zvýši desaťnásobne. A čo kooperatívne multitasking? Práve preto bol v SQL pre natively compiled code zavedený PREEMPTIVE MULTITASKING.

Zdroj: habr.com

Áno, môj starý laptop je niekoľkokrát výkonnejší než váš produkčný server

Riešenie

Záver