هو، زما زوړ لپ ټاپ ستاسو د تولید سرور څخه څو ځله ډیر پیاوړی دی.

دا په حقیقت کې هغه شکایتونه دي چې ما زموږ د پراختیا کونکو څخه اوریدلي دي. تر ټولو په زړه پورې خبره دا ده چې دا ریښتیا ثابته شوه، چې اوږد تحقیق ته وده ورکوي. موږ به د SQL سرورونو په اړه وغږیږو چې په VMware کې چلیږي.

په حقیقت کې ، دا ډاډ ترلاسه کول اسانه دي چې د تولید سرور په نا امیدۍ سره د لپ ټاپ شاته دی. کوډ اجرا کړئ (نه په 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

زما په ډیسټاپ کې دا 5 ثانیې وخت نیسي، او د تولید سرور کې دا 28 ثانیې وخت نیسي. ځکه چې SQL باید د لیږد د ننوتلو فزیکي پای ته انتظار وکړي، او موږ دلته خورا لنډ لیږدونه کوو. په لنډه توګه، موږ د ښار ټرافیک ته یو لوی، ځواکمن ټرک وګرځاوه، او ولیدل چې دا په سکوټرونو کې د پیزا رسولو خلکو لخوا په ډیره بې رحمۍ سره تیریږي - د ټروپټ دلته مهم ندي، یوازې ځنډ مهم دی. او د شبکې هیڅ ذخیره نده ، مهمه نده چې د دې قیمت کې څومره صفر شتون لري ، د ځنډ په شرایطو کې ځایی SSD ماتولی شي.

(په تبصرو کې دا معلومه شوه چې ما درواغ ویلي - ما په دواړو ځایونو کې پایښت ځنډولی و. پرته له ځنډه دوام پای ته رسیږي:
ډیسټاپ - 39 ثانیې، 15K tr/sec، 0.065ms/io roundtrip
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 سره "چټک" بدل شو. مګر ستونزه هم کوربه ته منسوب کیدی نشي - په هرصورت، دا کیدای شي دواړه "چټک" او "سست" ماشینونه ولري. همچنان ، دا د بار سره تړاو نه درلود - ما په کوربه کې د "سست" ماشین ترلاسه کولو اداره وکړه ، چیرې چې پرته له دې بل هیڅ نه و.

د نا امیدۍ څخه ، ما د سیسینټرالز څخه د پروسې اکسپلورر پیل کړ او د 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 ځله دی (!!!). دا لا دمخه یوه کوچنۍ بریا وه: په هر حالت کې ، د مایکروسافټ او 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 = غلط

پایلې

تاسو شاید یوه پوښتنه ولرئ: ولې SQL ډیری وختونه GetTimePrecise ته زنګ وهي؟

زه د SQL سرور سرچینې کوډ نلرم، مګر منطق دا وايي. ایس کیو ایل تقریبا یو عملیاتي سیسټم دی چې د کوپراتیف همغږي لري، چیرې چې هر تار باید وخت په وخت "ورکړل شي". د دې کولو لپاره غوره ځای چیرته دی؟ چیرته چې طبیعي انتظار شتون لري - لاک یا IO. سمه ده، مګر که چیرې موږ کمپیوټري لوپونه وګرځوو؟ بیا څرګند او نږدې یوازې ځای په ترجمان کې دی (دا واقعیا ژباړونکی ندی) ، د راتلونکي بیان اجرا کولو وروسته.

عموما، د SQL سرور د خالص کمپیوټري نیلینګ لپاره نه کارول کیږي او دا کومه ستونزه نده. مګر لوپونه چې د هر ډول موقتي جدولونو سره کار کوي (کوم چې سمدلاسه زیرمه شوي) کوډ د خورا ګړندي اجرا شوي بیانونو په ترتیب بدلوي.

په هرصورت، که تاسو په NATIVELY COMPILED کې فنکشن وتړئ، نو دا د وخت غوښتنه بندوي، او سرعت یې 10 ځله زیاتیږي. د کوپراتیف ملټي ټاسک کولو په اړه څه؟ مګر د اصلي تالیف شوي کوډ لپاره موږ باید په SQL کې پرییمپٹیو ملټي ټاسکنګ ترسره کړو.

سرچینه: www.habr.com