હા, મારું જૂનું લેપટોપ તમારા પ્રોડક્શન સર્વર કરતાં અનેક ગણું વધુ શક્તિશાળી છે.

આ એવા દાવા છે જે મેં અમારા વિકાસકર્તાઓ પાસેથી સાંભળ્યા છે. સૌથી રસપ્રદ બાબત એ છે કે આ સાચું હોવાનું બહાર આવ્યું છે, જે લાંબી તપાસને જન્મ આપે છે. અમે SQL સર્વર્સ વિશે વાત કરીશું જે VMware પર ચાલી રહ્યા છે.

ખરેખર, લેપટોપની પાછળ નિરાશાજનક રીતે પ્રોડક્શન સર્વર મેળવવું સરળ છે. કોડ ચલાવો (ટેમ્પડીબી પર નહીં અને વિલંબિત ટકાઉપણું સક્ષમ ધરાવતા ડેટાબેઝ પર નહીં)

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

તે મારા ડેસ્કટોપ પર 5 સેકન્ડ અને પ્રોડક્શન સર્વર પર 28 સેકન્ડ લે છે. કારણ કે SQL ને ટ્રાન્ઝેક્શન લોગમાં લખવાના ભૌતિક અંતની રાહ જોવી પડે છે, અને અમે અહીં ખૂબ ટૂંકા વ્યવહારો કરી રહ્યા છીએ. સામાન્ય રીતે કહીએ તો, અમે શહેરના ટ્રાફિકમાં એક મોટી શક્તિશાળી ટ્રક ચલાવી છે, અને અમે જોઈ રહ્યા છીએ કે કેવી રીતે સ્કૂટર પર પીઝા ડિલિવરી કરનારા લોકો તેને પ્રખ્યાત રીતે આગળ નીકળી રહ્યા છે - થ્રુપુટ અહીં મહત્વપૂર્ણ નથી, માત્ર લેટન્સી મહત્વપૂર્ણ છે. અને એક પણ નેટવર્ક સ્ટોરેજ નહીં, પછી ભલે તેની કિંમતમાં કેટલા શૂન્ય હોય, તે લેટન્સીની દ્રષ્ટિએ સ્થાનિક SSD ને પાછળ રાખી શકશે નહીં.

(ટિપ્પણીઓમાં એવું બહાર આવ્યું કે મેં જૂઠું બોલ્યું - મેં બંને જગ્યાએ ટકાઉપણામાં વિલંબ કર્યો હતો. વિલંબિત ટકાઉપણું વિના તે બહાર આવ્યું:
ડેસ્કટોપ - 39 સેકન્ડ, 15K tr/sec, 0.065ms/io રાઉન્ડટ્રીપ
PROD - 360 સેકન્ડ, 1600 tr/sec, 0.6ms
મેં નોંધ્યું હોવું જોઈએ કે તે ખૂબ ઝડપી છે)

જો કે, આ કિસ્સામાં અમે તુચ્છ ઉદાહરણ સાથે રીમેન ઝેટા ફંક્શનના તુચ્છ શૂન્ય સાથે કામ કરી રહ્યા છીએ. વિકાસકર્તાઓ મને લાવ્યા તે ઉદાહરણમાં, તે અલગ હતું. મને ખાતરી થઈ ગઈ કે તેઓ સાચા હતા, અને ઉદાહરણમાંથી વ્યવસાયના તર્ક સાથે સંબંધિત તેમની તમામ વિશિષ્ટતાઓને સાફ કરવાનું શરૂ કર્યું. અમુક સમયે, મને સમજાયું કે હું તેમનો કોડ સંપૂર્ણપણે ફેંકી શકું છું, અને મારો પોતાનો લખી શકું છું - જે સમાન સમસ્યા દર્શાવે છે - ઉત્પાદનમાં તે 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

