간단한 질문

SQL Server Quantum (4ms)은 서버 OS Quantum (일반적으로 187.5ms)과 어떻게 동기화됩니까?

간단한 질문 설명

184ms의 OS 퀀텀 (46 개의 전체 SQL 퀀텀에 해당)이 사용 된 후 OS 퀀텀은 일정을 다른 프로세스로 넘기기 전에 3.5ms의 시간이 걸립니다. SQL OS는 퀀텀 (4ms)을 시작하고 3.5ms 후에 OS 퀀텀은 현재 SQL OS 스레드를 중지하기로 결정했습니다. 지금 벌어지는 일은?

---

OS Quantum에 대한 심층 분석

다음 두 섹션에서는 OS 퀀텀에 관해 지금까지 찾은 내용과 퀀텀의 지속 시간을 계산하는 방법에 대해 설명합니다. OS "quantum"의 지속 시간은 "틱"을 기준으로하며 "tick"자체의 지속 시간은 일반적으로 15.625000ms 인 "클럭 간격"을 기반으로합니다. 하지만 조금 더 자세히 설명하겠습니다.

진드기

블로그 기사 Thy Tick을 아는 저자 Jim은 시계 간격의 기본 (일명 "틱")과 그 용도를 설명합니다.

“대부분의 x86 멀티 프로세서의 경우 클럭 간격은 약 15 밀리 초입니다.”와 같은 내용을 읽을 때 클럭의 값 또는“틱”간격을 결정해야합니다. 운 좋게도,이 인용문을 읽은 Windows Internals Fourth Edition은 저의 고난에 도움이되는 참고 자료를 제공합니다. ... 앞서 언급 한 책의 저자 Mark Russinovich는 자신의 웹 사이트에서 ClockRes 유틸리티를 은혜롭게 사용 가능 하게 만들었습니다 . 이 유틸리티를 실행하면서 x86 멀티 프로세서 PC의 클럭 간격이 15.625000ms임을 확인할 수있었습니다. 흥미롭지 만 궁금한 점이 더 알고 싶어합니다.

양자

이 기사의 저자는 두 번째 기사에서 계속 설명합니다. 그...

물론 틱 간격이 중요한 이유는 스레드 스케줄링에 영향을주기 때문 입니다. Windows 스케줄러는 동일한 우선 순위 수준에서 다른 작업을 실행하기 전에 각 스레드에 "양자"시간을 제공합니다. 스케줄러가 스레드에 할당하는 퀀텀은 틱 간격의 배수입니다 . 특정 스레드에 대해 선택된 특정 양자 값은이 기사와 함께 가고 싶은 곳을 약간 뛰어 넘습니다.

자, 나는 양자가 무엇인지 알고 있지만 양자가 얼마나 오래 실행 될지는 알지 못합니다.

지금은 XPe에서 포 그라운드 스레드의 기본 퀀텀 값을 살펴 보자. 이 경우 Windows 스케줄러는 18 또는 6 틱 간격의 퀀텀을 할당합니다. (예, 퀀텀을 틱 간격으로 변환하려면 3으로 나눠야합니다. 그러나 다중의 이유는 스케줄러가 스레드를 일시 중단시키는 조작을 수행하기 위해 스레드를 "충전"할 수있게하기 위함입니다.)

이제 클럭 간격 (틱)이 약 15.625000ms이고 기본 퀀텀이 18 인 Windows 데스크톱 OS에서 6 틱 또는 93.750000ms (18/3 * 15.625000ms)가되어야합니다.

Windows Server OS에서 기본 퀀텀은 다릅니다. "프로세서 예약"설정이 "백그라운드 서비스"로 설정되어 있습니다.

^{이 설정은 "시스템 설정 | 고급 (탭) | 성능 (섹션) | 설정 ..."을 통해 "성능 옵션 | 고급 (탭) | 프로세서 스케줄링"을 엽니 다.}

기본 양자 설정은 36 (배경)에서 36 (전경)입니다. 양자는 더 크고 따라서 더 길다. 이는 Windows 데스크톱 OS에서 백그라운드 서비스 용으로 설정된 서버 OS에서 약 187.500000ms 인 18 (6 틱) 양자 포 그라운드 설정의 93.750000ms의 두 배 입니다.

