ਹਾਂ, ਮੇਰਾ ਪੁਰਾਣਾ ਲੈਪਟਾਪ ਤੁਹਾਡੇ ਉਤਪਾਦਨ ਸਰਵਰ ਨਾਲੋਂ ਕਈ ਗੁਣਾ ਜ਼ਿਆਦਾ ਸ਼ਕਤੀਸ਼ਾਲੀ ਹੈ

ਇਹ ਬਿਲਕੁਲ ਉਹ ਸ਼ਿਕਾਇਤਾਂ ਹਨ ਜੋ ਮੈਂ ਸਾਡੇ ਡਿਵੈਲਪਰਾਂ ਤੋਂ ਸੁਣੀਆਂ ਹਨ। ਸਭ ਤੋਂ ਦਿਲਚਸਪ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇਹ ਸੱਚ ਨਿਕਲਿਆ, ਇੱਕ ਲੰਬੀ ਜਾਂਚ ਨੂੰ ਜਨਮ ਦਿੰਦਾ ਹੈ. ਅਸੀਂ 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 ਸਕਿੰਟ ਲੈਂਦਾ ਹੈ। ਕਿਉਂਕਿ SQL ਨੂੰ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਐਂਟਰੀ ਦੇ ਭੌਤਿਕ ਅੰਤ ਦੀ ਉਡੀਕ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਅਸੀਂ ਇੱਥੇ ਬਹੁਤ ਘੱਟ ਲੈਣ-ਦੇਣ ਕਰ ਰਹੇ ਹਾਂ। ਮੋਟੇ ਤੌਰ 'ਤੇ, ਅਸੀਂ ਸ਼ਹਿਰ ਦੇ ਟ੍ਰੈਫਿਕ ਵਿੱਚ ਇੱਕ ਵੱਡੇ, ਸ਼ਕਤੀਸ਼ਾਲੀ ਟਰੱਕ ਨੂੰ ਚਲਾਇਆ, ਅਤੇ ਦੇਖਿਆ ਕਿ ਇਹ ਸਕੂਟਰਾਂ 'ਤੇ ਪੀਜ਼ਾ ਡਿਲੀਵਰੀ ਵਾਲੇ ਲੋਕਾਂ ਦੁਆਰਾ ਬੜੀ ਬੇਚੈਨੀ ਨਾਲ ਪਛਾੜ ਗਿਆ ਸੀ - ਥ੍ਰੁਪੁੱਟ ਇੱਥੇ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਹੈ, ਸਿਰਫ ਲੇਟੈਂਸੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਅਤੇ ਕੋਈ ਵੀ ਨੈੱਟਵਰਕ ਸਟੋਰੇਜ, ਭਾਵੇਂ ਇਸਦੀ ਕੀਮਤ ਵਿੱਚ ਕਿੰਨੇ ਵੀ ਜ਼ੀਰੋ ਹੋਣ, ਲੇਟੈਂਸੀ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਸਥਾਨਕ SSD ਨੂੰ ਹਰਾ ਸਕਦਾ ਹੈ।

(ਟਿੱਪਣੀਆਂ ਵਿੱਚ ਇਹ ਸਾਹਮਣੇ ਆਇਆ ਕਿ ਮੈਂ ਝੂਠ ਬੋਲਿਆ - ਮੈਂ ਦੋਵਾਂ ਥਾਵਾਂ 'ਤੇ ਟਿਕਾਊਤਾ ਵਿੱਚ ਦੇਰੀ ਕੀਤੀ ਸੀ। ਬਿਨਾਂ ਦੇਰੀ ਦੇ ਟਿਕਾਊਤਾ ਦੇ ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ:
ਡੈਸਕਟਾਪ - 39 ਸਕਿੰਟ, 15K tr/sec, 0.065ms/io roundtrip
PROD - 360 ਸਕਿੰਟ, 1600 ਟਰ/ਸਕਿੰਟ, 0.6 ਮਿ
ਮੈਨੂੰ ਧਿਆਨ ਦੇਣਾ ਚਾਹੀਦਾ ਸੀ ਕਿ ਇਹ ਬਹੁਤ ਤੇਜ਼ ਸੀ)