જો તમારી સાથે બધું બરાબર છે, તો સંખ્યાની સરળતા તપાસવામાં 6-7-8 સેકન્ડનો સમય લાગશે. આ સંખ્યાબંધ સર્વર પર થયું છે. પરંતુ કેટલાક પર, ચેકમાં 25-40 સેકન્ડનો સમય લાગ્યો. રસપ્રદ વાત એ છે કે, ત્યાં કોઈ સર્વર નહોતા કે જ્યાં એક્ઝેક્યુશનમાં 14 સેકન્ડ લાગશે - કોડ ખૂબ જ ઝડપથી અથવા ખૂબ જ ધીમેથી કામ કરે છે, એટલે કે, સમસ્યા હતી, ચાલો કહીએ, કાળો અને સફેદ.

મે શુ કર્યુ? VMware મેટ્રિક્સમાં પ્રવેશ મેળવ્યો. ત્યાં બધું સારું હતું - ત્યાં પુષ્કળ સંસાધનો હતા, તૈયાર સમય = 0, ત્યાં બધું પૂરતું હતું, ટેસ્ટ દરમિયાન ઝડપી અને ધીમા બંને સર્વર CPU = 100 એક vCPU પર. મેં Pi ની સંખ્યાની ગણતરી કરવા માટે એક પરીક્ષણ લીધું - પરીક્ષણ કોઈપણ સર્વર પર સમાન પરિણામો દર્શાવે છે. કાળા જાદુની ગંધ વધુ ને વધુ મજબૂત થતી ગઈ.

DEV ફાર્મ પર બહાર નીકળ્યા પછી, મેં સર્વર સાથે રમવાનું શરૂ કર્યું. તે બહાર આવ્યું છે કે હોસ્ટથી હોસ્ટ સુધી vMotion સર્વરને "ઇલાજ" કરી શકે છે, પરંતુ તે "ઝડપી" સર્વરને "ધીમા" માં પણ ફેરવી શકે છે. એવું લાગે છે કે આ તે છે - કેટલાક યજમાનોને સમસ્યા છે ... પરંતુ ... ના. કેટલાક વર્ચ્યુઅલ મશીન હોસ્ટ પર ધીમા પડી ગયા, કહો કે, A, પરંતુ હોસ્ટ B પર ઝડપથી કામ કર્યું. અને અન્ય વર્ચ્યુઅલ મશીન, તેનાથી વિપરીત, A પર ઝડપથી કામ કર્યું અને B પર ધીમી પડી! "ઝડપી" અને "ધીમી" બંને કાર ઘણીવાર યજમાન પર ફરતી હતી!

તે ક્ષણથી, હવામાં સલ્ફરની એક વિશિષ્ટ ગંધ હતી. છેવટે, સમસ્યા કોઈપણ વર્ચ્યુઅલ મશીન (ઉદાહરણ તરીકે વિન્ડોઝ પેચો) ને આભારી હોઈ શકતી નથી - છેવટે, તે vMotion સાથે "ઝડપી" માં ફેરવાઈ ગઈ. પરંતુ સમસ્યા પણ હોસ્ટને આભારી હોઈ શકતી નથી - છેવટે, તેમાં "ઝડપી" અને "ધીમી" બંને મશીનો હોઈ શકે છે. તે લોડ સાથે પણ સંબંધિત ન હતું - મેં હોસ્ટ પર "ધીમી" મશીન મેળવવામાં વ્યવસ્થાપિત કર્યું, જ્યાં તેના સિવાય બીજું કંઈ નહોતું.

નિરાશામાં, મેં Sysinternals' Process Explorer ને કાઢી નાખ્યું અને SQL સ્ટેક પર જોયું. ધીમી મશીનો પર, લીટીએ તરત જ મારી નજર પકડી લીધી:

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
… છોડ્યું
sqldk.dll!SystemThread::MakeMiniSOSThread+0xa54
KERNEL32.DLL!BaseThreadInitThunk+0x14
ntdll.dll!RtlUserThreadStart+0x21

તે પહેલેથી જ કંઈક હતું. પ્રોગ્રામ લખ્યો હતો:

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