관찰 / 설명

서버 나 데스크톱에서 설정을 "백그라운드 서비스"에서 "애플리케이션"으로 변경하면 레지스트리 의 HKLM \ SYSTEM \ CurrentControlSet \ Control \ PriorityControl \ Win32PrioritySeparation 키가 0x18에서 0x02로 변경됩니다. 0x02의 기본 양자 값은 무엇입니까? 이것은 주석에서 찾을 수 있습니다.

0x02 값은 "Short vs. Long"및 "Variable vs. Fixed"필드가 OS의 기본값임을 나타냅니다.

XPe & XP Pro에서이 필드의 기본값은 Short & Variable입니다. 비트는 다음 비트 추가 비트 설정과 동일합니다 : 0x24.

이 값을 0x02와 함께 OR하면 0x26이 표시되며 기사의 표에서 찾을 수 있습니다.

^{참조 : "Master Quantum"에 대한 의견 (MSDN 블로그)}

같은 기사에서 양자 설정을 설명하는 표 :

Win32PrioritySeparation   Foreground   Background
0x28, 0x29, 0x2A                  18           18
0x18, 0x19, 0x1A                  36           36
0x24                               6            6
0x25, 0x14                        12            6
0x26                              18            6
0x15                              24            6
0x16                              36            6

OS 퀀텀 요약

위의 정보와 기사 인용문을 기반으로, 우리는 양자 크기가 고정 된 크기가 아니라 시스템 속성의 OS 설정에서 파생되었음을 알고 있습니다. 양자는 Win32PrioritySeparation레지스트리 의 설정에 따라 일반적으로 "시스템 속성"의 설정 중 하나 ( "백그라운드 서비스"또는 "응용 프로그램")에 해당합니다.

OS 수준의 양자는

• "응용 프로그램"설정
  • 포 그라운드 애플리케이션의 경우 18 (6 틱) (93.75ms)
  • 백그라운드 응용 프로그램의 경우 6 (2 틱) (31.25ms)
• "백그라운드 서비스"설정
  • 포 그라운드 애플리케이션의 경우 36 (18 틱) (187.5ms)
  • 백그라운드 애플리케이션의 경우 36 (18 틱) (187.5ms)

이제 백그라운드 서비스에 최적화 된 Windows Server 설정의 OS 퀀텀 은 다음과 같습니다.

36 / 3 * 15.625000 ms = 187.5 ms

---

SQL OS 양자

이 섹션에는 SQL OS 퀀텀에서 찾은 내용이 나와 있습니다.

SOS_SCHEDULER_YIELD 대기 유형

SOS_SCHEDULER_YIELD 대기 유형에 대한 Paul Randall의 설명에서 :

이 대기 유형은 스레드가 전체 스레드 퀀텀 (변경할 수없는 모든 버전의 SQL Server에서 4 밀리 초)에 대해 실행될 수 있었으므로 스케줄러에서 실행 가능 큐의 맨 아래로 이동하여 자발적으로 스케줄러를 생성했습니다.

^{참조 : SOS_SCHEDULER_YIELD (SQLSkills.com 대기 유형)}

SQL Server DMV의 스케줄러

sys.dm_os_schedulers DMV의 SQL Server DMV에 대한 설명

[...] Windows는 선점 예약 메커니즘을 사용하고 모든 스레드에 CPU 시간의 양자를 할당합니다. 스레드가 양자를 소비하면 큐로 보내지고 다른 스레드에는 실행이 부여됩니다.

반대로 SQL Server는 스레드 가 자발적으로 퀀텀 시간을 산출 할 수있는 경우 협업 스케줄링 메커니즘을 사용합니다 (SOS_SCHEDULER_YIELD 대기 유형이있는 경우이 동작을 볼 수 있음). 스레드가 실행을 위해 신호를 보내지 만 실행할 준비가되지 않은 경우 다른 스레드를 선호하여 양자 시간을 생성 할 수 있기 때문에 SQL Server는 CPU 사용률을 최적화 할 수 있습니다 .

^{참조 : SQL Server 스케줄러, 작업자 및 작업 이해 (MSSQLTips.com)}

SQL Server CPU 압력 감지

