ဟုတ်ပါသည်၊ ကျွန်ုပ်၏ လက်ပ်တော့ဟောင်းသည် သင့်ထုတ်လုပ်သည့် ဆာဗာထက် အဆများစွာ ပိုအစွမ်းထက်ပါသည်။

ဤသည်မှာ ကျွန်ုပ်တို့၏ ဆော့ဖ်ဝဲရေးသားသူများထံမှ ကြားလိုက်ရသော တိုင်ကြားစာများဖြစ်သည်။ စိတ်ဝင်စားစရာအကောင်းဆုံးအချက်မှာ ဤအရာသည် အမှန်ဖြစ်လာပြီး ရှည်လျားသော စုံစမ်းစစ်ဆေးမှုကို ဖြစ်ပေါ်စေခြင်းပင်ဖြစ်သည်။ VMware တွင်လည်ပတ်သော SQL ဆာဗာများအကြောင်းပြောပါမည်။

တကယ်တော့၊ ထုတ်လုပ်မှုဆာဗာသည် လက်ပ်တော့၏နောက်ကွယ်တွင် မျှော်လင့်ချက်မရှိကြောင်း သေချာစေရန် လွယ်ကူသည်။ ကုဒ်ကို လုပ်ဆောင်ပါ (tempdb တွင်မဟုတ်ဘဲ နှောင့်နှေးကြာရှည်ခံနိုင်မှု ဖွင့်ထားသည့် ဒေတာဘေ့စ်ပေါ်တွင် မဟုတ်ဘဲ) ကုဒ်ကို လုပ်ဆောင်ပါ။

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

ကျွန်ုပ်၏ဒက်စ်တော့တွင် ၅ စက္ကန့်ကြာပြီး ထုတ်လုပ်မှုဆာဗာတွင် ၂၈ စက္ကန့်ကြာသည်။ အဘယ်ကြောင့်ဆိုသော် SQL သည် ငွေပေးငွေယူ မှတ်တမ်းဝင်ရောက်မှု၏ ရုပ်ပိုင်းဆိုင်ရာအဆုံးကို စောင့်ရမည်ဖြစ်ပြီး၊ ကျွန်ုပ်တို့သည် ဤနေရာတွင် အလွန်တိုတောင်းသော ငွေပေးငွေယူများကို လုပ်ဆောင်နေသောကြောင့်ဖြစ်သည်။ အကြမ်းဖျင်းပြောရလျှင် ကျွန်ုပ်တို့သည် ကြီးမားပြီး အားကောင်းသော ထရပ်ကားကို မြို့တွင်းအသွားအလာသို့ မောင်းနှင်ကာ စကူတာပေါ်ရှိ ပီဇာပေးပို့သူများ၏ အရှိန်ပြင်းပြင်းဖြင့် ကျော်တက်သွားသည်ကို စောင့်ကြည့်ခဲ့သည် - ဖြတ်သန်းမှုသည် ဤနေရာတွင် အရေးမကြီးပါ၊ latency သာလျှင် အရေးကြီးပါသည်။ ၎င်း၏စျေးနှုန်းတွင် သုညမည်မျှရှိသည်ဖြစ်စေ ကွန်ရက်သိုလှောင်မှုမည်မျှပင်မရှိစေကာမူ၊ latency သတ်မှတ်ချက်ဖြင့် ပြည်တွင်း SSD ကို အနိုင်ယူနိုင်သည်။

(မှတ်ချက်များတွင် ကျွန်ုပ်လိမ်ညာမိသည်- ကျွန်ုပ်သည် နေရာနှစ်ခုလုံးတွင် တာရှည်ခံမှုကို နှောင့်နှေးစေပါသည်။ နှောင့်နှေးကြာရှည်ခံမှုမရှိဘဲ ပေါ်လာသည်-
ဒက်စ်တော့ - 39 စက္ကန့်၊ 15K tr/sec၊ 0.065ms /io အသွားအပြန်
PROD - 360 စက္ကန့်၊ 1600 tr/sec၊ 0.6ms
အရမ်းမြန်တာကို သတိပြုမိသင့်ပါတယ်)