આ પ્રોગ્રામે વધુ સ્પષ્ટ મંદી દર્શાવી - "ઝડપી" મશીનો પર તે પ્રતિ સેકન્ડમાં 16-18 મિલિયન ચક્ર બતાવે છે, જ્યારે ધીમા પર - દોઢ મિલિયન અથવા તો 700 હજાર. એટલે કે, તફાવત 10-20 વખત (!!!) છે. આ પહેલેથી જ એક નાની જીત હતી: કોઈ પણ સંજોગોમાં, Microsoft અને VMware સપોર્ટ વચ્ચે અટવાઈ જવાનો કોઈ ભય નહોતો જેથી તેઓ એકબીજા પર તીરો ફેરવે.

પછી પ્રગતિ અટકી ગઈ - વેકેશન, મહત્વપૂર્ણ વસ્તુઓ, વાયરલ ઉન્માદ અને વર્કલોડમાં તીવ્ર વધારો. મેં ઘણીવાર સાથીદારોને જાદુઈ સમસ્યાનો ઉલ્લેખ કર્યો, પરંતુ કેટલીકવાર એવું લાગતું હતું કે તેઓ હંમેશા મારા પર વિશ્વાસ કરતા નથી - VMware એ કોડને 10-20 વખત ધીમું કરે છે તે નિવેદન ખૂબ જ ભયંકર હતું.

મેં મારી જાતને શોધવાનો પ્રયાસ કર્યો કે તે શું ધીમું કરે છે. અમુક સમયે મને એવું લાગતું હતું કે મને એક ઉકેલ મળી ગયો છે - હોટ પ્લગને ચાલુ અને બંધ કરવું, મેમરીની માત્રા અથવા પ્રોસેસર્સની સંખ્યા બદલવી ઘણીવાર મશીનને "ઝડપી" બનાવી દે છે. પરંતુ કાયમ માટે નહીં. પરંતુ જે બહાર આવ્યું તે સાચું છે કે તે બહાર જવા માટે અને વ્હીલ પર પછાડવા માટે પૂરતું છે - એટલે કે, બદલવા માટે કોઈપણ વર્ચ્યુઅલ મશીન પરિમાણ

છેવટે, મારા અમેરિકન સાથીદારોને અચાનક એક મૂળ કારણ મળ્યું.

યજમાનો આવર્તનમાં અલગ હતા!

• એક નિયમ તરીકે, આ ડરામણી નથી. પરંતુ: જ્યારે 'મૂળ' હોસ્ટમાંથી 'ભિન્ન' આવર્તન સાથે હોસ્ટ પર જતી વખતે, VMware એ GetTimePrecise પરિણામને સમાયોજિત કરવું આવશ્યક છે.
• નિયમ પ્રમાણે, આ કોઈ સમસ્યા નથી, સિવાય કે એવી એપ્લિકેશન હોય કે જે SQL સર્વરની જેમ સેકન્ડ દીઠ લાખો વખત ચોક્કસ સમયની વિનંતી કરે.
• પરંતુ આ ડરામણી પણ નથી, કારણ કે SQL સર્વર હંમેશા આ કરતું નથી (નિષ્કર્ષ જુઓ)

પરંતુ એવા કિસ્સાઓ છે જ્યારે આ દાંતી દુખે છે. અને હા, વ્હીલ પર પછાડીને (VM સેટિંગ્સમાં કંઈક બદલીને), મેં VMware ને રૂપરેખાંકન 'પુનઃગણતરી' કરવા દબાણ કર્યું, અને વર્તમાન હોસ્ટની આવર્તન મશીનની 'નેટિવ' ફ્રીક્વન્સી બની ગઈ.

નિર્ણય

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