ਹਾਲਾਂਕਿ, ਇਸ ਮਾਮਲੇ ਵਿੱਚ ਅਸੀਂ ਇੱਕ ਮਾਮੂਲੀ ਉਦਾਹਰਣ ਦੇ ਨਾਲ ਰੀਮੈਨ ਜ਼ੀਟਾ ਫੰਕਸ਼ਨ ਦੇ ਮਾਮੂਲੀ ਜ਼ੀਰੋ ਨਾਲ ਨਜਿੱਠ ਰਹੇ ਹਾਂ। ਡਿਵੈਲਪਰਾਂ ਨੇ ਮੈਨੂੰ ਲਿਆਂਦੀ ਉਦਾਹਰਣ ਵਿੱਚ, ਇਹ ਵੱਖਰੀ ਸੀ. ਮੈਨੂੰ ਯਕੀਨ ਹੋ ਗਿਆ ਕਿ ਉਹ ਸਹੀ ਸਨ, ਅਤੇ ਕਾਰੋਬਾਰੀ ਤਰਕ ਨਾਲ ਸਬੰਧਤ ਉਹਨਾਂ ਦੀਆਂ ਸਾਰੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਉਦਾਹਰਣ ਤੋਂ ਹਟਾਉਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ। ਕਿਸੇ ਸਮੇਂ ਮੈਨੂੰ ਅਹਿਸਾਸ ਹੋਇਆ ਕਿ ਮੈਂ ਉਹਨਾਂ ਦੇ ਕੋਡ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸੁੱਟ ਸਕਦਾ ਹਾਂ ਅਤੇ ਆਪਣਾ ਖੁਦ ਲਿਖ ਸਕਦਾ ਹਾਂ - ਜੋ ਇੱਕੋ ਸਮੱਸਿਆ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ - ਉਤਪਾਦਨ ਵਿੱਚ ਇਹ 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, ਸਭ ਕੁਝ ਕਾਫ਼ੀ ਸੀ, ਇੱਕ vCPU 'ਤੇ ਤੇਜ਼ ਅਤੇ ਹੌਲੀ ਸਰਵਰ CPU = 100 ਦੋਵਾਂ 'ਤੇ ਟੈਸਟ ਦੌਰਾਨ. ਮੈਂ Pi ਨੰਬਰ ਦੀ ਗਣਨਾ ਕਰਨ ਲਈ ਇੱਕ ਟੈਸਟ ਲਿਆ - ਟੈਸਟ ਨੇ ਕਿਸੇ ਵੀ ਸਰਵਰ 'ਤੇ ਉਹੀ ਨਤੀਜੇ ਦਿਖਾਏ। ਕਾਲੇ ਜਾਦੂ ਦੀ ਗੰਧ ਤੇਜ਼ ਅਤੇ ਮਜ਼ਬੂਤ ​​ਹੁੰਦੀ ਗਈ।

ਇੱਕ ਵਾਰ ਜਦੋਂ ਮੈਂ ਡੀਈਵੀ ਫਾਰਮ ਵਿੱਚ ਪਹੁੰਚ ਗਿਆ, ਮੈਂ ਸਰਵਰਾਂ ਨਾਲ ਖੇਡਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ। ਇਹ ਸਾਹਮਣੇ ਆਇਆ ਕਿ ਹੋਸਟ ਤੋਂ ਹੋਸਟ ਤੱਕ vMotion ਇੱਕ ਸਰਵਰ ਨੂੰ "ਇਲਾਜ" ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਇੱਕ "ਤੇਜ਼" ਸਰਵਰ ਨੂੰ "ਹੌਲੀ" ਵਿੱਚ ਵੀ ਬਦਲ ਸਕਦਾ ਹੈ। ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਇਹ ਇਹ ਹੈ - ਕੁਝ ਮੇਜ਼ਬਾਨਾਂ ਨੂੰ ਸਮੱਸਿਆ ਹੈ... ਪਰ... ਨਹੀਂ। ਕੁਝ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਹੋਸਟ 'ਤੇ ਹੌਲੀ ਸੀ, ਜਿਵੇਂ ਕਿ A, ਪਰ ਹੋਸਟ B 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰਦੀ ਸੀ। ਅਤੇ ਇੱਕ ਹੋਰ ਵਰਚੁਅਲ ਮਸ਼ੀਨ, ਇਸ ਦੇ ਉਲਟ, A' ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰਦੀ ਸੀ ਅਤੇ B 'ਤੇ ਹੌਲੀ ਹੋ ਜਾਂਦੀ ਸੀ! ਦੋਵੇਂ "ਤੇਜ਼" ਅਤੇ "ਹੌਲੀ" ਮਸ਼ੀਨਾਂ ਅਕਸਰ ਮੇਜ਼ਬਾਨ 'ਤੇ ਘੁੰਮਦੀਆਂ ਸਨ!