သို့သော်၊ ဤကိစ္စတွင်၊ ကျွန်ုပ်တို့သည် အသေးအဖွဲ ဥပမာတစ်ခုဖြင့် Riemann zeta လုပ်ဆောင်ချက်၏ အသေးအဖွဲသုညနှင့် ဆက်ဆံနေပါသည်။ developer များကကျွန်ုပ်ကိုယူဆောင်ခဲ့သောဥပမာတွင်၊ ကွဲပြားသည်။ သူတို့ပြောတာမှန်တယ်လို့ ကျွန်တော်ယုံကြည်ခဲ့ပြီး စီးပွားရေးယုတ္တိနဲ့ပတ်သက်တဲ့ သူတို့ရဲ့အသေးစိတ်အချက်အလက်အားလုံးကို ဥပမာကနေ ဖယ်ရှားခဲ့တယ်။ တစ်ချိန်ချိန်မှာတော့ သူတို့ရဲ့ ကုဒ်တွေကို လုံး၀ စွန့်ပစ်ပြီး တူညီတဲ့ ပြဿနာကို သရုပ်ပြတဲ့ ငါ့ကိုယ်ပိုင် ရေးချနိုင်တယ်ဆိုတာ သိလာတယ် - ထုတ်လုပ်မှုမှာ 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

အားလုံးအဆင်ပြေပါက နံပါတ်တစ်ခု၏ primality ကိုစစ်ဆေးခြင်းသည် 6-7-8 စက္ကန့်ကြာမည်ဖြစ်သည်။ ၎င်းသည် ဆာဗာများစွာတွင် ဖြစ်ပွားခဲ့သည်။ သို့သော် အချို့သောစစ်ဆေးမှုသည် 25-40 စက္ကန့်ကြာသည်။ စိတ်ဝင်စားစရာကောင်းတာက၊ ကုဒ်က 14 စက္ကန့်ကြာတဲ့ execution လုပ်မယ့်ဆာဗာတွေမရှိခဲ့ဘူး - ကုဒ်က အရမ်းမြန်တယ် ဒါမှမဟုတ် အရမ်းနှေးတယ် ဆိုလိုတာက ပြဿနာက အဖြူအမည်းဆိုပါစို့။

ငါဘာတွေလုပ်ပြီးပြီလဲ။ VMware တိုင်းတာမှုများကို အသုံးပြုထားသည်။ အဲဒီမှာ အရာအားလုံးအဆင်ပြေပါတယ် - အရင်းအမြစ်များစွာရှိပါသည်၊ အဆင်သင့်အချိန် = 0၊ အားလုံးလုံလောက်ပါသည်၊ အမြန်နှင့်နှေးသောဆာဗာနှစ်ခုလုံးတွင်စမ်းသပ်နေစဉ် CPU = 100 vCPU တစ်ခုတည်းတွင်ဖြစ်သည်။ Pi နံပါတ်ကို တွက်ချက်ရန် စမ်းသပ်မှုတစ်ခု ပြုလုပ်ခဲ့သည် - စမ်းသပ်မှုသည် မည်သည့်ဆာဗာတွင်မဆို တူညီသောရလဒ်များကို ပြသခဲ့သည်။ အောက်လမ်းပညာ၏ အနံ့သည် ပို၍ ပြင်းထန်လာသည်။

ကျွန်တော် DEV ခြံကိုရောက်တာနဲ့ ဆာဗာတွေနဲ့ စတင်ကစားခဲ့တယ်။ host တစ်ခုမှ host တစ်ခုသို့ vMotion သည် ဆာဗာတစ်ခုအား "ကုသ" နိုင်သော်လည်း ၎င်းသည် "fast" server ကို "slow" တစ်ခုအဖြစ်သို့လည်း ပြောင်းလဲပေးနိုင်သည်။ ဒီလိုပုံရတယ် - တချို့အိမ်ရှင်တွေမှာ ပြဿနာရှိပေမယ့်... မဟုတ်ဘူး။ အချို့သော virtual machine သည် host တွင်နှေးကွေးနေသည်ဟု A ကပြောသော်လည်း host B တွင်လျင်မြန်စွာအလုပ်လုပ်သည်။ အခြား virtual machine သည် A တွင်လျင်မြန်စွာအလုပ်လုပ်ပြီး B တွင်နှေးကွေးသည်။ "မြန်" နှင့် "နှေးသော" စက်နှစ်ခုလုံးသည် အိမ်ရှင်အပေါ် မကြာခဏ လည်ပတ်နေပါသည်။