이것은 SQL Server의 CPU 압력에 관한 기사의 아주 작은 섹션입니다.

작업이 다른 작업을 실행하기 위해 자발적으로 스케줄러를 생성 할 때 발생합니다. 이 대기 중에 작업은 양자가 갱신되기를 기다리고 있습니다 .

^{참조 : SQL Server CPU 압력 감지 (MSSQLTips.com)}

sys.dm_os_schedulers (Microsoft 문서)

다음 인용문은 내가 찾을 수있는 SQL OS 퀀텀에 관한 가장 중요한 정보입니다.

quantum_length_us bigint  Identified for informational purposes only. 
                          Not supported. Future compatibility is not guaranteed. 
                          Exposes the scheduler quantum used by SQLOS.

^{참조 : sys.dm_os_schedulers (Transact-SQL) (Microsoft | Docs)}

---

내 수수께끼

서버 OS Quantum은 SQL Server 서비스가 "작업"을 실행하는 데 걸리는 시간을 조정합니다. SQL Server OS Quantum은 4ms로 정의됩니다. 187.5ms를 4ms로 나누면 3.5ms가 남습니다.

그리고 우리는 Clock Interval이 기본 15.625000 ms 이외의 것으로 설정된 시점에 대한 토론조차 시작하지 않았습니다.

간단한 질문

SQL Server Quantum (4ms)은 서버 OS Quantum (일반적으로 187.5ms)과 어떻게 동기화됩니까?

간단한 질문 설명

184ms의 OS 퀀텀 (46 개의 전체 SQL 퀀텀에 해당)이 사용 된 후 OS 퀀텀은 일정을 다른 프로세스로 넘기기 전에 3.5ms의 시간이 걸립니다. SQL OS는 퀀텀 (4ms)을 시작하고 3.5ms 후에 OS 퀀텀은 현재 SQL OS 스레드를 중지하기로 결정했습니다. 지금 벌어지는 일은?

스케줄러가 선점 형이 아니더라도 SQL Server 스케줄러는 여전히 퀀텀 개념을 준수합니다. SQL Server 작업이 운영 체제에서 CPU를 포기하도록하는 것보다 주기적으로 대기 큐에 주기적으로 대기하도록 요청하고 내부적으로 정의 된 4 밀리 초 양자를 초과하고 작업 중간에 있지 않은 경우 멈출 수 없으며 자발적으로 CPU를 포기합니다.

- " Microsoft SQL Server 2012 Internals ", Kalen Delaney et. 알. pp38

-2 장 "SQLOS"Jonathan Kehayias

따라서 SQL Server 내부의 "quantum"이라는 개념은 프로그래밍 작업을위한 "지침"에 가깝습니다. IE는 테이블 스캔을 수행하는 작업과 같은 작업을 작성할 때 페이지 래치, IO 래치를 잠그지 않거나 잠시 동안 대기하는 경우 작업을 중지하고 요청해야합니다. 대기중인 다른 작업이있는 경우 실행 가능한 큐에 다시 넣습니다.

그러나 이것을 구현하는 것은 작업 프로그래머에게 달려 있으며 각 종류의 작업에 대해 정확히 4ms 가 아닐 수도 있습니다 . 예를 들어 테이블 스캔 작업은 스캔 포인트를 구현하기 위해 스캔 된 페이지 수에 따라 간단한 휴리스틱을 사용할 수 있습니다.

그래서

SQL OS는 퀀텀 (4ms)을 시작하고 3.5ms 후에 OS 퀀텀은 현재 SQL OS 스레드를 중지하기로 결정했습니다. 지금 벌어지는 일은?

작업이 실행되는 동안 Windows에서 SQL Server 스레드를 선점하면 일시 중지되며 스레드가 CPU에서 다음에 예약되면 중단 된 지점에서 계속됩니다. 아마도 차이를 알지 못하므로 4ms 양자의 균형을 계속 소비 할 것입니다. 그러나 다시 항복 동작은 SQLOS의 동작이 아니라 작업의 구현 세부 사항이므로 여기서 다른 작업이 다르게 동작 할 수 있습니다.

_{원래 의견으로 남은 답변 기여}

SQL Server Quantum (4ms)은 서버 OS Quantum (일반적으로 187.5ms)과 어떻게 동기화됩니까?

