ہاں، میرا پرانا لیپ ٹاپ آپ کے پروڈکشن سرور سے کئی گنا زیادہ طاقتور ہے۔

یہ وہ دعوے ہیں جو میں نے اپنے ڈویلپرز سے سنے ہیں۔ سب سے دلچسپ بات یہ ہے کہ یہ سچ نکلا، جس نے ایک طویل تحقیقات کو جنم دیا۔ ہم SQL سرورز کے بارے میں بات کریں گے جو 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 سیکنڈ لگتے ہیں۔ کیونکہ ایس کیو ایل کو ٹرانزیکشن لاگ پر لکھنے کے فزیکل اینڈ کا انتظار کرنا پڑتا ہے، اور ہم یہاں بہت مختصر ٹرانزیکشنز کر رہے ہیں۔ موٹے الفاظ میں، ہم نے شہر کی ٹریفک میں ایک بڑا طاقتور ٹرک چلا دیا، اور ہم دیکھ رہے ہیں کہ پیزا ڈیلیوری کرنے والے لوگ کس طرح اسکوٹر پر مشہور ہو رہے ہیں - یہاں تھرو پٹ اہم نہیں ہے، صرف تاخیر اہم ہے۔ اور ایک بھی نیٹ ورک اسٹوریج نہیں، چاہے اس کی قیمت میں کتنے ہی زیرو ہوں، تاخیر کے لحاظ سے مقامی SSD کو پیچھے چھوڑنے کے قابل ہو گا۔

