Haya ni madai niliyosikia kutoka kwa wasanidi wetu. Jambo la kufurahisha zaidi ni kwamba hii iligeuka kuwa kweli, na kusababisha uchunguzi wa muda mrefu. Tutazungumza juu ya seva za SQL ambazo zinafanya kazi kwenye VMware.
Kwa kweli, kupata seva ya uzalishaji bila tumaini nyuma ya kompyuta ndogo ni rahisi. Endesha (sio kwenye tempdb na sio kwenye hifadhidata iliyo na Uimara wa Kuchelewa kuwezeshwa) msimbo:
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
Inachukua sekunde 5 kwenye eneo-kazi langu na sekunde 28 kwenye seva ya uzalishaji. Kwa sababu SQL inabidi ingojee mwisho halisi wa kuandika kwa logi ya muamala, na tunafanya shughuli fupi sana hapa. Kwa kusema, tuliendesha lori kubwa lenye nguvu kwenye trafiki ya jiji, na tunatazama jinsi watu wa kuwasilisha pizza kwenye pikipiki wanavyoipita kwa njia maarufu - upitishaji si muhimu hapa, ucheleweshaji pekee ndio muhimu. Na hakuna hifadhi moja ya mtandao, bila kujali ni zero ngapi kwa bei yake, itaweza kushinda SSD ya ndani kwa suala la latency.
(katika maoni iliibuka kuwa nilidanganya - nilikuwa nimechelewesha uimara katika sehemu zote mbili. Bila uimara wa kuchelewa inageuka:
Eneo-kazi - sekunde 39, 15K tr/sec, 0.065ms /io kurudi na kurudi
PROD - sekunde 360, 1600 tr/sec, 0.6ms
Nilipaswa kugundua kuwa ni haraka sana)
Walakini, katika kesi hii tunashughulika na sufuri ndogo za kazi ya Riemann zeta na mfano mdogo. Katika mfano ambao watengenezaji waliniletea, ilikuwa tofauti. Nilikuwa na hakika kwamba walikuwa sahihi, na nikaanza kusafisha maelezo yao yote yanayohusiana na mantiki ya biashara kutoka kwa mfano. Wakati fulani, niligundua kuwa naweza kutupa nambari zao kabisa, na kuandika yangu - ambayo inaonyesha shida kama hiyo - katika uzalishaji huendesha polepole mara 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
GOIkiwa kila kitu kiko sawa na wewe, basi kuangalia kwa unyenyekevu wa nambari itachukua sekunde 6-7-8. Hii imetokea kwenye seva kadhaa. Lakini kwa wengine, hundi ilichukua sekunde 25-40. Inafurahisha, hakukuwa na seva ambapo utekelezaji ungechukua, sema, sekunde 14 - nambari ilifanya kazi haraka sana au polepole sana, ambayo ni, shida ilikuwa, wacha tuseme, nyeusi na nyeupe.
Nilichofanya? Iliingia katika vipimo vya VMware. Kila kitu kilikuwa sawa - kulikuwa na rasilimali nyingi, Wakati ulio tayari = 0, kulikuwa na kila kitu cha kutosha, wakati wa jaribio kwenye seva za haraka na polepole CPU = 100 kwenye vCPU moja. Nilichukua mtihani kuhesabu idadi ya Pi - jaribio lilionyesha matokeo sawa kwenye seva yoyote. Harufu ya uchawi nyeusi ilikua na nguvu zaidi.
Baada ya kutoka kwenye shamba la DEV, nilianza kucheza na seva. Ilibadilika kuwa vMotion kutoka kwa mwenyeji hadi mwenyeji inaweza "kuponya" seva, lakini inaweza pia kugeuza seva ya "haraka" kuwa "polepole". Inaonekana kwamba hii ndiyo - baadhi ya majeshi wana tatizo ... lakini ... hapana. Mashine fulani ya mtandaoni ilipunguza kasi ya mwenyeji, tuseme, A, lakini ilifanya kazi haraka kwa mwenyeji B. Na mashine nyingine ya mtandaoni, kinyume chake, ilifanya kazi haraka kwenye A na ikapunguza kasi ya B! Magari yote "ya haraka" na "polepole" mara nyingi yalikuwa yanazunguka kwenye mwenyeji!
Kuanzia wakati huo na kuendelea, kulikuwa na harufu tofauti ya sulfuri hewani. Baada ya yote, shida haikuweza kuhusishwa na mashine yoyote ya kawaida (vipande vya madirisha, kwa mfano) - baada ya yote, iligeuka kuwa "haraka" na vMotion. Lakini shida pia haikuweza kuhusishwa na mwenyeji - baada ya yote, inaweza kuwa na mashine "za haraka" na "polepole". Pia haikuhusiana na mzigo - nilifanikiwa kupata mashine "polepole" kwenye mwenyeji, ambapo hakukuwa na chochote isipokuwa hiyo.
Kwa kukata tamaa, niliwasha Sysinternals 'Process Explorer na nikatazama safu ya SQL. Kwenye mashine polepole, laini mara moja ilivutia macho yangu:
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
β¦ ruka
sqldk.dll!SystemThread::MakeMiniSOSTthread+0xa54
KERNEL32.DLL!BaseThreadInitThunk+0x14
ntdll.dll!RtlUserThreadStart+0x21
Ilikuwa tayari kitu. Mpango huo uliandikwa:
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);
}
}
}
}Mpango huu ulionyesha kushuka kwa kasi zaidi - kwenye mashine "za haraka" inaonyesha mizunguko milioni 16-18 kwa sekunde, wakati kwa polepole - milioni moja na nusu, au hata 700 elfu. Hiyo ni, tofauti ni mara 10-20 (!!!). Hii ilikuwa tayari ushindi mdogo: kwa hali yoyote, hakukuwa na tishio la kukwama kati ya usaidizi wa Microsoft na VMware ili waweze kubadili mishale kwa kila mmoja.
Kisha maendeleo yalisimama - likizo, mambo muhimu, hysteria ya virusi na ongezeko kubwa la kazi. Mara nyingi nilitaja shida ya kichawi kwa wenzangu, lakini wakati mwingine ilionekana kuwa hata hawakuniamini kila wakati - taarifa kwamba VMware ilipunguza kasi ya nambari kwa mara 10-20 ilikuwa mbaya sana.
Nilijaribu kujichimba ni nini kinachopunguza kasi. Wakati fulani ilionekana kwangu kuwa nimepata suluhu - kuwasha na kuzima plugs Moto, kubadilisha kiasi cha kumbukumbu au idadi ya wasindikaji mara nyingi iligeuza mashine kuwa "ya haraka". Lakini si milele. Lakini kile kilichogeuka kuwa kweli ni kwamba inatosha kwenda nje na kubisha gurudumu - yaani, kubadili yoyote parameta ya mashine halisi
Hatimaye, wafanyakazi wenzangu wa Marekani ghafla walipata sababu ya msingi.
Waandaji walitofautiana katika masafa!
- Kama sheria, hii sio ya kutisha. Lakini: unapohama kutoka kwa mwenyeji 'asili' hadi mwenyeji aliye na marudio 'tofauti', VMware lazima irekebishe matokeo ya GetTimePrecise.
- Kama sheria, hii sio shida, isipokuwa kama kuna programu inayoomba wakati kamili mamilioni ya mara kwa sekunde, kama seva ya SQL.
- Lakini hii sio ya kutisha pia, kwani seva ya SQL haifanyi hivi kila wakati (tazama Hitimisho)
Lakini kuna matukio wakati reki hii inaumiza. Na ndiyo, kwa kugonga gurudumu (kwa kubadilisha kitu katika mipangilio ya VM), nililazimisha VMware 'kuhesabu upya' usanidi, na mzunguko wa mwenyeji wa sasa ukawa mzunguko wa "asili" wa mashine.
uamuzi
Unapozima uboreshaji wa TSC, kusoma TSC kutoka ndani ya mashine pepe hurejesha thamani ya TSC ya mashine halisi, na kuandika TSC kutoka ndani ya mashine pepe hakuna athari. Kuhamisha mashine pepe hadi kwa seva pangishi nyingine, kuirejesha kutoka hali iliyosimamishwa, au kurejesha muhtasari husababisha TSC kuruka bila kuendelea. Baadhi ya mifumo ya uendeshaji ya wageni inashindwa kuwasha, au kuonyesha matatizo mengine ya kuhifadhi wakati, wakati uboreshaji wa TSC umezimwa. Hapo awali, kipengele hiki kilipendekezwa wakati mwingine ili kuboresha utendakazi wa programu zinazosoma TSC mara kwa mara, lakini utendaji wa TSC pepe umeboreshwa kwa kiasi kikubwa katika bidhaa za sasa. Kipengele hiki pia kimependekezwa kwa matumizi wakati wa kufanya vipimo vinavyohitaji chanzo mahususi cha muda halisi katika mashine pepe.
Kwa kifupi, unahitaji kuongeza parameter
monitor_control.virtual_rdtsc = FALSE
Hitimisho
Labda una swali: kwa nini SQL ingeita GetTimePrecise mara nyingi?
Sina vyanzo vya seva ya SQL, lakini mantiki inasema hivi. SQL ni karibu mfumo wa uendeshaji na upatanishi wa ushirika, ambapo kila uzi lazima "utoe njia" mara kwa mara. Mahali pazuri pa kuifanya ni wapi? Ambapo kuna matarajio ya asili - kufuli au IO. Sawa, lakini vipi ikiwa tunazunguka mizunguko ya hesabu? Kisha dhahiri na karibu mahali pekee ni katika mkalimani (huyu sio mkalimani kabisa), baada ya utekelezaji wa operator mwingine.
Kama sheria, seva ya SQL haitumiwi kwa kompyuta safi na hii sio shida. Lakini mizunguko yenye kazi na kila aina ya jedwali za muda (ambazo zimehifadhiwa mara moja) hugeuza msimbo kuwa mlolongo wa taarifa zinazotekelezwa haraka sana.
Kwa njia, ikiwa kazi imefungwa kwa NATIVEY COMPILED, basi inachaacha kuomba wakati, na kasi yake huongezeka kwa mara 10. Lakini vipi kuhusu multitasking ya vyama vya ushirika? Lakini kwa nambari iliyojumuishwa asili, ilibidi nifanye PREEMPTIVE MULTITASKING katika SQL.
Chanzo: mapenzi.com