그렇지 않으며 SQL Server는 선점 예약을 사용하지 않습니다. 작업 항목은 항복점에 도달해야하며 그렇지 않은 경우 NONYIELDING스케줄러 와 같은 항목을 얻게됩니다 . 패리티가 없습니다. SQL Server는 시간을 분배하지 않습니다. 특정 스레드가 Windows에 적합하도록 예약하고 Windows가 스레드를 예약합니다. 퀀텀은 한동안 명명법입니다. 그게 다야. SQL Server는 선제 적이 지 않으며 코드 전체에서 자체를 생성하는 것은 무엇이든 실행해야합니다. – Sean Gallardy

OS 퀀텀이 만료되면 스레드가 강제로 예약 해제됩니다. 이것은 SQL Server에 투명합니다. SQLOS는 언제 이런 일이 발생했는지 감지 할 수 없습니다. 이에 대한 Win32 API는 없습니다. 스케줄링은 사용자 모드 스레드에 투명합니다. Windows 스케줄러는 어떤 사용자 모드 스레드가 수행 중인지 알거나 신경 쓰지 않습니다. Windows는 실행 가능한 스레드 만보고 OS 퀀텀의 끝까지 또는 차단 될 때까지 실행할 수 있습니다. – usr

에서 SQL Server의 과도한 SOS_SCHEDULER_YIELD 대기 유형의 값을 처리하는 방법 니콜라 Dimitrijevic에 의해, 용어 "양자는"기본적으로 "작업이 실제로 노동자에 할당 된 소비 한 시간"을 의미하는 데 사용하지만, 그 윈도우 양자와 같은 의미 아니다되어, OS가 CPU에서 스레드를 제거하는 기간입니다. 그것들은 단지 다른 개념입니다. OS 퀀텀에 도달하여 OS가 스레드를 강제로 종료하면 컨텍스트 전환이 발생합니다. SQL Server의 스레드는 다른 프로그램과 마찬가지로 일시 중단됩니다. – David Browne – Microsoft 및 George.Palacios .

---

설명서에서 발췌 : SQL Server 2000 사용자 모드 스케줄러 내부 (SQL Server 2000 용으로 작성되었지만 여전히 관련됨) :

선제 적 vs. 공동 작업

반대로 UMS는 스레드를 사용하여 자발적으로 산출합니다. UMS는 Windows 커널을 절대적으로 필요 이상으로 사용하지 못하도록하기위한 접근 방식을 취합니다. 작업자 스레드가 필요할 때 생산하도록 계산할 수있는 시스템에서는 스케줄링 프로세스가 애플리케이션의 특정 요구에 맞게 조정될 수 있기 때문에 협업 스케줄러는 실제로 선점보다 효율적일 수 있습니다. 앞서 말했듯이 UMS는 운영 체제가 예상 할 수있는 것보다 SQL Server의 일정 요구를 잘 알고 있습니다.

UMS가 일정을 인수하는 방법

UMS가 Windows에서 허용하지 않고 SQL Server의 스케줄링 요구를 처리하는 경우 UMS는 OS가 다른 모든 프로세스에서 수행하는 작업을 수행하지 못하게해야합니다. 선제 적 운영 체제에서 어떻게합니까? UMS는 Windows 이벤트 객체를 사용하여 영리한 트릭을 통해이를 해결합니다. UMS 아래의 각 스레드에는 연관된 이벤트 오브젝트가 있습니다. 예약을 위해 Windows는 실행 가능한 것으로 간주되지 않는 스레드 (무한 대기 상태이므로 실행할 수없는 스레드)를 무시합니다. 이를 알면 UMS 는 해당 이벤트 개체에서 WaitForSingleObject 를 호출 하고 시간 초과 값에 대해 INFINITE 를 전달 하여 예약하지 않으려는 스레드를 휴면 상태로 만듭니다 .

Windows가 동일한 프로세서에서 여러 스레드를 예약하지 못하도록하여 컨텍스트 스위치의 오버 헤드와 비용이 발생하지 않도록 UMS는 프로세서 당 하나의 스레드 만 실행 가능하도록 (즉, 무한 대기 상태가 아님) 유지하려고합니다.