🥇होय, माझा जुना लॅपटॉप तुमच्या प्रोडक्शन सर्व्हरपेक्षा कित्येक पटीने अधिक शक्तिशाली आहे

मी आमच्या डेव्हलपर्सकडून ऐकलेल्या तक्रारी आहेत. सर्वात मनोरंजक गोष्ट अशी आहे की हे खरे ठरले, ज्यामुळे दीर्घ तपासाला चालना मिळाली. आम्ही व्हीएमवेअरवर चालणार्‍या 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/सेकंद, 0.065ms/io राउंडट्रिप
PROD - 360 सेकंद, 1600 tr/सेकंद, 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 सह "वेगवान" मध्ये बदलले. परंतु समस्येचे श्रेय होस्टला देखील दिले जाऊ शकत नाही - शेवटी, त्यात "वेगवान" आणि "धीमे" दोन्ही मशीन असू शकतात. तसेच, हे लोडशी संबंधित नव्हते - मी होस्टवर "स्लो" मशीन मिळविण्यात व्यवस्थापित केले, जिथे त्याशिवाय काहीही नव्हते.

निराशेतून, मी Sysinternals वरून Process Explorer लाँच केले आणि 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 पट (!!!) आहे. हा आधीच एक छोटासा विजय होता: कोणत्याही परिस्थितीत, मायक्रोसॉफ्ट आणि व्हीएमवेअर समर्थनामध्ये अडकण्याची कोणतीही धमकी नव्हती जेणेकरून ते एकमेकांवर बाण फिरवतील.

मग प्रगती थांबली - सुट्ट्या, महत्त्वाच्या बाबी, विषाणूजन्य उन्माद आणि कामाच्या लोडमध्ये तीव्र वाढ. मी बर्‍याचदा माझ्या सहकार्‍यांना जादूच्या समस्येचा उल्लेख केला, परंतु कधीकधी असे दिसते की त्यांनी माझ्यावर नेहमीच विश्वास ठेवला नाही - व्हीएमवेअर कोड 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 चे कार्यप्रदर्शन लक्षणीयरीत्या सुधारले गेले आहे. व्हर्च्युअल मशीनमध्ये रिअल टाइमचा अचूक स्रोत आवश्यक असलेली मोजमाप करताना वापरण्यासाठी वैशिष्ट्याची शिफारस देखील केली आहे.

थोडक्यात, आपल्याला पॅरामीटर जोडण्याची आवश्यकता आहे

मॉनिटर_कंट्रोल.virtual_rdtsc = असत्य

निष्कर्ष

तुम्हाला कदाचित प्रश्न पडला असेल: एसक्यूएल गेटटाइम प्रिसाईसला वारंवार का कॉल करते?

माझ्याकडे SQL सर्व्हर सोर्स कोड नाही, पण लॉजिक हे सांगते. एसक्यूएल ही जवळजवळ सहकारी संयोग असलेली एक ऑपरेटिंग सिस्टीम आहे, जिथे प्रत्येक थ्रेडने वेळोवेळी "देणे" आवश्यक आहे. हे करण्यासाठी सर्वोत्तम ठिकाण कोठे आहे? जेथे नैसर्गिक प्रतीक्षा आहे - लॉक किंवा आयओ. ठीक आहे, पण जर आपण संगणकीय लूप फिरवत आहोत तर? नंतर स्पष्ट आणि जवळजवळ एकमेव स्थान दुभाष्यामध्ये आहे (हे खरोखर दुभाषी नाही), पुढील विधान कार्यान्वित केल्यानंतर.

साधारणपणे, SQL सर्व्हर शुद्ध संगणनासाठी वापरला जात नाही आणि ही समस्या नाही. परंतु लूप जे सर्व प्रकारच्या तात्पुरत्या सारण्यांसह कार्य करतात (जे लगेच कॅशे केले जातात) कोडला अतिशय त्वरीत कार्यान्वित केलेल्या विधानांच्या अनुक्रमात बदलतात.

तसे, जर तुम्ही NATIVELY COMPILED मध्ये फंक्शन गुंडाळले तर ते वेळ विचारणे थांबवते आणि त्याचा वेग 10 पटीने वाढतो. सहकारी मल्टीटास्किंगचे काय? परंतु मूळ संकलित कोडसाठी आम्हाला SQL मध्ये प्रीईम्प्टीव्ह मल्टीटास्किंग करावे लागले.

स्त्रोत: www.habr.com

होय, माझा जुना लॅपटॉप तुमच्या प्रोडक्शन सर्व्हरपेक्षा कित्येक पटीने अधिक शक्तिशाली आहे

निर्णय

निष्कर्ष

एक टिप्पणी जोडा Отменить ответ