হ্যাঁ, আমার পুরানো ল্যাপটপ আপনার প্রোডাকশন সার্ভারের চেয়ে কয়েকগুণ বেশি শক্তিশালী

এগুলি ঠিক সেই অভিযোগগুলি যা আমি আমাদের ডেভেলপারদের কাছ থেকে শুনেছি৷ সবচেয়ে মজার বিষয় হল এটি সত্য বলে প্রমাণিত হয়েছে, যা দীর্ঘ তদন্তের জন্ম দিয়েছে। আমরা এসকিউএল সার্ভার সম্পর্কে কথা বলব যা VMware এ চলে।

প্রকৃতপক্ষে, প্রোডাকশন সার্ভারটি ল্যাপটপের পিছনে আশাহীনভাবে রয়েছে তা নিশ্চিত করা সহজ। কোডটি কার্যকর করুন (টেম্পডিবিতে নয় এবং বিলম্বিত স্থায়িত্ব সক্ষম সহ একটি ডাটাবেসে নয়)

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 সেকেন্ড সময় নেয়। কারণ এসকিউএলকে অবশ্যই লেনদেন লগ এন্ট্রির প্রকৃত শেষের জন্য অপেক্ষা করতে হবে, এবং আমরা এখানে খুব ছোট লেনদেন করছি। মোটামুটিভাবে বলতে গেলে, আমরা শহরের ট্র্যাফিকের মধ্যে একটি বড়, শক্তিশালী ট্রাক চালিয়েছি, এবং স্কুটারে পিৎজা ডেলিভারি লোকেদের দ্বারা দুরন্তভাবে অতিক্রম করা দেখেছি - থ্রুপুট এখানে গুরুত্বপূর্ণ নয়, শুধুমাত্র লেটেন্সি গুরুত্বপূর্ণ। এবং কোনও নেটওয়ার্ক স্টোরেজ, এর দামে যত শূন্যই থাকুক না কেন, লেটেন্সির ক্ষেত্রে স্থানীয় এসএসডিকে হারাতে পারে।

