Istae sunt prorsus querelae quas ex nostris tincidunt audivi. Maxime interesting res est quod hoc verum evasit, inde longam inquisitionem. Loquemur de SQL servientibus qui in VMware currunt.
Profecto facile est curare ut productio server sine laptop post. Executio (non in tempdb et non in database cum Durabilitate moratus para) codicem:
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
In mea desktop capit 5 secundis, et in productione servo capit 28 secundis. Quia SQL exspectandum est finem physicam transactionis iniuriarum ingressu, et brevissimas res hic agimus. Dure loquendo magnum et potentem plaustrum in negotiationem urbanam compulimus et cum in scooters rusco russorum homines audaciter oppressi servabamus - throughput is not important here, only latency is important. Nulla reposita retis, quamvis multae cyphris in suo pretio sint, localem SSD verbis latency verberare possunt.
(in commentis vertit me mentitum - in utroque loco diuturnitatem distuli. Sine mora durabilitas evenit;
Desktop - 39 seconds, 15K tr/sec, 0.065ms /io roundtrip
PROD - 360 seconds, 1600 tr/sec, 0.6ms
Animadvertissem nimis celeriter)
Attamen in hoc casu de levibus zeris Riemann zetae functionis levi exemplo agimus. In ipsum velit, tincidunt efficitur mi in, varius dictum erat. Recte persuasum habeo, et ab exemplo omnia eorum specialia ad logicam negotia pertinentia amovere coepi. Aliquando intellexi me codicem suum penitus abicere ac scribere me ipsum β quod idem demonstrat problema β in productione percurrit 3-4 temporibus tardius;
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
GOSi omnia bona sunt, tunc primum numerorum primalitas inspicienda 6-7-8 secunda capiet. Hoc factum est in multis servientibus. Sed quibusdam, 25-40 secundis perscriptio. Interestingly, non erant ministri ubi supplicium sumeret, inquam, 14 secundae - signum vel celerrime vel tarde laboraverunt, id est, quaestio facta est, dicamus nigrum et album.
Quid ego feci? Usus est VMware metrics. Omnia ibi bene erant - copia opum erat, Promptus tempus = 0, satis rerum omnium, in probatione tam celeriter quam tardi servi CPU = 100 in uno vCPU. Probationem cepi ad calculandum numerum Pi - probatio ostendit eosdem eventus in quolibet servo. Odor magicae nigrae fortior et fortior factus est.
Cum ad villam DEV adveni, cum ministris ludere coepi. Versa est ut vMotion ab hospite ad exercitum "sedem" ministrantem possit, sed etiam "ieiunium" ministrantem in unum "tardus" vertere potest. Hoc simile videtur hoc est - problema aliquod habent .... sed .... non. Quidam apparatus virtualis segnis erat in exercitu, dicunt A, sed cito laborabat in exercitu B. Et alia machina virtualis, e contrario cito in A laborabat, et in B retardabatur! Ambae machinae "celeriter" et "tardus" exercitum saepe stabant!
Ex eo tempore distinctus erat odor sulphuris in aere. Post omnes, problema virtuali machinae tribui non potuit (Fenestrae inaequaliter, exempli gratia) - post omnes, in "celeriter" cum vMotione versa est. Sed quaestio etiam hostiae attribui non potuit - tamen, et "celeriter" et "tardus" machinas habere potuit. Etiam hoc onere non refertur - potui accipere machinam "tardus" in exercitu, ubi nihil omnino praeter.
De desperatione, Processum Explorer e Sysinternals excussi et SQL acervum aspexi. Tardis machinis acies statim oculus meus comprehendit;
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
... exsultaverunt
sqldk.dll!SystemThread::MakeMiniSOSThread+0xa54
KERNEL32.DLL!BaseThreadInitThunk+0x14
ntdll.dll!RtlUserThreadStart+0x21
Iam hoc aliquid erat. Programma inscriptum est;
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);
}
}
}
}Haec progressio demonstrata tarditatis adhuc acutior - in machinis "velox" demonstrat XVI-XVIII decies cyclos per alterum, dum in machinis tardis unum et dimidium miliones, vel etiam DCC milia ostendit. Hoc est, differentia 16-18 temporum (!!!). Haec parva iam victoria erat: certe nulla comminatio adhaesit inter Microsoft et VMware subsidium ut sagittas in se invicem converterent.
Progressus deinde cessavit - feriarum, rerum magnarum, hystoria viralis et acre auctum in quod inposuit. Saepe quaestionem magicam collegis meis commemoravi, sed interdum visum est eos ne mihi semper crederent - quod VMware retardat codicem a 10-20 temporibus nimis monstrosum fuisse.
Quod me retardans conabar effodere me. Aliquando mihi visum est solutionem invenisse - Hot plugs in et off convertens, mutato numero memoriae vel processuum numero saepe machinam in unum "celeriter" convertit. Sed non semper. Quod autem verum est, satis est exire et pulsare rotam, id est, mutationem nihil virtualis apparatus parametri
Demum, collegae mei Americani causam subito invenerunt.
Diversae catervae frequentia!
- Pro regula non est multum. Sed: cum a 'patria' ad exercitum cum frequentia 'diversa' frequentia moveatur, VMware eventum GetTimePrecise accommodare debet.
- Pro regula, hoc problema non est, nisi applicatio quae postulat tempus decies septies in secundo, sicut SQL ministrator.
- Sed hoc non est FORMIDULOSUS, quia SQL cultor hoc non semper facit.
Sed sunt casus cum hoc moechus duris ferit. Et tamen, sic, iactando in rota (aliquid mutando in VM occasus) figuram VMware ad recalculare coegi, et frequentia currentis exercitus facta est frequentia machinae indigena.
arbitrium
Cum virtualizationem TSC disable, legendo TSC intra virtualem machinam recurrit valorem corporis machinae TSC et scribens TSC ab intra virtualem machinam effectum non habet. Apparatus virtualis ad aliam exercitum migrans, eam e statu suspensa resumens, vel ad snapshotum reverti facit ut TSC saliat discontinue. Quidam hospes systemata operandi deficiunt vel ocreas, vel alias difficultates custodiendi exhibent, cum TSC virtualisatio debilis est. Praeteritis, haec factura interdum commendata est ad emendandas applicationes quae TSC frequenter leguntsed effectio virtualis TSC substantialiter in productis currentibus emendata est. Pluma etiam ad usum commendatum est cum mensuras faciendo quae certum fontem temporis realis in machina virtuali requirunt.
Denique modulo addere debes
monitor_control.virtual_rdtsc = FALSA
conclusio,
Vos forsit habere quaestionem: quare SQL vocat GetTimePrecise toties?
SQL signum originis non habeo, sed logica hoc dicit. SQL systema operativum fere est cum concurrentia cooperativo, ubi singula fila "in tempore" dare debent. Ubi est optimus locus hoc facere? Ubi est naturalis insidiator β lock or IO. Bene, sed quid si ansas computativas ligamus? Tum evidens et fere unicus locus est apud interpretem (hoc enim non est vere interpretis), postquam sequentia verba exsequuntur.
Fere, SQL server, pro puro computandi clavo non adhibetur, et hoc problema non est. Sed ansas, quae cum omnibus tabulis temporalibus (quae statim conditivo sunt) laborant, codicem in ordinem vertunt declarationum celerrime executae.
Viam, si munus in NATIVO COMPILATUM involvis, tempus sistit, et celeritas eius per 10 tempora augetur. Sed pro codice patrio exarato praereptum MULTITASKING in SQL facere debebamus.
Source: www.habr.com