ਉਸ ਪਲ ਤੋਂ, ਹਵਾ ਵਿੱਚ ਗੰਧਕ ਦੀ ਇੱਕ ਵੱਖਰੀ ਗੰਧ ਸੀ. ਆਖ਼ਰਕਾਰ, ਸਮੱਸਿਆ ਨੂੰ ਵਰਚੁਅਲ ਮਸ਼ੀਨ (ਉਦਾਹਰਣ ਲਈ ਵਿੰਡੋਜ਼ ਪੈਚ) ਨਾਲ ਜੋੜਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ - ਆਖਰਕਾਰ, ਇਹ vMotion ਨਾਲ "ਤੇਜ਼" ਵਿੱਚ ਬਦਲ ਗਿਆ. ਪਰ ਸਮੱਸਿਆ ਦਾ ਕਾਰਨ ਮੇਜ਼ਬਾਨ ਨੂੰ ਵੀ ਨਹੀਂ ਦਿੱਤਾ ਜਾ ਸਕਦਾ - ਆਖਰਕਾਰ, ਇਸ ਵਿੱਚ "ਤੇਜ਼" ਅਤੇ "ਹੌਲੀ" ਦੋਵੇਂ ਮਸ਼ੀਨਾਂ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਨਾਲ ਹੀ, ਇਹ ਲੋਡ ਨਾਲ ਸਬੰਧਤ ਨਹੀਂ ਸੀ - ਮੈਂ ਮੇਜ਼ਬਾਨ 'ਤੇ ਇੱਕ "ਹੌਲੀ" ਮਸ਼ੀਨ ਪ੍ਰਾਪਤ ਕਰਨ ਵਿੱਚ ਕਾਮਯਾਬ ਰਿਹਾ, ਜਿੱਥੇ ਇਸ ਤੋਂ ਇਲਾਵਾ ਕੁਝ ਵੀ ਨਹੀਂ ਸੀ.

ਨਿਰਾਸ਼ਾ ਦੇ ਕਾਰਨ, ਮੈਂ ਸਿਸਿਨਟਰਨਲਜ਼ ਤੋਂ ਪ੍ਰੋਸੈਸ ਐਕਸਪਲੋਰਰ ਲਾਂਚ ਕੀਤਾ ਅਤੇ 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 ਸਮਰਥਨ ਵਿਚਕਾਰ ਫਸਣ ਦਾ ਕੋਈ ਖ਼ਤਰਾ ਨਹੀਂ ਸੀ ਤਾਂ ਜੋ ਉਹ ਇੱਕ ਦੂਜੇ 'ਤੇ ਤੀਰ ਚਲਾ ਸਕਣ।

ਫਿਰ ਤਰੱਕੀ ਰੁਕ ਗਈ - ਛੁੱਟੀਆਂ, ਮਹੱਤਵਪੂਰਣ ਮਾਮਲੇ, ਵਾਇਰਲ ਹਿਸਟੀਰੀਆ ਅਤੇ ਕੰਮ ਦੇ ਬੋਝ ਵਿੱਚ ਤਿੱਖੀ ਵਾਧਾ. ਮੈਂ ਅਕਸਰ ਆਪਣੇ ਸਾਥੀਆਂ ਨੂੰ ਜਾਦੂ ਦੀ ਸਮੱਸਿਆ ਦਾ ਜ਼ਿਕਰ ਕੀਤਾ, ਪਰ ਕਈ ਵਾਰ ਅਜਿਹਾ ਲਗਦਾ ਸੀ ਕਿ ਉਹ ਹਮੇਸ਼ਾ ਮੇਰੇ 'ਤੇ ਵਿਸ਼ਵਾਸ ਨਹੀਂ ਕਰਦੇ ਸਨ - ਇਹ ਬਿਆਨ ਕਿ VMware ਕੋਡ ਨੂੰ 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 ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਕਾਫੀ ਸੁਧਾਰ ਕੀਤਾ ਗਿਆ ਹੈ। ਵਿਸ਼ੇਸ਼ਤਾ ਦੀ ਵਰਤੋਂ ਲਈ ਵੀ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਗਈ ਹੈ ਜਦੋਂ ਉਹ ਮਾਪ ਕਰਦੇ ਹਨ ਜਿਸ ਲਈ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਵਿੱਚ ਅਸਲ ਸਮੇਂ ਦੇ ਇੱਕ ਸਟੀਕ ਸਰੋਤ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਸੰਖੇਪ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਪੈਰਾਮੀਟਰ ਜੋੜਨ ਦੀ ਲੋੜ ਹੈ

