🥇አዎ፣ የድሮው ላፕቶፕዬ ከምርት አገልጋይዎ ብዙ እጥፍ የበለጠ ኃይለኛ ነው

እነዚህ ከገንቢዎቻችን የሰማኋቸው ቅሬታዎች በትክክል ናቸው። በጣም የሚያስደንቀው ነገር እውነት መሆናቸው እና ረጅም ምርመራ ማስከተሉ ነው። ይህ በVMware ላይ የምናስኬዳቸውን የSQL አገልጋዮችን ይመለከታል።

እንደ እውነቱ ከሆነ፣ የምርት አገልጋይ ከላፕቶፕ ጀርባ እንዲወድቅ ማድረግ ቀላል ነው። የሚከተለውን ኮድ ያሂዱ (በቴምፕዲቢ ወይም በዳታቤዝ ላይ የዘገየ ዘላቂነት ነቅቷል)፡

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 የግብይት ምዝግብ ማስታወሻው በአካል እስኪጻፍ ድረስ መጠበቅ ስላለበት ነው፣ እና እዚህ በጣም አጭር ግብይቶችን እያደረግን ነው። በግምት ለመናገር፣ በከተማ ትራፊክ ውስጥ ትልቅ እና ኃይለኛ የጭነት መኪና ነድተናል እና በስኩተር ላይ ያሉ የፒዛ አቅርቦት አሽከርካሪዎች ከእሱ ሲሮጡ እየተመለከትን ነው - throughput እዚህ አስፈላጊ አይደለም፣ ዘግይቶ መውጣት ብቻ ነው። እና ምንም አይነት የአውታረ መረብ ማከማቻ፣ ምንም ያህል ዜሮዎች በዋጋው ውስጥ ቢኖሩ፣ በአካባቢው SSD ላይ በመዘግየት ሊሸነፍ አይችልም።

(በአስተያየቶቹ ውስጥ፣ እንደዋሸሁ ተገለጠ - በሁለቱም ቦታዎች ዘላቂነት ዘግይቶብኛል። ዘላቂነት ሳይዘገይ፣ እንዲህ ይመስላል፡
ዴስክቶፕ - 39 ሰከንዶች፣ 15ሺህ ትር/ሰከንድ፣ 0.065ሚሴ/አዙር ጉዞ
PROD - 360 ሰከንዶች፣ 1600 ትር/ሰከንድ፣ 0.6 ሚ.ሴ.
በጣም ፈጣን እንደነበር ልብ ማለት ነበረብኝ)

ሆኖም ግን፣ በዚህ ሁኔታ፣ የሪማን ዜታ ተግባርን ቀላል ዜሮዎች በትንሽ ምሳሌ እየተመለከትን ነው። ገንቢዎች ያመጡልኝ ምሳሌ የተለየ ነበር። ትክክል እንደሆኑ እርግጠኛ ሆንኩና ከንግድ ሎጂክ ጋር የተያያዙትን ሁሉንም ዝርዝሮች ማስወገድ ጀመርኩ። በአንድ ወቅት፣ ኮዳቸውን ሙሉ በሙሉ መጣል እና ተመሳሳይ ችግርን የሚያሳይ የራሴን መጻፍ እንደምችል ተገነዘብኩ - ነገር ግን በምርት ውስጥ፣ ከ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፣ ሁሉም ነገር ደህና ነበር፣ እና በፈተናው ወቅት፣ በፈጣን እና በዝግተኛ አገልጋዮች ላይ፣ በአንድ vCPU ላይ ሲፒዩ = 100። የPi ስሌት ሙከራውን አስኬድኩ - ውጤቶቹ በሁሉም አገልጋዮች ላይ ወጥ ነበሩ። የጥቁር አስማት ሽታ እየጠነከረ መጣ።

ወደ ዴቭ እርሻ ከደረስኩ በኋላ ከአገልጋዮቹ ጋር መጫወት ጀመርኩ። ከአስተናጋጅ ወደ አስተናጋጅ vMotion አገልጋይን "ሊፈውስ" እንደሚችል ታወቀ፣ ነገር ግን "ፈጣን" አገልጋይን ወደ "ቀርፋፋ" አገልጋይ ሊለውጠው ይችላል። እንደዚያ ይመስል ነበር - አንዳንድ አስተናጋጆች ችግር እያጋጠማቸው ነበር... ግን... አይደለም። አንድ ምናባዊ ማሽን በአስተናጋጁ ላይ ቀርፋፋ ነበር፣ ለምሳሌ፣ A፣ ነገር ግን በአስተናጋጅ B ላይ በፍጥነት ሮጧል። በሌላ በኩል ደግሞ ሌላ ምናባዊ ማሽን በA ላይ በፍጥነት ሮጦ በB ላይ ቀነሰ! ሁለቱም "ፈጣን" እና "ቀርፋፋ" ማሽኖች ብዙውን ጊዜ በተመሳሳይ አስተናጋጅ ላይ ይሰሩ ነበር!

