Yebo, i-laptop yami endala inamandla izikhathi eziningana kuneseva yakho yokukhiqiza.

Lezi yizo kanye izikhalo engizizwe konjiniyela bethu. Okuthakazelisa kakhulu ukuthi lokhu kube yiqiniso, okwenza kube nophenyo olude. Sizokhuluma ngamaseva e-SQL asebenza ku-VMware.

Empeleni, kulula ukuqinisekisa ukuthi iseva yokukhiqiza ingemuva kwe-laptop ngokungenathemba. Sebenzisa (hhayi ku-tempdb futhi hhayi kusizindalwazi Enokuqina Okubambezelekile okunikwe amandla) ikhodi:

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

Kudeskithophu yami kuthatha imizuzwana emi-5, futhi kuseva yokukhiqiza kuthatha imizuzwana engama-28. Ngoba i-SQL kufanele ilinde ukuphela okungokoqobo kokungena kwelogi yokwenziwe, futhi senza imisebenzi emifushane kakhulu lapha. Uma sikhuluma nje, sishayele iloli elikhulu, elinamandla sangena kuthrafikhi yedolobha, futhi sabuka njengoba lalithathwa abantu abaletha i-pizza ngezithuthuthu - ukudlula akubalulekile lapha, ukubambezeleka kuphela kubalulekile. Futhi asikho isitoreji senethiwekhi, noma ngabe mangaki ama-zero enanini laso, esingashaya i-SSD yendawo ngokuya ngokubambezeleka.

(kumazwana kuvele ukuthi ngiqambe amanga - ngibambezele ukuqina kuzo zombili izindawo. Ngaphandle kokulibaziseka ukuqina kuyavela:
Ideskithophu - imizuzwana engama-39, 15K tr/isekhondi, 0.065ms /io uhambo lokuya nokubuya
I-PROD - 360 imizuzwana, 1600 tr/sec, 0.6ms
Bekumele ngiqaphele ukuthi bekushesha kakhulu)

Kodwa-ke, kulokhu sibhekene neziro ezincane zomsebenzi we-Riemann zeta ngesibonelo esincane. Esibonelweni abangilethela sona abathuthukisi, bekuhlukile. Ngangiqiniseka ukuthi baqinisile, futhi ngaqala ukususa esibonelweni yonke imininingwane yabo ehlobene nengqondo yebhizinisi. Ngesinye isikhathi ngabona ukuthi ngingayilahla ngokuphelele ikhodi yabo bese ngibhala eyami - ebonisa inkinga efanayo - ekukhiqizeni ihamba kancane izikhathi ezingu-3-4:

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
GO

Uma konke kuhamba kahle, ukuhlola ubukhulu benombolo kuzothatha imizuzwana engu-6-7-8. Lokhu kwenzeke kumaseva amaningi. Kodwa kwabanye, isheke lathatha imizuzwana engu-25-40. Kuyathakazelisa ukuthi kwakungekho amaseva lapho ukubulawa kungathatha khona, yithi, imizuzwana engu-14 - ikhodi isebenze ngokushesha noma kancane kakhulu, okungukuthi, inkinga yayiwukuthi, ake sithi, omnyama nomhlophe.

Ngenzeni? Kusetshenziswe amamethrikhi e-VMware. Konke kwakuhamba kahle lapho - kwakukhona inala yezinsiza, Isikhathi esilungile = 0, kwakukhona konke okwanele, ngesikhathi sokuhlolwa kokubili amaseva asheshayo futhi ahamba kancane CPU = 100 ku-vCPU eyodwa. Ngithathe isivivinyo ukuze ngibale inombolo engu-Pi - ukuhlolwa kubonise imiphumela efanayo kunoma iyiphi iseva. Iphunga lomlingo omnyama laqina futhi laqina.

