Dawn huma eżattament l-ilmenti li smajt mingħand l-iżviluppaturi tagħna. L-aktar ħaġa interessanti hija li dan irriżulta li kien minnu, li ta lok għal investigazzjoni twila. Se nitkellmu dwar servers SQL li jaħdmu fuq VMware.
Fil-fatt, huwa faċli li jiġi żgurat li s-server tal-produzzjoni jkun bla tama wara l-laptop. Eżegwixxi (mhux fuq tempdb u mhux fuq database b'Delayed Durability attivata) il-kodiċi:
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
Fuq id-desktop tiegħi tieħu 5 sekondi, u fuq is-server tal-produzzjoni tieħu 28 sekonda. Minħabba li SQL irid jistenna t-tmiem fiżiku tad-dħul fil-log tat-tranżazzjonijiet, u qed nagħmlu tranżazzjonijiet qosra ħafna hawn. Bejn wieħed u ieħor, saq trakk kbir u b'saħħtu fit-traffiku tal-belt, u rajna kif inqabeż b'mod dashingly minn nies tal-konsenja tal-pizza fuq skuters - il-fluss mhuwiex importanti hawn, il-latency biss hija importanti. U l-ebda ħażna tan-netwerk, ma jimpurtax kemm hemm żerijiet fil-prezz tiegħu, ma jista 'jegħleb l-SSD lokali f'termini ta' latency.
(fil-kummenti rriżulta li giddejt - kelli d-durabilità mdewma fiż-żewġ postijiet. Mingħajr durabilità mdewma jirriżulta:
Desktop - 39 sekonda, 15K tr/sec, 0.065ms /io roundtrip
PROD - 360 sekonda, 1600 tr/sec, 0.6ms
I kellha ndunat li kien mgħaġġel wisq)
Madankollu, f'dan il-każ qed nittrattaw żerijiet trivjali tal-funzjoni zeta Riemann b'eżempju trivjali. Fl-eżempju li ġabuli l-iżviluppaturi, kien differenti. Kont konvint li kellhom raġun, u bdejt inneħħi mill-eżempju l-ispeċifiċitajiet kollha tagħhom relatati mal-loġika tan-negozju. F'xi punt indunajt li stajt narmi kompletament il-kodiċi tagħhom u nikteb tiegħi stess - li juri l-istess problema - fil-produzzjoni taħdem 3-4 darbiet aktar bil-mod:
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
GOJekk kollox huwa tajjeb, allura l-iċċekkjar tal-primalità ta 'numru jieħu 6-7-8 sekondi. Dan ġara fuq numru ta' servers. Iżda fuq xi wħud, il-kontroll ħa 25-40 sekonda. Interessanti, ma kien hemm l-ebda servers fejn l-eżekuzzjoni kienet tieħu, ngħidu aħna, 14-il sekonda - il-kodiċi ħadem jew malajr ħafna jew bil-mod ħafna, jiġifieri, il-problema kienet, ejja ngħidu, iswed u abjad.
Dak li għamilt? Metriċi VMware użati. Kollox kien tajjeb hemmhekk - kien hemm abbundanza ta 'riżorsi, Ħin lest = 0, kien hemm biżżejjed minn kollox, waqt it-test kemm fuq servers veloċi kif ukoll bil-mod CPU = 100 fuq vCPU wieħed. Ħadt test biex nikkalkula n-numru Pi - it-test wera l-istess riżultati fuq kwalunkwe server. Ir-riħa tal-maġija sewda saret aktar u aktar qawwija.
Ladarba wasalt fir-razzett DEV, bdejt nilgħab mas-servers. Irriżulta li vMotion minn host għal host jista '"jfejjaq" server, iżda jista' wkoll jibdel server "veloċi" f'wieħed "bil-mod". Jidher li dan hu - xi hosts għandhom problema... imma... le. Xi magna virtwali kienet bil-mod fuq host, ngħidu aħna A, iżda ħadmet malajr fuq host B. U magna virtwali oħra, għall-kuntrarju, ħadmet malajr fuq A u naqset fuq B! Kemm magni "veloċi" kif ukoll "bil-mod" kienu spiss iduru fuq l-ospitanti!
Minn dak il-mument 'il quddiem, kien hemm riħa distinta ta' kubrit fl-arja. Wara kollox, il-problema ma setgħetx tiġi attribwita lill-magna virtwali (irqajja tal-Windows, pereżempju) - wara kollox, inbidel f'"mgħaġġel" b'vMotion. Iżda l-problema wkoll ma setgħetx tiġi attribwita lill-ospitant - wara kollox, jista 'jkollha kemm magni "veloċi" kif ukoll "bil-mod". Ukoll, dan ma kienx relatat mat-tagħbija - irnexxieli nikseb magna "bil-mod" fuq l-ospitant, fejn ma kien hemm xejn minbarra dan.
Minn disprament, nediet Process Explorer minn Sysinternals u ħares lejn il-munzell SQL. Fuq magni bil-mod il-linja immedjatament ġibditli l-għajn:
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
... maqbuża
sqldk.dll!SystemThread::MakeMiniSOSThread+0xa54
KERNEL32.DLL!BaseThreadInitThunk+0x14
ntdll.dll!RtlUserThreadStart+0x21
Din kienet diġà xi ħaġa. Il-programm inkiteb:
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);
}
}
}
}Dan il-programm wera tnaqqis saħansitra aktar evidenti - fuq magni "veloċi" juri 16-18-il miljun ċiklu kull sekonda, filwaqt li fuq magni bil-mod juri miljun u nofs, jew saħansitra 700 elf. Jiġifieri, id-differenza hija 10-20 darba (!!!). Din kienet diġà rebħa żgħira: fi kwalunkwe każ, ma kien hemm l-ebda theddida li jeħel bejn l-appoġġ ta 'Microsoft u VMware sabiex dawn iduru l-vleġeġ fuq xulxin.
Imbagħad il-progress waqaf - vaganzi, kwistjonijiet importanti, isteriżmu virali u żieda qawwija fl-ammont ta 'xogħol. Spiss semmejt il-problema tal-maġija lill-kollegi tiegħi, iżda xi drabi deher li lanqas dejjem emmnuni - id-dikjarazzjoni li VMware inaqqas il-kodiċi b'10-20 darba kienet mostruża wisq.
Ippruvajt noħroġ lili nnifsi dak li kien qed inaqqasni. Xi drabi deherli li kont sibt soluzzjoni - ixgħel u jintefa Hot plugs, nibdel l-ammont ta 'memorja jew in-numru ta' proċessuri ta 'spiss biddel il-magna f'waħda "mgħaġġla". Imma mhux għal dejjem. Imma li rriżulta li hu minnu huwa li huwa biżżejjed li toħroġ u tħabbat ir-rota - jiġifieri, tibdel kwalunkwe parametru tal-magna virtwali
Fl-aħħarnett, il-kollegi Amerikani tiegħi f'daqqa sabu l-kawża ewlenija.
L-ospiti kienu differenti fil-frekwenza!
- Bħala regola, din mhix xi ħaġa kbira. Iżda: meta jiċċaqlaq minn host "nattiv" għal host bi frekwenza "differenti", VMware għandu jaġġusta r-riżultat GetTimePrecise.
- Bħala regola, din mhix problema, sakemm ma jkunx hemm applikazzjoni li titlob il-ħin eżatt miljuni ta 'darbiet kull sekonda, bħal SQL server.
- Iżda dan mhux tal-biża', peress li SQL server mhux dejjem jagħmel dan (ara l-Konklużjoni)
Iżda hemm każijiet meta dan ir-rake jolqot iebes. U madankollu, iva, billi ttektek fuq ir-rota (billi nbidel xi ħaġa fis-settings tal-VM) sfurzajt lil VMware biex "jikkalkula mill-ġdid" il-konfigurazzjoni, u l-frekwenza tal-host attwali saret il-frekwenza "nattiva" tal-magna.
deċiżjoni
Meta tiddiżattiva l-virtwalizzazzjoni tat-TSC, il-qari tat-TSC minn ġewwa l-magna virtwali jirritorna l-valur TSC tal-magna fiżika, u l-kitba tat-TSC minn ġewwa l-magna virtwali m'għandha l-ebda effett. Il-migrazzjoni tal-magna virtwali għal host ieħor, it-tkomplija tagħha minn stat sospiż, jew ir-ritorn għal snapshot tikkawża li t-TSC jaqbeż b'mod mhux kontinwu. Xi sistemi operattivi mistiedna jonqsu milli jibdew, jew juru problemi oħra ta' żamma tal-ħin, meta l-virtwalizzazzjoni TSC tkun diżattivata. Fil-passat, din il-karatteristika ġieli ġiet rakkomandata biex ittejjeb il-prestazzjoni ta 'applikazzjonijiet li jaqraw it-TSC ta' spiss, iżda l-prestazzjoni tat-TSC virtwali tjiebet sostanzjalment fil-prodotti attwali. Il-karatteristika ġiet rakkomandata wkoll għall-użu meta jsiru kejl li jeħtieġu sors preċiż ta 'ħin reali fil-magna virtwali.
Fil-qosor, għandek bżonn iżżid il-parametru
monitor_control.virtual_rdtsc = FALZ
Konklużjoni
Probabilment ikollok mistoqsija: għaliex SQL isejjaħ GetTimePrecise daqshekk spiss?
M'għandix il-kodiċi tas-sors tas-server SQL, iżda l-loġika tgħid dan. L-SQL huwa kważi sistema operattiva b'konkorrenza kooperattiva, fejn kull ħajta trid "jċedi" minn żmien għal żmien. Fejn hu l-aħjar post biex tagħmel dan? Fejn hemm stennija naturali - lock jew IO. Okay, imma x'jiġri jekk aħna għażil linji komputazzjoni? Imbagħad il-post ovvju u kważi l-uniku huwa fl-interpretu (dan mhux verament interpretu), wara li tesegwixxi l-istqarrija li jmiss.
Ġeneralment, is-server SQL ma jintużax għal nailing tal-kompjuter pur u din mhix problema. Iżda loops li jaħdmu ma 'kull xorta ta' tabelli temporanji (li huma immedjatament cache) jibdlu l-kodiċi f'sekwenza ta 'dikjarazzjonijiet eżegwiti malajr ħafna.
Mill-mod, jekk tkebbeb il-funzjoni f'NATIVELY COMPILED, allura tieqaf titlob ħin, u l-veloċità tagħha tiżdied b'darbiet 10. Xi ngħidu dwar il-multitasking kooperattiv? Iżda għal kodiċi miġbura b'mod nattiv kellna nagħmlu PREEMPTIVE MULTITASKING fl-SQL.
Sors: www.habr.com