Mao gyud ni ang mga reklamo nga akong nadunggan gikan sa among mga developers. Ang labing makaiikag nga butang mao nga kini nahimo nga tinuod, nga nagpatungha sa usa ka taas nga imbestigasyon. Maghisgot kami bahin sa mga SQL server nga nagdagan sa VMware.
Sa tinuud, dali nga masiguro nga ang server sa produksiyon walaβy paglaum sa luyo sa laptop. Ipatuman (dili sa tempdb ug dili sa database nga adunay Delayed Durability) ang code:
set nocount on
create table _t (v varchar(100))
declare @n int=300000
while @n>0 begin
insert into _t select 'What a slowpoke!'
delete from _t
set @n=@n-1
end
GO
drop table _t
Sa akong desktop nagkinahanglan kini og 5 segundos, ug sa production server nagkinahanglan kini og 28 segundos. Tungod kay kinahanglan maghulat ang SQL sa pisikal nga pagtapos sa pagsulod sa log sa transaksyon, ug naghimo kami labi ka mubu nga mga transaksyon dinhi. Sa laktod nga pagkasulti, nagmaneho kami usa ka dako, kusgan nga trak sa trapiko sa lungsod, ug gitan-aw nga kini dali nga naapsan sa mga tawo nga naghatud sa pizza sa mga scooter - ang throughput dili hinungdanon dinhi, ang latency lang ang hinungdanon. Ug walaβy pagtipig sa network, bisan kung pila ang mga zero sa presyo niini, makapildi sa lokal nga SSD sa mga termino sa latency.
(sa mga komento nahimo nga namakak ko - nalangan nako ang durability sa duha ka lugar.
Desktop - 39 segundos, 15K tr/sec, 0.065ms/io roundtrip
PROD - 360 segundos, 1600 tr/sec, 0.6ms
Nakabantay unta ko nga paspas kaayo)
Bisan pa, sa kini nga kaso kita nag-atubang sa mga trivial nga mga zero sa Riemann zeta function nga adunay usa ka gamay nga pananglitan. Sa pananglitan nga gidala kanako sa mga developer, lahi kini. Nakombinsir ko nga husto sila, ug nagsugod sa pagtangtang gikan sa panig-ingnan sa tanan nilang mga detalye nga may kalabutan sa lohika sa negosyo. Sa pila ka punto nakaamgo ko nga mahimo nakong hingpit nga ilabay ang ilang code ug isulat ang akong kaugalingon - nga nagpakita sa parehas nga problema - sa produksiyon kini nagdagan 3-4 ka beses nga hinay:
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 -- check odds up to 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
GOKung maayo ang tanan, nan ang pagsusi sa primality sa usa ka numero molungtad og 6-7-8 segundos. Nahitabo kini sa daghang mga server. Apan sa pipila, ang tseke mikabat og 25-40 segundos. Makapainteres, walaβy mga server kung diin ang pagpatay, ingnon ta, 14 segundos - ang code nagtrabaho bisan kadali o hinay kaayo, nga mao, ang problema, ingnon ta, itom ug puti.
Unsa akong nabuhat? Gigamit nga VMware metrics. Maayo ra ang tanan didto - adunay daghang mga kahinguhaan, Panahon nga andam = 0, adunay igo sa tanan, sa panahon sa pagsulay sa paspas ug hinay nga mga server CPU = 100 sa usa ka vCPU. Nagkuha ako usa ka pagsulay aron makalkulo ang numero nga Pi - ang pagsulay nagpakita sa parehas nga mga resulta sa bisan unsang server. Ang baho sa black magic nahimong mas kusog ug mas kusog.
Sa dihang nakaabot na ko sa DEV farm, nagsugod ko sa pagdula sa mga server. Nahibal-an nga ang vMotion gikan sa host ngadto sa host mahimong "makaayo" sa usa ka server, apan mahimo usab nga himuon ang usa ka "paspas" nga server nga usa ka "hinay". Morag mao kini - ang ubang mga host adunay problema ... apan ... dili. Ang ubang virtual machine hinay sa host, ingna ang A, apan miandar dayon sa host B. Ug laing virtual machine, sa sukwahi, miandar dayon sa A ug mihinay sa B! Ang "paspas" ug "hinay" nga mga makina kanunay nga nagtuyok sa host!
Sukad niadto, adunay usa ka lahi nga baho sa asupre sa hangin. Human sa tanan, ang problema dili mahimong ikapasangil sa virtual machine (Windows patch, pananglitan) - human sa tanan, kini nahimong "paspas" uban sa vMotion. Apan ang problema dili usab mahimong ipasangil sa host - pagkahuman, mahimo nga adunay "paspas" ug "hinay" nga mga makina. Usab, wala kini kalabutan sa pagkarga - nakakuha ako usa ka "hinay" nga makina sa host, diin walaβy bisan unsa gawas niini.
Tungod sa desperasyon, gilusad nako ang Process Explorer gikan sa Sysinternals ug gitan-aw ang SQL stack. Sa hinay nga mga makina ang linya nakadani dayon sa akong mata:
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
... nilaktaw
sqldk.dll!SystemThread::MakeMiniSOSThread+0xa54
KERNEL32.DLL!BaseThreadInitThunk+0x14
ntdll.dll!RtlUserThreadStart+0x21
Kini usa na ka butang. Ang programa gisulat:
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 < 1000)
{
GetSystemTimePreciseAsFileTime(out var fileTime);
counter++;
}
if (i > 0)
{
Console.WriteLine("{0}", counter);
}
}
}
}Kini nga programa nagpakita sa usa ka labi pa nga gipahayag nga paghinay - sa "paspas" nga mga makina kini nagpakita sa 16-18 milyon nga mga siklo matag segundo, samtang sa hinay nga mga makina nagpakita kini usa ug tunga nga milyon, o bisan 700 ka libo. Sa ato pa, ang kalainan 10-20 ka beses (!!!). Kini usa na ka gamay nga kadaugan: sa bisan unsang kaso, walaβy hulga nga ma-stuck tali sa suporta sa Microsoft ug VMware aron sila magbutang mga pana sa usag usa.
Unya ang pag-uswag mihunong - mga bakasyon, importante nga mga butang, viral hysteria ug usa ka mahait nga pagtaas sa workload. Kanunay nakong gihisgutan ang problema sa salamangka sa akong mga kauban, apan usahay ingon og dili sila kanunay motuo kanako - ang pahayag nga gipahinay sa VMware ang code sa 10-20 nga mga panahon grabe kaayo.
Naningkamot ko sa pagkalot sa akong kaugalingon kung unsa ang nagpahinay kanako. Usahay ingon og nakakaplag ko og solusyon - ang pag-on ug off sa Hot plugs, pag-ilis sa gidaghanon sa memorya o sa gidaghanon sa mga processor nga sagad gihimong βpaspasβ ang makina. Pero dili forever. Apan ang nahimo nga tinuod mao nga igo na ang paggawas ug pagtuktok sa ligid - nga mao, pagbag-o bisan unsa parameter sa virtual machine
Sa katapusan, ang akong mga kauban sa Amerika kalit nga nakit-an ang hinungdan.
Ang mga host lahi sa frequency!
- Ingon sa usa ka lagda, kini dili usa ka dako nga deal. Apan: kung mobalhin gikan sa usa ka 'native' host ngadto sa usa ka host nga adunay 'lainlain' nga frequency, ang VMware kinahanglan nga mag-adjust sa resulta sa GetTimePrecise.
- Ingon sa usa ka lagda, dili kini usa ka problema, gawas kung adunay usa ka aplikasyon nga nangayo sa eksaktong oras milyon-milyon nga beses matag segundo, sama sa SQL server.
- Apan dili kini makahadlok, tungod kay ang SQL server dili kanunay buhaton kini (tan-awa ang Panapos)
Apan adunay mga kaso nga kini nga rake kusog nga naigo. Ug bisan pa, oo, pinaagi sa pag-tap sa ligid (pinaagi sa pagbag-o sa usa ka butang sa mga setting sa VM) gipugos nako ang VMware nga 'i-recalculate' ang configuration, ug ang frequency sa kasamtangan nga host nahimong 'native' frequency sa makina.
desisyon
Kung imong gi-disable ang virtualization sa TSC, ang pagbasa sa TSC gikan sa sulod sa virtual machine ibalik ang TSC value sa pisikal nga makina, ug ang pagsulat sa TSC gikan sa sulod sa virtual machine walay epekto. Ang pagbalhin sa virtual nga makina ngadto sa laing host, pagpadayon niini gikan sa gisuspinde nga estado, o pagbalik ngadto sa usa ka snapshot maoy hinungdan sa TSC sa pag-ambak nga walay hunong. Ang ubang mga operating system sa bisita napakyas sa pag-boot, o nagpakita sa ubang mga problema sa timekeeping, kung ang TSC virtualization na-disable. Kaniadto, kini nga bahin usahay girekomenda aron mapauswag ang paghimo sa mga aplikasyon nga kanunay nga nagbasa sa TSC, apan ang performance sa virtual nga TSC miuswag pag-ayo sa mga produkto karon. Girekomenda usab ang bahin nga gamiton kung maghimo mga pagsukod nga nanginahanglan usa ka tukma nga gigikanan sa tinuud nga oras sa virtual machine.
Sa laktud, kinahanglan nimo nga idugang ang parameter
monitor_control.virtual_rdtsc = FALSE
konklusyon
Tingali adunay usa ka pangutana: nganong ang SQL nagtawag sa GetTimePrecise kanunay?
Wala koy SQL server source code, pero ang logic nag-ingon niini. Ang SQL hapit usa ka operating system nga adunay cooperative concurrency, diin ang matag thread kinahanglan nga "mohatag" matag karon ug unya. Asa ang pinakamaayong dapit sa pagbuhat niini? Kung diin adunay natural nga paghulat - lock o IO. Okay, apan unsa man kung nagtuyok kami sa mga computational loops? Unya ang dayag ug halos bugtong dapit anaa sa tighubad (kini dili gayud usa ka tighubad), human sa pagpatuman sa sunod nga pahayag.
Sa kinatibuk-an, ang SQL server wala gigamit alang sa lunsay nga computing nailing ug kini dili usa ka problema. Apan ang mga galong nga nagtrabaho sa tanang matang sa temporaryo nga mga lamesa (nga diha-diha dayon gi-cache) naghimo sa code ngadto sa usa ka han-ay sa dali kaayong gipatuman nga mga pahayag.
Pinaagi sa dalan, kung imong giputos ang function sa NATIVELY COMPILED, nan kini mohunong sa pagpangayo og oras, ug ang katulin niini motaas sa 10 ka beses. Komosta ang kooperatiba nga multitasking? Apan alang sa natively compiled code kinahanglan namong buhaton ang PREEMPTIVE MULTITASKING sa SQL.
Source: www.habr.com