જ્યારે તમે TSC ના વર્ચ્યુઅલાઈઝેશનને નિષ્ક્રિય કરો છો, ત્યારે વર્ચ્યુઅલ મશીનની અંદરથી TSC વાંચવાથી ભૌતિક મશીનની TSC કિંમત પરત મળે છે, અને વર્ચ્યુઅલ મશીનની અંદરથી TSC લખવાની કોઈ અસર થતી નથી. વર્ચ્યુઅલ મશીનને બીજા યજમાનમાં સ્થાનાંતરિત કરવું, તેને સસ્પેન્ડ કરેલી સ્થિતિમાંથી ફરી શરૂ કરવું, અથવા સ્નેપશોટ પર પાછા ફરવાથી TSC અસંતુલિત રીતે કૂદવાનું કારણ બને છે. જ્યારે TSC વર્ચ્યુઅલાઈઝેશન નિષ્ક્રિય હોય ત્યારે કેટલીક ગેસ્ટ ઓપરેટિંગ સિસ્ટમો બુટ કરવામાં નિષ્ફળ જાય છે, અથવા અન્ય ટાઈમકીપિંગ સમસ્યાઓ પ્રદર્શિત કરે છે. ભૂતકાળમાં, આ સુવિધાને કેટલીકવાર TSC ને વારંવાર વાંચતી એપ્લિકેશનોના પ્રદર્શનને સુધારવા માટે ભલામણ કરવામાં આવી છે, પરંતુ વર્તમાન ઉત્પાદનોમાં વર્ચ્યુઅલ TSC ની કામગીરીમાં નોંધપાત્ર સુધારો કરવામાં આવ્યો છે. વર્ચ્યુઅલ મશીનમાં વાસ્તવિક સમયના ચોક્કસ સ્ત્રોતની જરૂર હોય તેવા માપન કરતી વખતે ઉપયોગ માટે પણ સુવિધાની ભલામણ કરવામાં આવી છે.

ટૂંકમાં, તમારે પરિમાણ ઉમેરવાની જરૂર છે

monitor_control.virtual_rdtsc = FALSE

નિષ્કર્ષ

તમારી પાસે કદાચ એક પ્રશ્ન છે: શા માટે એસક્યુએલ ગેટટાઇમ પ્રિસાઇઝને વારંવાર કૉલ કરશે?

મારી પાસે SQL સર્વર સ્ત્રોત નથી, પરંતુ તર્ક આ કહે છે. એસક્યુએલ એ સહકારી સંમતિ સાથે લગભગ એક ઓપરેટિંગ સિસ્ટમ છે, જ્યાં દરેક થ્રેડે સમયાંતરે "માર્ગ આપવો" જોઈએ. તે કરવા માટે શ્રેષ્ઠ સ્થાન ક્યાં છે? જ્યાં કુદરતી અપેક્ષા છે - લોક અથવા IO. ઠીક છે, પરંતુ જો આપણે કોમ્પ્યુટેશનલ ચક્રો ફરતા હોઈએ તો શું? પછી સ્પષ્ટ અને લગભગ એકમાત્ર સ્થાન દુભાષિયામાં છે (આ તદ્દન દુભાષિયા નથી), આગામી ઑપરેટરના અમલ પછી.

નિયમ પ્રમાણે, SQL સર્વરનો ઉપયોગ શુદ્ધ કમ્પ્યુટિંગ માટે થતો નથી અને આ કોઈ સમસ્યા નથી. પરંતુ તમામ પ્રકારના અસ્થાયી કોષ્ટકો (જે તરત જ કેશ કરવામાં આવે છે) સાથે કામ સાથેના ચક્રો કોડને ખૂબ જ ઝડપથી એક્ઝિક્યુટ થયેલા સ્ટેટમેન્ટના ક્રમમાં ફેરવે છે.

બાય ધ વે, જો ફંક્શન NATIVELY COMPILED માં લપેટાયેલું હોય, તો તે સમયની વિનંતી કરવાનું બંધ કરે છે, અને તેની ઝડપ 10 ગણી વધી જાય છે. પરંતુ સહકારી મલ્ટિટાસ્કિંગનું શું? પરંતુ મૂળ રીતે સંકલિત કોડ માટે, મારે SQL માં પ્રીમ્પ્ટીવ મલ્ટીટાસ્કીંગ કરવું પડ્યું.

સોર્સ: www.habr.com