បាទ កុំព្យូទ័រយួរដៃចាស់របស់ខ្ញុំមានថាមពលខ្លាំងជាងម៉ាស៊ីនមេផលិតកម្មរបស់អ្នក។

ទាំងនេះពិតជាពាក្យបណ្តឹងដែលខ្ញុំបានឮពីអ្នកអភិវឌ្ឍន៍របស់យើង។ អ្វី​ដែល​គួរ​ឱ្យ​ចាប់​អារម្មណ៍​បំផុត​នោះ​គឺ​ថា​នេះ​បាន​ក្លាយ​ទៅ​ជា​ការ​ពិត​ដែល​ធ្វើ​ឱ្យ​មាន​ការ​ស៊ើប​អង្កេត​ដ៏​យូរ។ យើងនឹងនិយាយអំពីម៉ាស៊ីនមេ 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
ខ្ញុំគួរកត់សំគាល់ថាវាលឿនពេក)

ទោះយ៉ាងណាក៏ដោយ ក្នុងករណីនេះ យើងកំពុងដោះស្រាយជាមួយនឹងលេខសូន្យនៃមុខងារ 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 វិនាទីទេ - កូដដំណើរការលឿនឬយឺតណាស់ នោះគឺជាបញ្ហា ឧបមាថាខ្មៅ និងស។

តើខ្ញុំបានធ្វើអ្វីខ្លះ? បានប្រើរង្វាស់ VMware ។ អ្វីគ្រប់យ៉ាងគឺល្អនៅទីនោះ - មានធនធានច្រើន ពេលវេលាត្រៀមរួចរាល់ = 0 មានអ្វីគ្រប់យ៉ាងគ្រប់គ្រាន់ អំឡុងពេលធ្វើតេស្តលើស៊ីភីយូទាំងល្បឿនលឿន និងយឺតស៊ីភីយូ = 100 នៅលើ vCPU មួយ។ ខ្ញុំបានធ្វើតេស្តដើម្បីគណនាលេខ Pi - ការធ្វើតេស្តបង្ហាញលទ្ធផលដូចគ្នានៅលើម៉ាស៊ីនមេណាមួយ។ ក្លិននៃវេទមន្តខ្មៅកាន់តែរឹងមាំនិងកាន់តែខ្លាំង។

នៅពេលដែលខ្ញុំទៅដល់កសិដ្ឋាន DEV ខ្ញុំចាប់ផ្តើមលេងជាមួយម៉ាស៊ីនមេ។ វាប្រែថា vMotion ពីម៉ាស៊ីនទៅម៉ាស៊ីនអាច "ព្យាបាល" ម៉ាស៊ីនមេ ប៉ុន្តែវាក៏អាចប្រែក្លាយម៉ាស៊ីនមេ "លឿន" ទៅជា "យឺត" ផងដែរ។ វាហាក់ដូចជានេះគឺវា - ម៉ាស៊ីនមួយចំនួនមានបញ្ហា ... ប៉ុន្តែ ... ទេ។ ម៉ាស៊ីននិម្មិតមួយចំនួនមានភាពយឺតយ៉ាវនៅលើម៉ាស៊ីន និយាយថា A ប៉ុន្តែបានដំណើរការយ៉ាងលឿននៅលើម៉ាស៊ីន B។ ហើយម៉ាស៊ីននិម្មិតមួយទៀត ផ្ទុយទៅវិញបានធ្វើការយ៉ាងលឿននៅលើ A និងបន្ថយល្បឿននៅលើ B! ទាំងម៉ាស៊ីន "លឿន" និង "យឺត" តែងតែវិលលើម៉ាស៊ីន!

ចាប់​ពី​ពេល​នោះ​មក មាន​ក្លិន​ស្ពាន់ធ័រ​នៅ​ក្នុង​អាកាស។ យ៉ាងណាមិញបញ្ហាមិនអាចត្រូវបានកំណត់គុណលក្ខណៈម៉ាស៊ីននិម្មិត (ឧទាហរណ៍បំណះវីនដូ) - បន្ទាប់ពីទាំងអស់វាប្រែទៅជា "លឿន" ជាមួយ vMotion ។ ប៉ុន្តែបញ្ហាក៏មិនអាចត្រូវបានកំណត់គុណលក្ខណៈម៉ាស៊ីនដែរ - បន្ទាប់ពីទាំងអស់វាអាចមានទាំងម៉ាស៊ីន "លឿន" និង "យឺត" ។ ដូចគ្នានេះផងដែរនេះមិនទាក់ទងទៅនឹងបន្ទុកទេ - ខ្ញុំបានគ្រប់គ្រងម៉ាស៊ីន "យឺត" នៅលើម៉ាស៊ីនដែលគ្មានអ្វីក្រៅពីវា។

ដោយអស់សង្ឃឹម ខ្ញុំបានបើកដំណើរការ Explorer ពី Sysinternals ហើយមើលលើ 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 ឬចំនួន processors ជារឿយៗធ្វើអោយម៉ាស៊ីនទៅជា "លឿន"។ ប៉ុន្តែមិនមែនជារៀងរហូតទេ។ ប៉ុន្តែអ្វីដែលប្រែទៅជាការពិតគឺថាវាគ្រប់គ្រាន់ហើយក្នុងការចេញទៅក្រៅហើយគោះកង់ - នោះគឺផ្លាស់ប្តូរ любой ប៉ារ៉ាម៉ែត្រម៉ាស៊ីននិម្មិត

ទីបំផុត សហសេវិកអាមេរិករបស់ខ្ញុំស្រាប់តែរកឃើញមូលហេតុដើម។

ម្ចាស់ផ្ទះខុសគ្នាក្នុងប្រេកង់!

• តាមក្បួននេះមិនមែនជាបញ្ហាធំទេ។ ប៉ុន្តែ៖ នៅពេលផ្លាស់ប្តូរពីម៉ាស៊ីន 'ដើម' ទៅម៉ាស៊ីនដែលមានប្រេកង់ 'ខុសគ្នា' 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 ដង។ ចុះកិច្ចការច្រើនដែលសហការគ្នាវិញ? ប៉ុន្តែសម្រាប់កូដដែលបានចងក្រងពីកំណើត យើងត្រូវធ្វើ PREEMPTIVE MULTITASKING នៅក្នុង SQL ។

ប្រភព: www.habr.com