Lapho ngifika epulazini le-DEV, ngaqala ukudlala ngamaseva. Kuvele ukuthi i-vMotion isuka kosokhaya iye kosokhaya ingakwazi “ukwelapha” iseva, kodwa ingaphinda iguqule iseva “esheshayo” ibe “ehamba kancane”. Kubonakala sengathi yilokhu - abanye abasingathi banenkinga... kodwa... cha. Omunye umshini obonakalayo ubuhamba kancane kumsingathi, yithi A, kodwa wasebenza ngokushesha kumsingathi u-B. Futhi omunye umshini we-virtual, ngokuphambene nalokho, wasebenza ngokushesha ku-A futhi wehlisa ijubane ku-B! Yomibili imishini “esheshayo” “nenensayo” yayivame ukuphotha umsingathi!

Kusukela ngaleso sikhathi kuqhubeke, kwaba nephunga elihlukile lesibabule emoyeni. Phela, inkinga ayikwazanga ukuvela kumshini we-virtual (ama-patches we-Windows, isibonelo) - emva kwakho konke, yaphenduka "ishesha" nge-vMotion. Kodwa inkinga nayo ayikwazanga ukuthi ibangelwa umsingathi - phela, ingaba nayo yomibili imishini “esheshayo” kanye “nenensayo”. Futhi, lokhu kwakungahlobene nomthwalo - ngikwazile ukuthola umshini "ohamba kancane" kumsingathi, lapho kwakungekho lutho ngaphandle kwawo.

Ngenxa yokuphelelwa ithemba, ngethule i-Process Explorer evela kwa-Sysinternals futhi ngabheka isitaki se-SQL. Emishinini ehamba kancane ulayini wangidonsa amehlo ngokushesha:

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
... weqiwe
sqldk.dll!SystemThread::MakeMiniSOSTthread+0xa54
KERNEL32.DLL!BaseThreadInitThunk+0x14
ntdll.dll!RtlUserThreadStart+0x21

Lokhu bekuvele kukhona. Uhlelo lwalubhalwe ukuthi:

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

Lolu hlelo lubonise ukwehla okumenyezelwe nakakhulu - emishinini "esheshayo" kukhombisa imijikelezo eyizigidi eziyi-16-18 ngomzuzwana, kanti emishinini ehamba kancane kukhombisa isigidi nesigamu, noma izinkulungwane ezingama-700. Okungukuthi, umehluko izikhathi ezingu-10-20 (!!!). Lokhu bekuvele kuwukunqoba okuncane: kunoma yikuphi, kwakungekho usongo lokunamathela phakathi kokusekelwa kweMicrosoft ne-VMware ukuze baphendule imicibisholo komunye nomunye.

Kwabe sekumiswa inqubekelaphambili - amaholide, izindaba ezibalulekile, i-viral hysteria kanye nokwanda okukhulu komsebenzi. Ngangivame ukusho inkinga yomlingo kozakwethu, kodwa ngezinye izikhathi kwakubonakala sengathi babengangikholelwa njalo - isitatimende sokuthi i-VMware yehlisa ikhodi izikhathi ezingu-10-20 sasiyimbi kakhulu.

Ngazama ukuzimba ukuthi yini eyayingibambezela. Ngezinye izikhathi kimina kwakubonakala sengathi ngithole isisombululo - ukuvula nokuvala ama-Hot plugs, ukushintsha inani lememori noma inani lamaphrosesa ngokuvamile kuvame ukuguqula umshini uwenze "osheshayo". Kodwa hhayi kuze kube phakade. Kodwa okwaba yiqiniso ukuthi kwanele ukuphuma futhi ushaye isondo - okungukuthi, ukushintsha noma yikuphi ipharamitha yomshini we-virtual

Ekugcineni, ozakwethu baseMelika bavele bathola umnyombo.

Abasingathi bebehluka ngobuningi!