(تبصروں میں پتہ چلا کہ میں نے جھوٹ بولا تھا - میں نے دونوں جگہوں پر استحکام میں تاخیر کی تھی۔ بغیر کسی تاخیر کے یہ پتہ چلا:
ڈیسک ٹاپ - 39 سیکنڈ، 15K tr/sec، 0.065ms/io راؤنڈ ٹرپ
PROD - 360 سیکنڈ، 1600 tr/sec، 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 کی تعداد کا حساب لگانے کے لیے ایک ٹیسٹ لیا - ٹیسٹ نے کسی بھی سرور پر وہی نتائج دکھائے۔ کالے جادو کی بو مضبوط سے مضبوط ہوتی گئی۔

ڈی ای وی فارم پر نکلنے کے بعد، میں نے سرورز کے ساتھ کھیلنا شروع کیا۔ یہ پتہ چلا کہ میزبان سے میزبان تک 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 گنا (!!!) ہے۔ یہ پہلے سے ہی ایک چھوٹی سی فتح تھی: کسی بھی صورت میں، مائیکروسافٹ اور وی ایم ویئر سپورٹ کے درمیان پھنس جانے کا کوئی خطرہ نہیں تھا تاکہ وہ تیروں کو ایک دوسرے کی طرف بدل دیں۔

پھر ترقی رک گئی - چھٹی، اہم چیزیں، وائرل ہسٹیریا اور کام کے بوجھ میں تیزی سے اضافہ۔ میں نے اکثر ساتھیوں کے سامنے جادوئی مسئلہ کا ذکر کیا، لیکن بعض اوقات ایسا لگتا تھا کہ وہ ہمیشہ مجھ پر یقین نہیں کرتے تھے - یہ بیان کہ VMware نے کوڈ کو 10-20 گنا سست کر دیا ہے، یہ بہت خوفناک تھا۔

میں نے اپنے آپ کو کھودنے کی کوشش کی جو اسے سست کرتی ہے۔ بعض اوقات مجھے ایسا لگتا تھا کہ میں نے ایک حل تلاش کر لیا ہے - ہاٹ پلگ کو آن اور آف کرنا، میموری کی مقدار یا پروسیسرز کی تعداد میں تبدیلی اکثر مشین کو "تیز رفتار" میں بدل دیتی ہے۔ لیکن ہمیشہ کے لیے نہیں۔ لیکن جو سچ نکلا وہ یہ ہے کہ باہر جا کر پہیے پر دستک دینا ہی کافی ہے یعنی بدلنے کے لیے کوئی بھی ورچوئل مشین پیرامیٹر

آخر کار، میرے امریکی ساتھیوں کو اچانک ایک بنیادی وجہ مل گئی۔

میزبان تعدد میں مختلف ہیں!

• ایک اصول کے طور پر، یہ خوفناک نہیں ہے. لیکن: جب 'مقامی' میزبان سے 'مختلف' فریکوئنسی والے میزبان کی طرف جاتے ہیں تو، VMware کو GetTimePrecise نتیجہ کو ایڈجسٹ کرنا چاہیے۔
• ایک اصول کے طور پر، یہ کوئی مسئلہ نہیں ہے، جب تک کہ کوئی ایسی ایپلی کیشن نہ ہو جو ایس کیو ایل سرور کی طرح فی سیکنڈ لاکھوں بار درست وقت کی درخواست کرے۔
• لیکن یہ بھی خوفناک نہیں ہے، کیوں کہ SQL سرور ہمیشہ ایسا نہیں کرتا (نتیجہ دیکھیں)

لیکن ایسے معاملات ہوتے ہیں جب اس ریک کو تکلیف ہوتی ہے۔ اور ہاں، وہیل پر دستک دے کر (VM سیٹنگز میں کچھ تبدیل کر کے)، میں نے VMware کو کنفیگریشن کا 'دوبارہ حساب' کرنے پر مجبور کیا، اور موجودہ میزبان کی فریکوئنسی مشین کی 'مقامی' فریکوئنسی بن گئی۔

حل

www.vmware.com/files/pdf/techpaper/Timekeeping-In-VirtualMachines.pdf

جب آپ TSC کی ورچوئلائزیشن کو غیر فعال کرتے ہیں، تو ورچوئل مشین کے اندر سے TSC پڑھنے سے فزیکل مشین کی TSC ویلیو واپس آجاتی ہے، اور ورچوئل مشین کے اندر سے TSC لکھنے کا کوئی اثر نہیں ہوتا ہے۔ ورچوئل مشین کو دوسرے میزبان میں منتقل کرنا، اسے معطل حالت سے دوبارہ شروع کرنا، یا اسنیپ شاٹ پر واپس جانا TSC کو متواتر چھلانگ لگانے کا سبب بنتا ہے۔ کچھ مہمان آپریٹنگ سسٹم بوٹ کرنے میں ناکام ہو جاتے ہیں، یا ٹائم کیپنگ کے دیگر مسائل کو ظاہر کرتے ہیں، جب TSC ورچوئلائزیشن کو غیر فعال کر دیا جاتا ہے۔ ماضی میں، اس خصوصیت کو بعض اوقات ٹی ایس سی کو کثرت سے پڑھنے والی ایپلیکیشنز کی کارکردگی کو بہتر بنانے کے لیے تجویز کیا گیا ہے۔، لیکن موجودہ مصنوعات میں ورچوئل TSC کی کارکردگی کو کافی حد تک بہتر کیا گیا ہے۔ اس خصوصیت کو استعمال کرنے کے لیے بھی تجویز کیا گیا ہے جب وہ پیمائشیں انجام دے رہے ہوں جس کے لیے ورچوئل مشین میں حقیقی وقت کا درست ذریعہ درکار ہو۔

مختصر میں، آپ کو پیرامیٹر شامل کرنے کی ضرورت ہے۔

monitor_control.virtual_rdtsc = غلط

حاصل يہ ہوا

آپ کے پاس شاید ایک سوال ہے: SQL اتنی کثرت سے GetTimePrecise کو کیوں کال کرے گا؟

میرے پاس ایس کیو ایل سرور کے ذرائع نہیں ہیں، لیکن منطق یہ کہتی ہے۔ SQL تقریباً ایک آپریٹنگ سسٹم ہے جس میں کوآپریٹو ہم آہنگی ہے، جہاں ہر تھریڈ کو وقتاً فوقتاً "راستہ دینا" چاہیے۔ ایسا کرنے کے لیے بہترین جگہ کہاں ہے؟ جہاں قدرتی توقع ہے - لاک یا آئی او۔ ٹھیک ہے، لیکن کیا ہوگا اگر ہم کمپیوٹیشنل سائیکل گھوم رہے ہیں؟ پھر واضح اور تقریباً واحد جگہ مترجم میں ہے (یہ بالکل مترجم نہیں ہے)، اگلے آپریٹر کے عمل کے بعد۔

ایک اصول کے طور پر، SQL سرور خالص کمپیوٹنگ کے لیے استعمال نہیں کیا جاتا ہے اور یہ کوئی مسئلہ نہیں ہے۔ لیکن ہر طرح کے عارضی ٹیبلز (جو فوری طور پر کیش کر دیے جاتے ہیں) کے ساتھ کام کرنے والے چکر کوڈ کو بہت جلد عمل میں آنے والے بیانات کی ترتیب میں بدل دیتے ہیں۔

ویسے، اگر فنکشن کو NATIVELY COMPILED میں لپیٹ دیا جائے، تو یہ وقت کی درخواست کرنا بند کر دیتا ہے، اور اس کی رفتار 10 گنا بڑھ جاتی ہے۔ لیکن کوآپریٹو ملٹی ٹاسکنگ کا کیا ہوگا؟ لیکن مقامی طور پر مرتب کردہ کوڈ کے لیے، مجھے ایس کیو ایل میں پریمپٹیو ملٹی ٹاسکنگ کرنا پڑی۔

ماخذ: www.habr.com