monitor_control.virtual_rdtsc = ਗਲਤ

ਸਿੱਟਾ

ਤੁਹਾਡੇ ਕੋਲ ਸ਼ਾਇਦ ਇੱਕ ਸਵਾਲ ਹੈ: SQL ਇੰਨੀ ਵਾਰ GetTimePrecise ਨੂੰ ਕਿਉਂ ਕਾਲ ਕਰਦਾ ਹੈ?

ਮੇਰੇ ਕੋਲ SQL ਸਰਵਰ ਸਰੋਤ ਕੋਡ ਨਹੀਂ ਹੈ, ਪਰ ਤਰਕ ਇਹ ਕਹਿੰਦਾ ਹੈ। SQL ਲਗਭਗ ਇੱਕ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਹੈ ਜਿਸ ਵਿੱਚ ਸਹਿਕਾਰੀ ਸਹਿਮਤੀ ਹੈ, ਜਿੱਥੇ ਹਰੇਕ ਥ੍ਰੈਡ ਨੂੰ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ "ਦੇਣਾ" ਚਾਹੀਦਾ ਹੈ। ਅਜਿਹਾ ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਜਗ੍ਹਾ ਕਿੱਥੇ ਹੈ? ਜਿੱਥੇ ਇੱਕ ਕੁਦਰਤੀ ਉਡੀਕ ਹੈ - ਲਾਕ ਜਾਂ ਆਈ.ਓ. ਠੀਕ ਹੈ, ਪਰ ਕੀ ਜੇ ਅਸੀਂ ਕੰਪਿਊਟੇਸ਼ਨਲ ਲੂਪਸ ਨੂੰ ਸਪਿਨ ਕਰ ਰਹੇ ਹਾਂ? ਫਿਰ ਸਪੱਸ਼ਟ ਅਤੇ ਲਗਭਗ ਸਿਰਫ ਸਥਾਨ ਦੁਭਾਸ਼ੀਏ ਵਿੱਚ ਹੈ (ਇਹ ਅਸਲ ਵਿੱਚ ਇੱਕ ਦੁਭਾਸ਼ੀਏ ਨਹੀਂ ਹੈ), ਅਗਲੇ ਬਿਆਨ ਨੂੰ ਚਲਾਉਣ ਤੋਂ ਬਾਅਦ.

ਆਮ ਤੌਰ 'ਤੇ, SQL ਸਰਵਰ ਸ਼ੁੱਧ ਕੰਪਿਊਟਿੰਗ ਨੇਲਿੰਗ ਲਈ ਨਹੀਂ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇਹ ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ। ਪਰ ਲੂਪਸ ਜੋ ਹਰ ਤਰ੍ਹਾਂ ਦੀਆਂ ਅਸਥਾਈ ਟੇਬਲਾਂ (ਜੋ ਤੁਰੰਤ ਕੈਸ਼ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ) ਨਾਲ ਕੰਮ ਕਰਦੀਆਂ ਹਨ, ਕੋਡ ਨੂੰ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਐਗਜ਼ੀਕਿਊਟ ਕੀਤੇ ਸਟੇਟਮੈਂਟਾਂ ਦੇ ਕ੍ਰਮ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ।

ਵੈਸੇ, ਜੇਕਰ ਤੁਸੀਂ NATIVELY COMPILED ਵਿੱਚ ਫੰਕਸ਼ਨ ਨੂੰ ਸਮੇਟਦੇ ਹੋ, ਤਾਂ ਇਹ ਸਮਾਂ ਮੰਗਣਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਇਸਦੀ ਗਤੀ 10 ਗੁਣਾ ਵੱਧ ਜਾਂਦੀ ਹੈ। ਕੋਆਪਰੇਟਿਵ ਮਲਟੀਟਾਸਕਿੰਗ ਬਾਰੇ ਕੀ? ਪਰ ਮੂਲ ਰੂਪ ਵਿੱਚ ਕੰਪਾਇਲ ਕੀਤੇ ਕੋਡ ਲਈ ਸਾਨੂੰ SQL ਵਿੱਚ ਪ੍ਰੀਮਪਟੀਵ ਮਲਟੀਟਾਸਕਿੰਗ ਕਰਨੀ ਪੈਂਦੀ ਸੀ।

ਸਰੋਤ: www.habr.com