დიახ, ჩემი ძველი ლეპტოპი რამდენჯერმე უფრო ძლიერია ვიდრე თქვენი წარმოების სერვერი.

ეს არის ზუსტად ის ჩივილები, რაც მე მოვისმინე ჩვენი დეველოპერებისგან. ყველაზე საინტერესო ის არის, რომ ეს სიმართლე აღმოჩნდა, რამაც გამოიწვია ხანგრძლივი გამოძიება. ჩვენ ვისაუბრებთ SQL სერვერებზე, რომლებიც მუშაობენ VMware-ზე.

სინამდვილეში, ადვილია იმის უზრუნველყოფა, რომ წარმოების სერვერი უიმედოდ დგას ლეპტოპის უკან. შეასრულეთ (არა tempdb-ზე და არა მონაცემთა ბაზაში ჩართული Delayed Durability) კოდი:

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 ტრ/წმ, 0.065ms/io ორმხრივი
PROD - 360 წამი, 1600 ტრ/წმ, 0.6 ms
უნდა შემემჩნია, რომ ძალიან სწრაფი იყო)

თუმცა, ამ შემთხვევაში საქმე გვაქვს რიმანის ზეტა ფუნქციის ტრივიალურ ნულებთან ტრივიალური მაგალითით. იმ მაგალითში, რომელიც დეველოპერებმა მომიტანეს, სხვაგვარად იყო. მე დავრწმუნდი, რომ ისინი მართლები იყვნენ და დავიწყე მაგალითიდან ამოღება მათი ყველა სპეციფიკის, რომელიც დაკავშირებულია ბიზნეს ლოგიკასთან. რაღაც მომენტში მივხვდი, რომ შემეძლო მთლიანად გადავაგდო მათი კოდი და დავწერო ჩემი - რაც იგივე პრობლემას აჩვენებს - წარმოებაში ის 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-ზე! მასპინძელზე ხშირად ტრიალებდნენ როგორც „სწრაფი“ და „ნელი“ მანქანები!

იმ მომენტიდან ჰაერში გოგირდის მკვეთრი სუნი იდგა. ყოველივე ამის შემდეგ, პრობლემა არ შეიძლება მიეკუთვნებოდეს ვირტუალურ მანქანას (მაგალითად, Windows პატჩები) - ბოლოს და ბოლოს, ის გადაიქცა "სწრაფად" vMotion-ით. მაგრამ პრობლემა ასევე არ შეიძლება მიეწეროს მასპინძელს - ბოლოს და ბოლოს, მას შეიძლება ჰქონდეს როგორც "სწრაფი" და "ნელი" მანქანები. ასევე, ეს არ იყო დაკავშირებული დატვირთვასთან - მე მოვახერხე მასპინძელზე "ნელი" აპარატის მოპოვება, სადაც ამის გარდა საერთოდ არაფერი იყო.

სასოწარკვეთილებისგან გავუშვი Process Explorer Sysinternals-დან და გადავხედე 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-ჯერ (!!!). ეს უკვე მცირე გამარჯვება იყო: ყოველ შემთხვევაში, Microsoft-ისა და VMware-ის მხარდაჭერას შორის გაჭედვის საფრთხე არ არსებობდა, რათა მათ ისრები ერთმანეთზე გადასცემდნენ.

შემდეგ პროგრესი შეჩერდა - არდადეგები, მნიშვნელოვანი საკითხები, ვირუსული ისტერია და დატვირთვის მკვეთრი ზრდა. მე ხშირად ვახსენებდი ჩემს კოლეგებს ჯადოსნურ პრობლემას, მაგრამ ზოგჯერ მეჩვენებოდა, რომ მათ ყოველთვის არ სჯეროდათ ჩემი - განცხადება, რომ VMware ანელებს კოდს 10-20-ჯერ, ძალიან ამაზრზენი იყო.

ვცდილობდი გამომეტანა, რაც მანელებდა. ზოგჯერ მეჩვენებოდა, რომ ვიპოვე გამოსავალი - ცხელი შტეფსლების ჩართვა და გამორთვა, მეხსიერების რაოდენობის შეცვლა ან პროცესორების რაოდენობა ხშირად აქცევდა მანქანას "სწრაფად". მაგრამ არა სამუდამოდ. მაგრამ რაც მართალი აღმოჩნდა, საკმარისია გასვლა და საჭეზე დაკაკუნება - ანუ გამოცვლა ნებისმიერი ვირტუალური მანქანის პარამეტრი

საბოლოოდ, ჩემმა ამერიკელმა კოლეგებმა მოულოდნელად იპოვეს ძირითადი მიზეზი.

მასპინძლები განსხვავდებოდნენ სიხშირით!

• როგორც წესი, ეს არ არის დიდი საქმე. მაგრამ: "მშობლიური" ჰოსტიდან "სხვადასხვა" სიხშირის ჰოსტზე გადასვლისას, VMware-მა უნდა დაარეგულიროს GetTimePrecise შედეგი.
• როგორც წესი, ეს არ არის პრობლემა, თუ არ არის პროგრამა, რომელიც ითხოვს ზუსტ დროს მილიონჯერ წამში, როგორიცაა SQL სერვერი.
• მაგრამ ეს არ არის საშინელი, რადგან SQL სერვერი ყოველთვის არ აკეთებს ამას (იხ. დასკვნა)

მაგრამ არის შემთხვევები, როცა ეს რაკი ძლიერად ურტყამს. და მაინც, დიახ, საჭეზე დაჭერით (ვირტუალური ტექნიკის პარამეტრებში რაღაცის შეცვლით) ვაიძულე 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