ထိုအချိန်မှစ၍ လေထုထဲတွင် ဆာလဖာ၏ ထူးခြားသော အနံ့တစ်ခု ထွက်ပေါ်လာသည်။ နောက်ဆုံးတွင်၊ ပြဿနာကို virtual machine (ဥပမာ၊ Windows ဖာထေးမှုများ) ကြောင့်ဟု သတ်မှတ်၍မရပါ - ပြီးနောက်၊ ၎င်းသည် vMotion ဖြင့် "မြန်" အဖြစ်သို့ ပြောင်းလဲသွားသည်။ သို့သော် ပြဿနာကို အိမ်ရှင်ဟု သတ်မှတ်၍မရပါ - ပြီးနောက်၊ ၎င်းတွင် "မြန်" နှင့် "နှေးသော" စက်များ နှစ်မျိုးလုံးရှိနိုင်သည်။ ထို့အပြင်၊ ၎င်းသည်ဝန်နှင့်မသက်ဆိုင်ပါ - ကျွန်ုပ်သည် host တွင် "နှေးကွေးသော" စက်ကိုရနိုင်သည်၊ ၎င်းမှလွဲ၍ဘာမှမရှိပါ။

စိတ်ပျက်အားငယ်စွာဖြင့် Sysinternals မှ Process Explorer ကိုဖွင့်ပြီး SQL stack ကိုကြည့်ရှုခဲ့သည်။ နှေးကွေးတဲ့ စက်တွေမှာ လိုင်းက ချက်ချင်း မျက်စိကျသွားတယ်။

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::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 သန်း လည်ပတ်နှုန်းကို ပြသနိုင်ပြီး အနှေးစက်များတွင် တစ်သန်းခွဲ သို့မဟုတ် 700 ပင် ပြသနေပါသည်။ ဆိုလိုသည်မှာ ခြားနားချက်မှာ 10-20 အဆ (!!!) ဖြစ်သည်။ ဒါဟာ သေးငယ်တဲ့ အောင်ပွဲတစ်ခု ဖြစ်နေပါပြီ- ဘယ်လိုပဲဖြစ်ဖြစ်၊ Microsoft နဲ့ VMware ပံ့ပိုးမှုကြားထဲမှာ မြှားတွေ လှန်ပစ်ဖို့ ခြိမ်းခြောက်မှု မရှိပါဘူး။

ထို့နောက် တိုးတက်မှုရပ်တန့်သွားသည် - အားလပ်ရက်များ၊ အရေးကြီးသောကိစ္စများ၊ ဗိုင်းရပ်ဒေါသူပုန်ထခြင်းနှင့် အလုပ်တာဝန်များ သိသိသာသာတိုးလာသည်။ ကျွန်ုပ်၏လုပ်ဖော်ကိုင်ဖက်များအား မှော်ပြဿနာကို မကြာခဏပြောပြသော်လည်း တစ်ခါတစ်ရံတွင် ၎င်းတို့သည် ကျွန်ုပ်ကို အမြဲပင် မယုံကြပုံရသည် - VMware သည် ကုဒ်ကို အကြိမ် 10-20 ဖြင့် နှေးကွေးစေသည်ဟူသော စကားသည် အလွန်နက်နဲလှသည်။

