예, 제 오래된 노트북은 프로덕션 서버보다 몇 배 더 강력합니다.

이것이 바로 제가 개발자들로부터 들었던 불만 사항입니다. 가장 흥미로운 점은 이것이 사실로 밝혀져 오랜 조사가 이어졌다는 것입니다. VMware에서 실행되는 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은 트랜잭션 로그 항목의 물리적 끝을 기다려야 하기 때문에 여기서는 매우 짧은 트랜잭션을 수행하고 있습니다. 대략적으로 말하면, 우리는 크고 강력한 트럭을 도시 교통으로 몰고 스쿠터를 탄 피자 배달원이 급히 추월하는 것을 지켜보았습니다. 여기서 처리량은 중요하지 않고 대기 시간만 중요합니다. 그리고 가격에 XNUMX이 아무리 많이 있어도 지연 시간 측면에서 로컬 SSD를 능가할 수 있는 네트워크 스토리지는 없습니다.

(댓글에서 내가 거짓말을 한 것으로 밝혀졌습니다. 두 곳 모두에서 내구성이 지연되었습니다. 내구성이 지연되지 않으면 다음과 같이 밝혀졌습니다.
데스크탑 - 39초, 15K tr/초, 0.065ms/io 왕복
PROD - 360초, 1600tr/초, 0.6ms
너무 빠르다는 걸 눈치챘어야 했는데)

그러나 이 경우에는 사소한 예를 들어 리만 제타 함수의 사소한 3을 다루고 있습니다. 개발자가 가져온 예에서는 달랐습니다. 나는 그들이 옳다고 확신했고 비즈니스 로직과 관련된 모든 세부 사항을 예제에서 제거하기 시작했습니다. 어느 시점에서 나는 그들의 코드를 완전히 버리고 내 자신의 코드를 작성할 수 있다는 것을 깨달았습니다. 이는 동일한 문제를 보여 주며 프로덕션에서는 4-XNUMX배 느리게 실행됩니다.

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 수를 계산하기 위해 테스트를 했습니다. 테스트 결과는 모든 서버에서 동일한 결과를 보여주었습니다. 흑마법의 냄새가 점점 강해졌습니다.

DEV 팜에 도착하자마자 서버를 가지고 놀기 시작했습니다. 호스트 간 vMotion은 서버를 "치료"할 수 있을 뿐만 아니라 "빠른" 서버를 "느린" 서버로 전환할 수도 있다는 사실이 밝혀졌습니다. 바로 이 것 같습니다. 일부 호스트에는 문제가 있습니다... 하지만... 아닙니다. 일부 가상 머신은 호스트 A에서는 느리지만 호스트 B에서는 빠르게 작동했습니다. 반대로 또 다른 가상 머신은 A에서는 빠르게 작동하고 B에서는 속도가 느려졌습니다! "빠른" 머신과 "느린" 머신 모두 호스트에서 회전하는 경우가 많았습니다!

그 순간부터 공기 중에는 뚜렷한 유황 냄새가 났습니다. 결국 문제는 가상 머신(예: Windows 패치)으로 인한 것이 아닙니다. 결국 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~XNUMX배(!!!) 입니다. 이것은 이미 작은 승리였습니다. 어쨌든 Microsoft와 VMware 지원 사이에 갇혀 서로에게 화살을 돌릴 위협은 없었습니다.

그런 다음 휴가, 중요한 문제, 바이러스 성 히스테리 및 작업량의 급격한 증가 등 진행이 중단되었습니다. 나는 종종 동료들에게 마법 같은 문제에 대해 언급했지만 때로는 그들이 내 말을 항상 믿지 않는 것 같았습니다. VMware가 코드 속도를 10~20배 늦춘다는 진술은 너무 끔찍했습니다.

나는 나를 느리게 만드는 것이 무엇인지 스스로 알아내려고 노력했습니다. 때로는 해결책을 찾은 것 같았습니다. 핫 플러그를 켜고 끄고, 메모리 양이나 프로세서 수를 변경하면 종종 컴퓨터가 "빠른" 컴퓨터로 바뀌었습니다. 그러나 영원히는 아닙니다. 그러나 사실로 밝혀진 것은 나가서 바퀴를 두드리는 것, 즉 변화하는 것만으로도 충분하다는 것입니다. 모든 가상 머신 매개변수

마침내 미국 동료들이 갑자기 근본 원인을 찾아냈습니다.

호스트의 빈도가 달랐습니다!

• 일반적으로 이것은 큰 문제가 아닙니다. 그러나 '네이티브' 호스트에서 '다른' 빈도를 가진 호스트로 이동할 때 VMware는 GetTimePrecise 결과를 조정해야 합니다.
• 일반적으로 SQL 서버처럼 초당 수백만 번씩 정확한 시간을 요청하는 애플리케이션이 없다면 이는 문제가 되지 않습니다.
• 그러나 SQL Server가 항상 이 작업을 수행하는 것은 아니기 때문에 이는 두렵지 않습니다(결론 참조).

하지만 이 갈퀴가 큰 타격을 입는 경우가 있습니다. 그럼에도 불구하고 휠을 탭하여(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 Server 소스 코드는 없지만 논리에 따르면 다음과 같습니다. SQL은 거의 각 스레드가 때때로 "포기"해야 하는 협력적 동시성을 갖춘 운영 체제입니다. 이 작업을 수행하는 가장 좋은 장소는 어디입니까? 자연스러운 대기가 있는 경우 - 잠금 또는 IO. 좋습니다. 하지만 계산 루프를 회전시키면 어떨까요? 그렇다면 명백하고 거의 유일한 위치는 다음 명령문을 실행한 후 인터프리터(실제로는 인터프리터가 아닙니다)입니다.

일반적으로 SQL Server는 순수 컴퓨팅 네일링에 사용되지 않으며 이는 문제가 되지 않습니다. 그러나 모든 종류의 임시 테이블(즉시 캐시됨)과 함께 작동하는 루프는 코드를 매우 빠르게 실행되는 일련의 명령문으로 바꿉니다.

그런데 함수를 NATIVELY COMPILED로 래핑하면 시간 요청이 중단되고 속도가 10배 증가합니다. 협동적 멀티태스킹은 어떻습니까? 그러나 기본적으로 컴파일된 코드의 경우 SQL에서 PREEMPTIVE MULTITASKING을 수행해야 했습니다.

출처 : habr.com