ከዚያን ጊዜ ጀምሮ በአየር ላይ የተለየ የሰልፈር ሽታ ታየ። ችግሩ በምናባዊ ማሽኑ (ለምሳሌ የዊንዶውስ ፓች) ምክንያት ሊሆን አይችልም - በvMotion ወቅት ወደ "ፈጣን" ተቀይሯል። ነገር ግን ችግሩ በአስተናጋጁም ላይ ሊመሰረት አይችልም - "ፈጣን" እና "ቀርፋፋ" ማሽኖች ሊኖሩት ይችላል። እንዲሁም ከጭነት ጋር የተያያዘ አልነበረም - በአስተናጋጁ ላይ "ቀርፋፋ" ማሽን ማግኘት ችያለሁ፣ ሌላ ምንም ነገር አልነበረም።

ተስፋ በመቁረጥ፣ የሲሲንተርናልስ ፕሮሰስ ኤክስፕሎረርን አስጀመርኩና የSQL ቁልልን ተመለከትኩ። በዝግታ ማሽኖች ላይ፣ ወዲያውኑ ዓይኔን የሳበው መስመር፡

ntoskrnl.exe!ከSynchronizeExecution+0x5bf6
ntoskrnl.exe!KeWaitForMultipleObjects+0x109d
ntoskrnl.exe!KeWaitForMultipleObjects+0xb3f
ntoskrnl.exe!KeWaitForSingleObject+0x377
ntoskrnl.exe!KeQuerySystemTimePrecise+0x881 <- !!!
ntoskrnl.exe!ObDereferenceObjectDeferDelete+0x28a
ntoskrnl.exe!ከSynchronizeExecution+0x2de2
sqllang.dll!CDiagክርክርአስተማማኝ::PxlvlReplace+0x1a20
… ተዘልሏል
sqldk.dll!SystemThread::MakeMiniSOSTthread+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 ሚሊዮን ዑደቶችን አሳይቷል፣ በዝግተኛ ማሽኖች ላይ ደግሞ ከ1.5 ሚሊዮን ወይም ከ700,000 በላይ ነበር። ይህ ከ10-20 እጥፍ ልዩነት ነው (!!!)። ይህ ትንሽ ድል ነበር፡ ቢያንስ በማይክሮሶፍት እና በVMware ድጋፍ መካከል የመጣበቅ አደጋ አልነበረም፣ ይህም ገንዘብን በማለፍ ነው።

ከዚያም እድገቱ ቆመ - ዕረፍት፣ አስፈላጊ ጉዳዮች፣ የቫይረስ ግርግር እና የሥራ ጫና በከፍተኛ ሁኔታ መጨመር። ብዙ ጊዜ አስማታዊውን ችግር ለሥራ ባልደረቦቼ እጠቅስ ነበር፣ ነገር ግን አንዳንድ ጊዜ እንኳን አላመኑኝም ነበር - VMware ኮዱን በ10-20 ጊዜ እያዘገየው ነው የሚለው አባባል በጣም አስደንጋጭ ነበር።

እኔ ራሴ ምን እያዘገየኝ እንዳለ ለማወቅ ሞከርኩ። አንዳንድ ጊዜ መፍትሄ እንዳገኘሁ አስብ ነበር - ሆት ፕለጎችን ማንቃት እና ማሰናከል፣ የማህደረ ትውስታ መጠኑን መቀየር ወይም የማቀነባበሪያዎቹ ብዛት ብዙውን ጊዜ ማሽኑን "ፈጣን" ያደርጉታል። ግን ለዘላለም አይደለም። እውነት የሆነው ነገር ማድረግ ያለብዎት ወጥተው መንኮራኩሩን መንካት ብቻ ነው - ማለትም መቀየር። ማንኛውም ምናባዊ ማሽን መለኪያ

በመጨረሻም፣ አሜሪካውያን ባልደረቦቼ በድንገት ዋናውን ምክንያት አገኙ።

አስተናጋጆቹ በተደጋጋሚነት ይለያያሉ!

ይህ በአጠቃላይ ችግር አይደለም። ሆኖም፣ ከመነሻ አስተናጋጅ ወደተለየ ድግግሞሽ ወዳለው አስተናጋጅ ሲዛወር፣ VMware የ GetTimePrecise ውጤቱን ማስተካከል አለበት።
እንደ SQL Server ያሉ በሰከንድ በሚሊዮን የሚቆጠሩ ጊዜዎችን የሚጠይቅ ትክክለኛ ጊዜ የሚጠይቅ መተግበሪያ ከሌለዎት ይህ በአጠቃላይ ትልቅ ጉዳይ አይደለም።
ግን ይህ ትልቅ ጉዳይ አይደለም፣ ምክንያቱም SQL Server ሁልጊዜ ይህንን አያደርግም (ማጠቃለያን ይመልከቱ)