နှောင့်နှေးစေတဲ့အရာတွေကို ကိုယ့်ကိုယ်ကိုယ် ဖော်ထုတ်ဖို့ ကြိုးစားခဲ့တယ်။ တစ်ခါတလေမှာ အဖြေတစ်ခုကို ရှာတွေ့ခဲ့တယ် - Hot plugs တွေကို အဖွင့်အပိတ်လုပ်ခြင်း၊ memory ပမာဏကို ပြောင်းလဲခြင်း သို့မဟုတ် ပရိုဆက်ဆာအရေအတွက်ကို ပြောင်းလဲခြင်းဖြင့် စက်ကို "fast" အဖြစ်သို့ ပြောင်းလဲပေးလေ့ရှိပါတယ်။ ဒါပေမယ့် ထာဝရမဟုတ်ဘူး။ ဒါပေမယ့် အမှန်ဖြစ်လာတာကတော့ အပြင်ထွက်ပြီး ဘီးခေါက်တာ လုံလောက်ပါပြီ - ဆိုလိုသည်မှာ ပြောင်းလဲခြင်းပင်ဖြစ်သည်။ မည်သည့် virtual machine parameter

နောက်ဆုံးမှာတော့ ကျွန်တော့်ရဲ့ အမေရိကန်လုပ်ဖော်ကိုင်ဖက်တွေက အကြောင်းရင်းကို ရုတ်တရက် တွေ့ရှိခဲ့ပါတယ်။

အိမ်ရှင်များသည် အကြိမ်ရေ ကွဲပြားသည်။

• စည်းကမ်းအရ၊ ဒါက ကြီးကြီးမားမားတော့ မဟုတ်ပါဘူး။ သို့သော်- 'ဇာတိ' ဝန်ဆောင်မှ 'ကွဲပြားခြားနားသော' ကြိမ်နှုန်းရှိသော host သို့ပြောင်းသောအခါ၊ VMware သည် GetTimePrecise ရလဒ်ကို ချိန်ညှိရပါမည်။
• စည်းကမ်းအရ၊ SQL server ကဲ့သို့ တစ်စက္ကန့်လျှင် အကြိမ်ပေါင်း သန်းနှင့်ချီသော အချိန်အတိအကျကို တောင်းဆိုသည့် အပလီကေးရှင်းတစ်ခုမှ မရှိလျှင် ၎င်းသည် ပြဿနာမဟုတ်ပါ။
• ဒါပေမယ့် SQL server က ဒါကို အမြဲမလုပ်တဲ့အတွက် ကြောက်စရာမဟုတ်ပါဘူး (နိဂုံးကိုကြည့်ပါ)

ဒါပေမယ့် ဒီကောင့်ကို ပြင်းပြင်းထန်ထန် ထိမိတဲ့ ကိစ္စတွေလည်း ရှိတယ်။ သို့တိုင်၊ ဟုတ်ပါသည်၊ ဘီးကိုနှိပ်ခြင်းဖြင့် (VM ဆက်တင်များတွင် တစ်ခုခုကိုပြောင်းလဲခြင်းဖြင့်) ကျွန်ုပ်သည် VMware ၏ဖွဲ့စည်းပုံကို 'ပြန်လည်တွက်ချက်ရန်' ခိုင်းစေခဲ့ပြီး လက်ရှိလက်ခံသူ၏ကြိမ်နှုန်းသည် စက်၏ 'ဇာတိ' ကြိမ်နှုန်းဖြစ်လာခဲ့သည်။

ဆုံးဖြတ်ချက်

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