(মন্তব্যে দেখা গেল যে আমি মিথ্যা বলেছি - আমি উভয় জায়গায় স্থায়িত্ব বিলম্বিত করেছি। বিলম্বিত স্থায়িত্ব ছাড়াই দেখা যাচ্ছে:
ডেস্কটপ - 39 সেকেন্ড, 15K tr/সেকেন্ড, 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 সেকেন্ড সময় লাগবে - কোডটি খুব দ্রুত বা খুব ধীরে কাজ করত, অর্থাৎ, সমস্যাটি ছিল, ধরা যাক, কালো এবং সাদা।

আমি যা করেছি? ব্যবহৃত VMware মেট্রিক্স। সেখানে সবকিছু ঠিকঠাক ছিল - প্রচুর পরিমাণে সংস্থান ছিল, প্রস্তুত সময় = 0, দ্রুত এবং ধীর উভয় সার্ভারে পরীক্ষা চলাকালীন একটি ভিসিপিইউতে সিপিইউ = 100, সবকিছুই যথেষ্ট ছিল। আমি Pi সংখ্যা গণনা করার জন্য একটি পরীক্ষা নিয়েছিলাম - পরীক্ষাটি যেকোনো সার্ভারে একই ফলাফল দেখায়। কালো জাদুর গন্ধ ক্রমশ শক্তিশালী হয়ে উঠল।

একবার আমি ডিইভি ফার্মে উঠলে, আমি সার্ভারের সাথে খেলা শুরু করি। দেখা গেল যে হোস্ট থেকে হোস্টে vMotion একটি সার্ভারকে "নিরাময়" করতে পারে, তবে এটি একটি "দ্রুত" সার্ভারকে "ধীর" তে পরিণত করতে পারে। মনে হচ্ছে এটিই - কিছু হোস্টের সমস্যা আছে... কিন্তু... না। কিছু ভার্চুয়াল মেশিন হোস্টে ধীর ছিল, বলুন A, কিন্তু হোস্ট B-তে দ্রুত কাজ করেছে। এবং অন্য একটি ভার্চুয়াল মেশিন, বিপরীতে, A-তে দ্রুত কাজ করেছে এবং B-তে গতি কমিয়ে দিয়েছে! "দ্রুত" এবং "ধীর" উভয় মেশিনই প্রায়ই হোস্টে ঘুরছিল!

সেই মুহূর্ত থেকে, বাতাসে সালফারের একটি স্বতন্ত্র গন্ধ ছিল। সর্বোপরি, সমস্যাটি ভার্চুয়াল মেশিনের জন্য দায়ী করা যায়নি (উদাহরণস্বরূপ উইন্ডোজ প্যাচগুলি) - সর্বোপরি, এটি vMotion এর সাথে "দ্রুত" তে পরিণত হয়েছে। তবে সমস্যাটি হোস্টকেও দায়ী করা যায় না - সর্বোপরি, এতে "দ্রুত" এবং "ধীর" উভয় মেশিন থাকতে পারে। এছাড়াও, এটি লোডের সাথে সম্পর্কিত ছিল না - আমি হোস্টে একটি "ধীর" মেশিন পেতে সক্ষম হয়েছি, যেখানে এটি ছাড়া কিছুই ছিল না।

হতাশা থেকে, আমি সিসিন্টারনাল থেকে প্রসেস এক্সপ্লোরার চালু করেছি এবং এসকিউএল স্ট্যাকের দিকে তাকালাম। ধীরগতির মেশিনে লাইনটি অবিলম্বে আমার নজর কেড়েছে:

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 কোডটিকে 10-20 বার ধীর করে দেয় এমন বিবৃতিটি খুব ভয়ঙ্কর ছিল।

আমি নিজেকে খনন করার চেষ্টা করেছি কি আমাকে ধীর করছিল। মাঝে মাঝে আমার কাছে মনে হয়েছিল যে আমি একটি সমাধান খুঁজে পেয়েছি - হট প্লাগ চালু এবং বন্ধ করা, মেমরির পরিমাণ বা প্রসেসরের সংখ্যা পরিবর্তন করা প্রায়শই মেশিনটিকে "দ্রুত" তে পরিণত করে। কিন্তু চিরকাল নয়। তবে যা সত্য হয়ে উঠল তা হ'ল বাইরে গিয়ে চাকা ঠকানোই যথেষ্ট - অর্থাৎ পরিবর্তন কোন ভার্চুয়াল মেশিন প্যারামিটার

অবশেষে, আমার আমেরিকান সহকর্মীরা হঠাৎ মূল কারণ খুঁজে পেয়েছিলেন।

আয়োজক ফ্রিকোয়েন্সি ভিন্ন!

• একটি নিয়ম হিসাবে, এটি একটি বড় চুক্তি নয়। কিন্তু: একটি 'নেটিভ' হোস্ট থেকে 'ভিন্ন' ফ্রিকোয়েন্সি সহ হোস্টে যাওয়ার সময়, ভিএমওয়্যারকে অবশ্যই 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 = মিথ্যা

উপসংহার

আপনার সম্ভবত একটি প্রশ্ন আছে: কেন এসকিউএল এত ঘন ঘন GetTimePrecise কল করে?

আমার কাছে এসকিউএল সার্ভার সোর্স কোড নেই, কিন্তু যুক্তি এটি বলে। এসকিউএল হল প্রায় সমবায় সমবায় সহ একটি অপারেটিং সিস্টেম, যেখানে প্রতিটি থ্রেডকে সময়ে সময়ে "প্রদান" করতে হবে। এটি করার সেরা জায়গা কোথায়? যেখানে একটি প্রাকৃতিক অপেক্ষা আছে - লক বা আইও। ঠিক আছে, কিন্তু যদি আমরা কম্পিউটেশনাল লুপ স্পিন করছি? তারপর সুস্পষ্ট এবং প্রায় একমাত্র স্থানটি দোভাষীতে (এটি আসলে একটি দোভাষী নয়), পরবর্তী বিবৃতিটি কার্যকর করার পরে।

সাধারণত, SQL সার্ভার বিশুদ্ধ কম্পিউটিং পেরেক করার জন্য ব্যবহার করা হয় না এবং এটি একটি সমস্যা নয়। কিন্তু লুপগুলি যেগুলি সমস্ত ধরণের অস্থায়ী টেবিলের সাথে কাজ করে (যা অবিলম্বে ক্যাশে করা হয়) কোডটিকে খুব দ্রুত নির্বাহিত বিবৃতিগুলির একটি ক্রমে পরিণত করে৷

যাইহোক, আপনি যদি NATIVELY COMPILED-এ ফাংশনটি র‍্যাপ করেন, তাহলে এটি সময় চাওয়া বন্ধ করে দেয় এবং এর গতি 10 গুণ বেড়ে যায়। সমবায় মাল্টিটাস্কিং সম্পর্কে কী হবে? কিন্তু নেটিভলি কম্পাইল করা কোডের জন্য আমাদের এসকিউএল-এ প্রিম্পটিভ মাল্টিটাস্কিং করতে হয়েছিল।

উত্স: www.habr.com