ግን ይህ ሬክ በኃይል የሚመታባቸው አጋጣሚዎች አሉ። እና አዎ፣ ጎማውን በመንካት (በVM ቅንብሮች ውስጥ የሆነ ነገር በመቀየር)፣ VMware ውቅሩን 'እንደገና እንዲያሰላ' አስገድጄዋለሁ፣ እና የአሁኑ የአስተናጋጅ ድግግሞሽ የማሽኑ 'ተወላጅ' ድግግሞሽ ሆነ።

ዉሳኔ

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

የTSCን ምናባዊነት ሲያሰናክሉ፣ ከቨርቹዋል ማሽኑ ውስጥ TSCን ማንበብ የአካላዊ ማሽኑን የTSC እሴት ይመልሳል፣ እና TSCን ከቨርቹዋል ማሽኑ ውስጥ መጻፍ ምንም ውጤት የለውም። ምናባዊ ማሽኑን ወደ ሌላ አስተናጋጅ ማዛወር፣ ከተንጠለጠለ ሁኔታ እንደገና ማስጀመር ወይም ወደ ቅጽበታዊ ገጽ እይታ መመለስ TSC ያለማቋረጥ እንዲዘል ያደርገዋል። አንዳንድ የእንግዳ ኦፕሬቲንግ ሲስተሞች የTSC ምናባዊነት ሲሰናከል ማስነሳት ወይም ሌሎች የጊዜ አያያዝ ችግሮችን ማሳየት አይችሉም። ቀደም ሲል፣ ይህ ባህሪ አንዳንድ ጊዜ TSC ን በተደጋጋሚ የሚያነቡ አፕሊኬሽኖችን አፈፃፀም ለማሻሻል ይመከራል።ነገር ግን የቨርቹዋል ቲኤስሲ አፈጻጸም በአሁኑ ምርቶች ላይ በእጅጉ ተሻሽሏል። በቨርቹዋል ማሽኑ ውስጥ ትክክለኛ የእውነተኛ ጊዜ ምንጭ የሚጠይቁ መለኪያዎችን ሲያደርጉ ባህሪው ጥቅም ላይ እንዲውል ይመከራል።

በአጭሩ፣ መለኪያ ማከል ያስፈልግዎታል

የክትትል_ተቆጣጣሪ.ቨርቹዋል_rdtsc = ሐሰት

መደምደሚያ

ምናልባት እያሰቡ ይሆናል፡ SQL GetTimePreciseን ብዙ ጊዜ ለምን መደወል ያስፈልገዋል?

የSQL አገልጋይ ምንጭ ኮድ የለኝም፣ ግን አመክንዮ ይህንን ይገድባል። SQL ልክ እንደ ተባባሪ ተመሳሳይነት ያለው ኦፕሬቲንግ ሲስተም ነው፣ እያንዳንዱ ክር ከጊዜ ወደ ጊዜ መምጣት አለበት። እና ይህን ለማድረግ በጣም ጥሩው ቦታ የት ነው? ተፈጥሯዊ መጠበቅ ባለበት - መቆለፊያ ወይም አይኦ። እሺ፣ ግን የስሌት ዑደቶችን እያሄድን ከሆነስ? ከዚያ ግልጽ እና ብቸኛው ቦታ በአስተርጓሚው ውስጥ ነው (በእርግጥ ተርጓሚ አይደለም)፣ የሚቀጥለውን መግለጫ ከፈጸመ በኋላ።

SQL Server በተለምዶ ለንፁህ ስሌት ጥቅም ላይ አይውልም፣ እና ያ ችግር አይደለም። ሆኖም፣ ጊዜያዊ ሰንጠረዦችን (ወዲያውኑ የተሸጎጡ) የሚያካትቱ ሉፖች ኮዱን በጣም በፍጥነት ወደሚፈጸሙ መግለጫዎች ቅደም ተከተል ይለውጧቸዋል።

በነገራችን ላይ፣ በNatively Compiled ውስጥ አንድን ተግባር ከጠቀለልከው፣ መጠይቅ ማድረግ ያቆማል፣ እና ፍጥነቱ በአስር እጥፍ ይጨምራል። ግን ስለ ተባባሪ ብዙ ስራዎችስ? በተፈጥሯዊ መልኩ ለተቀናጀ ኮድ፣ በSQL ውስጥ PREMPTIVE MULTITASKINGን ማንቃት ነበረብኝ።

ምንጭ: hab.com

አዎ፣ የእኔ የድሮ ላፕቶፕ ከእርስዎ የምርት አገልጋይ በብዙ እጥፍ የበለጠ ኃይለኛ ነው።

ዉሳኔ

መደምደሚያ

ProHoster