ඔව්, මගේ පැරණි ලැප්ටොප් පරිගණකය ඔබේ නිෂ්පාදන සේවාදායකයට වඩා කිහිප ගුණයකින් බලවත් ය.

මේවා මම අපේ සංවර්ධකයින්ගෙන් ඇසූ ප්‍රකාශයන්ය. වඩාත්ම සිත්ගන්නා කරුණ නම් මෙය සත්‍යයක් බවට පත් වූ අතර එය දිගු විමර්ශනයකට තුඩු දෙයි. අපි 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

මගේ ඩෙස්ක්ටොප් එකේ තත්පර 5 ක් සහ නිෂ්පාදන සේවාදායකයේ තත්පර 28 ක් ගතවේ. SQL ගණුදෙණු ලොගයට ලිවීමේ භෞතික අවසානය එනතෙක් බලා සිටිය යුතු නිසාත්, අපි මෙහි ඉතා කෙටි ගනුදෙනු සිදු කරන නිසාත් ය. දළ වශයෙන් කිවහොත්, අපි විශාල ප්‍රබල ට්‍රක් රථයක් නගර තදබදයට ගෙන ගිය අතර, ස්කූටරවල පීසා බෙදාහරින පුද්ගලයින් ප්‍රසිද්ධ ලෙස එය අභිබවා යන ආකාරය අපි බලා සිටිමු - ප්‍රතිදානය මෙහි වැදගත් නොවේ, ප්‍රමාදය පමණක් වැදගත් වේ. තවද එක් ජාල ගබඩාවකටවත්, එහි මිලෙහි බිංදු කීයක් තිබුණත්, ප්‍රමාදය අනුව දේශීය SSD අභිබවා යාමට නොහැකි වනු ඇත.

(අදහස් දැක්වීමේදී මම බොරු කී බව පෙනී ගියේය - මම ස්ථාන දෙකෙහිම කල්පැවැත්ම ප්‍රමාද කර ඇත. කල්පැවැත්ම ප්‍රමාද නොකර එය හැරෙන්නේ:
ඩෙස්ක්ටොප් - තත්පර 39, 15K tr/sec, 0.065ms /io වට සංචාරය
PROD - තත්පර 360, 1600 tr/sec, 0.6ms
එය ඉතා වේගවත් බව මම දැක ගත යුතුව තිබුණි)

කෙසේ වෙතත්, මෙම අවස්ථාවෙහිදී අපි සුළු උදාහරණයක් සමඟ Riemann zeta ශ්‍රිතයේ සුළු ශුන්‍ය සමඟ කටයුතු කරන්නෙමු. සංවර්ධකයින් මට ගෙන ආ උදාහරණයේ එය වෙනස් විය. ඔවුන් නිවැරදි බව මට ඒත්තු ගිය අතර, උදාහරණයෙන් ව්‍යාපාරික තර්කයට අදාළ ඔවුන්ගේ සියලු විශේෂතා පිරිසිදු කිරීමට පටන් ගත්තේය. යම් අවස්ථාවක දී, මට ඔවුන්ගේ කේතය සම්පූර්ණයෙන්ම ඉවත දැමිය හැකි බවත්, මගේම ලිවීමට හැකි බවත් මම තේරුම් ගත්තෙමි - එය එකම ගැටළුව පෙන්නුම් කරයි - නිෂ්පාදනයේදී එය 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 ක් ගතවන සේවාදායකයන් නොතිබීමයි - කේතය ඉතා ඉක්මනින් හෝ ඉතා සෙමින් ක්‍රියාත්මක විය, එනම්, ගැටළුව වූයේ කළු සහ සුදු යැයි කියමු.

මම මොනවද කරලා තියෙන්නේ? වීඑම්වෙයාර් ප්‍රමිතික වලට ඇතුල් විය. එහි සෑම දෙයක්ම හොඳින් විය - සම්පත් ඕනෑ තරම් තිබුණි, සූදානම් කාලය = 0, සෑම දෙයක්ම ප්රමාණවත් විය, පරීක්ෂණය අතරතුර වේගවත් සහ මන්දගාමී සේවාදායකයන් මත CPU = 100 එක් vCPU මත. මම Pi ගණන ගණනය කිරීමට පරීක්ෂණයක් කළා - පරීක්ෂණය ඕනෑම සේවාදායකයක එකම ප්‍රතිඵල පෙන්වයි. කළු මැජික් සුවඳ තව තවත් ශක්තිමත් විය.

DEV ගොවිපලෙන් පිටතට ගිය මම සේවාදායකයන් සමඟ සෙල්ලම් කිරීමට පටන් ගතිමි. ධාරකයේ සිට ධාරකයට vMotion මඟින් සේවාදායකයක් “සුව” කළ හැකි නමුත් එයට “වේගවත්” සේවාදායකයක් “මන්දගාමී” එකක් බවට පත් කළ හැකි බව පෙනී ගියේය. එය මෙය බව පෙනේ - සමහර සත්කාරකයන්ට ගැටලුවක් ඇත ... නමුත් ... නැත. සමහර අතථ්‍ය යන්ත්‍ර ධාරකයේ වේගය අඩු විය, කියන්න, A, නමුත් ධාරක B හි ඉක්මනින් ක්‍රියා කළේය. අනෙක් අතථ්‍ය යන්ත්‍රය, ඊට ප්‍රතිවිරුද්ධව, A මත වේගයෙන් ක්‍රියා කර B මත මන්දගාමී විය! "වේගවත්" සහ "මන්දගාමී" මෝටර් රථ දෙකම බොහෝ විට ධාරකය මත කැරකෙමින් තිබුණි!

