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

ከገንቢዎቻችን የሰማኋቸው ቅሬታዎች ናቸው። በጣም የሚያስደንቀው ነገር ይህ እውነት ሆኖ ተገኝቷል, ይህም ረጅም ምርመራን ያመጣል. በ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 የግብይት ምዝግብ ማስታወሻ ግቤት አካላዊ መጨረሻ መጠበቅ አለበት፣ እና እዚህ በጣም አጭር ግብይቶችን እያደረግን ነው። በግምት፣ አንድ ትልቅ ኃይለኛ የጭነት መኪና ወደ ከተማው ትራፊክ አስገባን፣ እና በስኩተርተር በፒዛ መላኪያ ሰዎች በአስገራሚ ሁኔታ ሲይዘው ተመልክተናል - የትርፍ ጊዜ ማሳለፊያ እዚህ አስፈላጊ አይደለም፣ መዘግየት ብቻ አስፈላጊ ነው። እና ምንም አይነት የአውታረ መረብ ማከማቻ፣ ምንም ያህል ዜሮዎች በዋጋው ውስጥ ቢኖሩ፣ ዘግይቶ አንፃር የአካባቢውን ኤስኤስዲ ማሸነፍ አይችልም።

(በአስተያየቶቹ ውስጥ እንደዋሸሁ ተረጋግጧል - በሁለቱም ቦታዎች ላይ ጥንካሬን ዘግይቼ ነበር.
ዴስክቶፕ - 39 ሰከንድ፣ 15 ኪ ትሪ/ሴኮንድ፣ 0.065ms/io የዙር ጉዞ
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 ፣ ሁሉም ነገር በቂ ነበር ፣ በፈተና ጊዜ በሁለቱም ፈጣን እና ቀርፋፋ አገልጋዮች ሲፒዩ = 100 በአንድ vCPU። የ Pi ቁጥርን ለማስላት ፈተና ወስጃለሁ - ፈተናው በማንኛውም አገልጋይ ላይ ተመሳሳይ ውጤቶችን አሳይቷል. የጥቁር አስማት ሽታ እየጠነከረ እና እየጠነከረ መጣ።

ወደ DEV እርሻ እንደደረስኩ ከአገልጋዮቹ ጋር መጫወት ጀመርኩ. vMotion ከአስተናጋጅ ወደ አስተናጋጅ አገልጋይን “ማከም” ይችላል፣ ነገር ግን “ፈጣን” አገልጋይን ወደ “ቀርፋፋ” መቀየር ይችላል። ይህ ይመስላል - አንዳንድ አስተናጋጆች ችግር አለባቸው ... ግን ... አይደለም. አንዳንድ ቨርቹዋል ማሽን በአስተናጋጅ ላይ ቀርፋፋ ነበር ፣ ግን በአስተናጋጅ B ላይ በፍጥነት ሰርቷል ። እና ሌላ ቨርቹዋል ማሽን ፣ በተቃራኒው ፣ በፍጥነት በኤ ላይ ሰርቷል እና በ B ላይ ቀንሷል! ሁለቱም "ፈጣን" እና "ቀርፋፋ" ማሽኖች ብዙውን ጊዜ በአስተናጋጁ ላይ ይሽከረከሩ ነበር!

ከዚያን ጊዜ ጀምሮ በአየር ውስጥ የተለየ የሰልፈር ሽታ ነበር። ከሁሉም በላይ ችግሩ ለምናባዊው ማሽን (ለምሳሌ የዊንዶውስ ፓቼስ) ሊባል አይችልም - ከሁሉም በላይ በ vMotion ወደ “ፈጣን”ነት ተቀየረ። ነገር ግን ችግሩ በአስተናጋጁ ላይም እንዲሁ ሊባል አይችልም - ከሁሉም በላይ ፣ ሁለቱም “ፈጣን” እና “ቀርፋፋ” ማሽኖች ሊኖሩት ይችላል። በተጨማሪም ፣ ይህ ከጭነቱ ጋር የተገናኘ አልነበረም - በአስተናጋጁ ላይ “ቀርፋፋ” ማሽን ማግኘት ቻልኩ ፣ ከሱ በቀር ምንም ነገር የለም።

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

ntoskrnl.exe!ከSynchronizeExecution+0x5bf6
ntoskrnl.exe!KeWaitForMultipleObjects+0x109d
ntoskrnl.exe!KeWaitForMultipleObjects+0xb3f
ntoskrnl.exe!KeWaitForSingleObject+0x377
ntoskrnl.exe!KeQuerySystemTimePrecise+0x881 <- !!!
ntoskrnl.exe!ObDereferenceObjectDefer ሰርዝ+0x28a
ntoskrnl.exe!ከSynchronizeExecution+0x2de2
sqllang.dll!CDiagThreadSafe::Pxlvl ተካ+0x1a20
... ተዘለለ
sqldk.dll!SystemThread ::MakeMiniSOSThread+0xa54
KERNEL32.DLL!BaseThreadInitThunk+0x14
ntdll.dll!RtlUserThreadጀምር+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 እና በቪኤምዌር ድጋፍ መካከል እርስበርስ ቀስቶችን እንዲያዞሩ የመግባት ስጋት አልነበረም።

ከዚያ መሻሻል ቆመ - ዕረፍት ፣ አስፈላጊ ጉዳዮች ፣ የቫይረስ ሃይስቴሪያ እና ከፍተኛ የሥራ ጫና። ለባልደረቦቼ ብዙ ጊዜ አስማታዊውን ችግር ተናግሬ ነበር፣ ነገር ግን አንዳንድ ጊዜ እነሱ ሁልጊዜም ያመኑኝ አይመስሉም ነበር - ቪኤምዌር ኮዱን ከ10-20 ጊዜ ያዘገየዋል የሚለው መግለጫ በጣም አስፈሪ ነበር።

እያዘገመኝ ያለውን ነገር ራሴን ለማወቅ ሞከርኩ። አንዳንድ ጊዜ መፍትሔ ያገኘሁ መስሎ ይታየኝ ነበር - Hot plugs ን ማብራት እና ማጥፋት፣ የማስታወሻውን መጠን ወይም የአቀነባባሪዎችን ብዛት መለወጥ ብዙውን ጊዜ ማሽኑን ወደ “ፈጣን” ይለውጠዋል። ግን ለዘላለም አይደለም. እውነት ሆኖ የተገኘው ግን ወጥቶ መንኮራኩሩን ማንኳኳቱ በቂ ነው - ማለትም መለወጥ ማንኛውም ምናባዊ ማሽን መለኪያ

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

አስተናጋጆቹ በድግግሞሽ ይለያያሉ!

• እንደ አንድ ደንብ, ይህ ትልቅ ጉዳይ አይደለም. ነገር ግን፡ ከ'ቤተኛ' አስተናጋጅ ወደ 'የተለየ' ፍሪኩዌንሲ ወደ አስተናጋጅ ሲዘዋወሩ፣ 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 ለምን GetTimePrecise ደጋግሞ ይደውላል?

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

በአጠቃላይ የSQL አገልጋይ ለንፁህ ማስላት ጥፍር ጥቅም ላይ አይውልም እና ይህ ችግር አይደለም። ነገር ግን ከሁሉም አይነት ጊዜያዊ ጠረጴዛዎች ጋር የሚሰሩ ቀለበቶች (ወዲያውኑ የተሸጎጡ ናቸው) ኮዱን በፍጥነት ወደተፈጸሙት መግለጫዎች ቅደም ተከተል ይለውጣሉ.

በነገራችን ላይ ተግባሩን በNATIVELY COMPILED ከጠቀልከው ጊዜ መጠየቅ ያቆማል እና ፍጥነቱ በ10 እጥፍ ይጨምራል፡ ስለ ትብብር ብዙ ስራስ? ነገር ግን ቤተኛ ለተጠናቀረ ኮድ በSQL ውስጥ PREEMPTIVE MULTITASKING ማድረግ ነበረብን።

ምንጭ: hab.com