TSC ၏ virtualization ကို သင်ပိတ်ထားသောအခါ၊ TSC ကို virtual machine အတွင်းမှဖတ်ခြင်းသည် ရုပ်ပိုင်းဆိုင်ရာစက်၏ TSC တန်ဖိုးကို ပြန်ပေးသည်၊ နှင့် TSC ကို virtual machine အတွင်းမှရေးသားခြင်းသည် အကျိုးသက်ရောက်မှုမရှိပါ။ virtual machine ကို အခြား host သို့ ပြောင်းရွှေ့ခြင်း၊ ရပ်ဆိုင်းထားသော အခြေအနေမှ ပြန်လည်စတင်ခြင်း သို့မဟုတ် လျှပ်တစ်ပြက်ပုံတစ်ခုသို့ ပြန်သွားခြင်းသည် TSC ကို အဆက်မပြတ်ခုန်သွားစေပါသည်။ TSC virtualization ကိုပိတ်ထားသောအခါ အချို့သောဧည့်သည်လည်ပတ်မှုစနစ်များသည် စတင်ရန်ပျက်ကွက်ခြင်း သို့မဟုတ် အခြားအချိန်ထိန်းခြင်းပြဿနာများကိုပြသခြင်းမပြုပါ။ ယခင်က၊ ဤအင်္ဂါရပ်သည် TSC ကို မကြာခဏဖတ်ရှုသည့် အပလီကေးရှင်းများ၏ စွမ်းဆောင်ရည်ကို မြှင့်တင်ရန် တစ်ခါတစ်ရံ အကြံပြုထားသည်။သို့သော် လက်ရှိ ထုတ်ကုန်များတွင် virtual TSC ၏ စွမ်းဆောင်ရည်ကို သိသိသာသာ မြှင့်တင်ထားသည်။ virtual machine တွင် အချိန်နှင့်တပြေးညီ တိကျသောအရင်းအမြစ်လိုအပ်သော တိုင်းတာမှုများလုပ်ဆောင်သည့်အခါတွင်လည်း အသုံးပြုရန် အကြံပြုထားပါသည်။

အတိုချုပ်ပြောရရင်၊ သင် parameter ကိုထည့်ဖို့လိုပါတယ်။

monitor_control.virtual_rdtsc = FALSE

ကောက်ချက်

သင့်တွင်မေးခွန်းတစ်ခုရှိနိုင်သည်- SQL သည် GetTimePrecise ကိုအဘယ်ကြောင့်ဤမျှမကြာခဏခေါ်ဆိုသနည်း။

ကျွန်ုပ်တွင် SQL ဆာဗာရင်းမြစ်ကုဒ်မရှိသော်လည်း လော့ဂျစ်က ဤသို့ဆိုသည်။ SQL သည် ချိတ်ဆက်မှုတစ်ခုစီအား အခါအားလျော်စွာ “ပေးဆောင်ရမည်” ဖြစ်သည့် ပူးပေါင်းဆောင်ရွက်သော ပေါင်းစပ်ငွေကြေးဖြင့် လည်ပတ်သည့်စနစ်နီးပါးဖြစ်သည်။ ဒီလိုလုပ်ဖို့ အကောင်းဆုံးနေရာက ဘယ်မှာလဲ။ သဘာဝအတိုင်း စောင့်ဆိုင်းခြင်း - သော့ခတ်ခြင်း သို့မဟုတ် IO။ ကောင်းပြီ၊ ငါတို့က ကွန်ပြူတာလှည့်ပတ်နေရင် ဘယ်လိုလုပ်မလဲ။ ထို့နောက် ရှင်းရှင်းလင်းလင်းနှင့် တစ်ခုတည်းသောနေရာသည် စကားပြန်တွင် (ဤစကားပြန်မဟုတ်ပါ)၊

ယေဘူယျအားဖြင့်၊ SQL server ကို စစ်မှန်သော ကွန်ပြူတာ လက်ဆွဲခြင်းအတွက် အသုံးမချပါ၊ ၎င်းသည် ပြဿနာမဟုတ်ပါ။ သို့သော် ယာယီဇယားများ (ချက်ချင်း ကက်ရှ်ထားသည့်) အမျိုးအစားအားလုံးနှင့် အလုပ်လုပ်သည့် ကွက်များသည် ကုဒ်ကို အလွန်လျင်မြန်စွာ လုပ်ဆောင်ပြီးသော ထုတ်ပြန်ချက်များ၏ စည်းရိုးတစ်ခုအဖြစ်သို့ ပြောင်းလဲသွားသည်။

စကားမစပ်၊ အကယ်၍ သင်သည် လုပ်ဆောင်ချက်ကို NATIVELY Compiled ဖြင့် ခြုံထားပါက၊ ၎င်းသည် အချိန်တောင်းခြင်း ရပ်သွားပြီး ၎င်း၏ အမြန်နှုန်းသည် 10 ဆ တိုးလာသည်။ ဒါပေမယ့် မူရင်းစုစည်းထားတဲ့ code အတွက် SQL မှာ PREEMPTIVE MULTITASKING လုပ်ရပါမယ်။

source: www.habr.com