ඒ මොහොතේ සිට වාතයේ සල්ෆර් සුවඳක් පැතිර ගියේය. සියල්ලට පසු, ගැටළුව කිසිදු අතථ්‍ය යන්ත්‍රයකට ආරෝපණය කළ නොහැක (උදාහරණයක් ලෙස වින්ඩෝස් පැච්) - සියල්ලට පසු, එය vMotion සමඟ “වේගවත්” එකක් බවට පත් විය. නමුත් ගැටළුව ධාරකයට ආරෝපණය කළ නොහැක - සියල්ලට පසු, එයට “වේගවත්” සහ “මන්දගාමී” යන්ත්‍ර දෙකම තිබිය හැකිය. එය ද බරට සම්බන්ධ නොවේ - ධාරකයේ “මන්දගාමී” යන්ත්‍රයක් ලබා ගැනීමට මට හැකි විය, එය හැර වෙනත් කිසිවක් නොතිබුණි.

බලාපොරොත්තු සුන්වීම නිසා, මම Sysinternals' Process Explorer ගිනිබත් කර SQL තොගය දෙස බැලුවෙමි. මන්දගාමී යන්ත්‍රවල, රේඛාව වහාම මගේ ඇසට හසු විය:

ntoskrnl.exe!KeSynchronizeExecution+0x5bf6
ntoskrnl.exe!KeWaitForMultiple Objects+0x109d
ntoskrnl.exe!KeWaitForMultiple Objects+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 වාරයක් (!!!) වේ. මෙය දැනටමත් කුඩා ජයග්‍රහණයක් විය: ඕනෑම අවස්ථාවක, මයික්‍රොසොෆ්ට් සහ වීඑම්වෙයාර් සහාය අතර සිරවී සිටීමේ තර්ජනයක් නොතිබූ අතර එමඟින් ඒවා එකිනෙකට ඊතල මාරු වනු ඇත.

එවිට ප්රගතිය නතර විය - නිවාඩු, වැදගත් දේවල්, වෛරස් හිස්ටීරියාව සහ වැඩ බරෙහි තියුණු වැඩිවීමක්. මම බොහෝ විට සගයන්ට ඉන්ද්‍රජාලික ගැටලුව ගැන සඳහන් කළ නමුත් සමහර අවස්ථාවලදී ඔවුන් මාව විශ්වාස නොකරන බවක් පෙනෙන්නට තිබුණි - VMware කේතය 10-20 ගුණයකින් මන්දගාමී කළ බවට වූ ප්‍රකාශය ඉතා භයානක විය.

එය මන්දගාමී වන්නේ කුමක් දැයි මම මා විසින්ම හාරා ගැනීමට උත්සාහ කළෙමි. සමහර අවස්ථාවලදී මට පෙනුනේ මම විසඳුමක් සොයාගෙන ඇති බවයි - Hot ප්ලග් සක්‍රිය සහ අක්‍රිය කිරීම, මතකයේ ප්‍රමාණය හෝ ප්‍රොසෙසර ගණන වෙනස් කිරීම බොහෝ විට යන්ත්‍රය “වේගවත් එකක්” බවට පත් කළේය. නමුත් සදහටම නොවේ. නමුත් සත්‍ය වූයේ පිටතට ගොස් රෝදයට තට්ටු කිරීම ප්‍රමාණවත් බවයි - එනම් වෙනස් කිරීමට කිසිවක් නැත අතථ්‍ය යන්ත්‍ර පරාමිතිය

අවසාන වශයෙන්, මගේ ඇමරිකානු සගයන් හදිසියේම මූලික හේතුවක් සොයා ගත්හ.

ධාරක සංඛ්‍යාතයෙන් වෙනස් විය!

• රීතියක් ලෙස, මෙය බියජනක නොවේ. නමුත්: 'ස්වදේශීය' ධාරකයක සිට 'වෙනස්' සංඛ්‍යාතයක් සහිත ධාරකයකට මාරු වන විට, 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 සේවාදායකය පිරිසිදු පරිගණනය සඳහා භාවිතා නොකරන අතර මෙය ගැටළුවක් නොවේ. නමුත් සියලුම ආකාරයේ තාවකාලික වගු සමඟ වැඩ සහිත චක්‍ර (වහාම හැඹිලිගත කර ඇති) කේතය ඉතා ඉක්මනින් ක්‍රියාත්මක කරන ලද ප්‍රකාශ අනුපිළිවෙලක් බවට පත් කරයි.

මාර්ගය වන විට, ශ්‍රිතය ස්වදේශීය ලෙස සම්පාදනය කර තිබේ නම්, එය කාලය ඉල්ලීම නවත්වන අතර එහි වේගය 10 ගුණයකින් වැඩි වේ. නමුත් සමුපකාර බහුකාර්යය ගැන කුමක් කිව හැකිද? නමුත් ස්වදේශිකව සම්පාදනය කරන ලද කේතය සඳහා, මට SQL හි පූර්ව බහු කාර්ය සාධනය කිරීමට සිදු විය.

මූලාශ්රය: www.habr.com