• Njengomthetho, lokhu akuyona into enkulu. Kodwa: lapho usuka kumsingathi ‘womdabu’ uye kumsingathi onemvamisa ‘ehlukile’, i-VMware kufanele ilungise umphumela we-GetTimePrecise.
• Njengomthetho, lokhu akuyona inkinga, ngaphandle uma kukhona uhlelo lokusebenza olucela isikhathi esiqondile izigidi zezikhathi ngomzuzwana, njengeseva ye-SQL.
• Kodwa lokhu akwethusi, ngoba iseva ye-SQL ayikwenzi lokhu ngaso sonke isikhathi (bona Isiphetho)

Kodwa kunezimo lapho leli gama lishaya kanzima. Futhi nokho, yebo, ngokuthepha isondo (ngokushintsha okuthile kuzilungiselelo ze-VM), ngiphoqe i-VMware ukuthi 'ibale kabusha' ukucushwa, futhi imvamisa yomphathi wamanje yaba imvamisa 'yomdabu' yomshini.

Isixazululo

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

Uma ukhubaza ukwenziwa kwe-virtual kwe-TSC, ukufunda i-TSC ngaphakathi komshini obonakalayo kubuyisela inani le-TSC lomshini ophathekayo, futhi ukubhala i-TSC ngaphakathi komshini obonakalayo akunawo umthelela. Ukuthutha umshini we-virtual uwuyise komunye umsingathi, ukuwuqalisa kabusha usuka esimweni esimisiwe, noma ubuyela esifinyezweni kubangela i-TSC ukuthi igxume ingaqhubeki. Amanye amasistimu wokusebenza wezihambeli ahluleka ukuqalisa, noma abonise ezinye izinkinga zokugcina isikhathi, lapho ukwenziwa kwezinto ezibonakalayo kwe-TSC kukhutshaziwe. Esikhathini esedlule, lesi sici kwesinye isikhathi siye sanconywa ukuthuthukisa ukusebenza kwezinhlelo zokusebenza ezifunda i-TSC njalo, kodwa ukusebenza kwe-TSC ebonakalayo kuthuthukiswe kakhulu emikhiqizweni yamanje. Isici sinconyelwe futhi ukuthi sisetshenziswe uma kwenziwa izilinganiso ezidinga umthombo onembile wesikhathi sangempela emshinini wokubuka.

Ngamafuphi, udinga ukwengeza ipharamitha

monitor_control.virtual_rdtsc = FALSE

isiphetho

Cishe unombuzo: kungani i-SQL ishayela i-GetTimePrecise kaningi?

Anginayo ikhodi yomthombo weseva ye-SQL, kodwa ingqondo isho lokhu. I-SQL cishe iyisistimu yokusebenza ene-cooperative concurrency, lapho uchungechunge ngalunye kufanele "lunikeze" ngezikhathi ezithile. Ikuphi indawo engcono kakhulu yokwenza lokhu? Lapho kukhona ukulinda kwemvelo - ukukhiya noma i-IO. Kulungile, kodwa kuthiwani uma siphotha amaluphu ekhompyutha? Khona-ke indawo esobala futhi ecishe ibe kuphela kumhumushi (lo akuyena ngempela umhumushi), ngemva kokwenza isitatimende esilandelayo.

Ngokuvamile, iseva ye-SQL ayisetshenziselwa ukubethela okuhlanzekile kwekhompuyutha futhi lokhu akuyona inkinga. Kodwa ama-loops asebenza nazo zonke izinhlobo zamathebula esikhashana (agcinwe kunqolobane ngokushesha) aphendulela ikhodi ibe ukulandelana kwezitatimende ezisheshe zabulawa.

Ngendlela, uma ugoqa umsebenzi ku-NATIVELY COPILED, bese iyayeka ukucela isikhathi, futhi ijubane layo likhuphuka izikhathi ezingu-10. Kuthiwani ngokwenza izinto eziningi ngokubambisana? Kodwa ngekhodi ehlanganiswe ngokomdabu bekufanele senze I-PREEMPTIVE MULTITASKING ku-SQL.

Source: www.habr.com