스레드 및 태스크 아키텍처 가이드

아티클
07/12/2024

적용 대상: SQL Server Azure SQL 데이터베이스 Azure SQL Managed Instance

운영 체제 태스크 예약

스레드는 운영 체제에서 실행되는 가장 작은 공정 단위로, 애플리케이션 논리를 여러 개의 동시 실행 경로로 분리할 수 있습니다. 스레드는 여러 태스크를 동시에 수행할 수 있는 복잡한 애플리케이션에 유용합니다.

운영 체제는 애플리케이션의 인스턴스를 실행할 때 인스턴스를 관리하기 위해 프로세스라는 단위를 생성합니다. 프로세스에는 실행 스레드가 있습니다. 실행 스레드는 애플리케이션 코드가 수행하는 일련의 프로그래밍 명령어입니다. 예를 들어, 간단한 애플리케이션에 연속적으로 수행될 수 있는 단일 명령어 집합이 있는 경우 해당 명령어 집합은 단일 태스크로 처리되며 애플리케이션을 통해 하나의 실행 경로(또는 스레드)만 존재합니다. 더 복잡한 애플리케이션에는 연속적으로 수행되는 대신 동시에 수행될 수 있는 여러 개의 태스크가 있을 수 있습니다. 애플리케이션은 리소스를 많이 사용하는 작업인 각 태스크에 대해 별도의 프로세스를 시작하거나 리소스를 상대적으로 적게 사용하는 별도의 스레드를 시작하여 이를 수행할 수 있습니다. 또한 각 스레드는 프로세스와 관련된 다른 스레드와 독립적으로 실행되도록 예약할 수 있습니다.

스레드를 사용하면 단일 CPU를 사용하는 컴퓨터에서도 복잡한 애플리케이션이 프로세서(CPU)를 더 효율적으로 사용할 수 있습니다. CPU가 1개이면 한 번에 하나의 스레드만 실행할 수 있습니다. 한 스레드가 디스크 읽기 또는 쓰기와 같이 CPU를 사용하지 않는 장기 실행 작업을 실행하는 경우, 첫 번째 작업이 완료될 때까지 다른 스레드가 실행될 수 있습니다. 다른 스레드가 작업이 끝날 때까지 기다리는 동안 스레드를 실행할 수 있으면 애플리케이션이 CPU의 사용을 최대화할 수 있습니다. 이와 같은 이점은 특히 데이터베이스 서버와 같은 여러 사용자가 사용하는 디스크 입출력 집중형 애플리케이션에서 잘 나타납니다. 여러 개의 CPU가 있는 컴퓨터에서는 CPU당 하나의 스레드를 동시에 실행할 수 있습니다. 예를 들어, 컴퓨터에 CPU가 8개인 경우 동시에 8개 스레드를 실행할 수 있습니다.

SQL Server 작업 스케줄링

SQL Server의 범위에서 요청은 쿼리 또는 일괄 처리의 논리적인 표현입니다. 요청은 검사점이나 로그 기록기와 같이 시스템 스레드에 필요한 작업도 나타냅니다. 요청은 수명 기간 동안 다양한 상태로 존재하며, 요청을 실행하는 데 필요한 리소스를 사용할 수 없는 경우 잠금 또는 래치)와 같은 대기 상태가 누적될 수 있습니다. 요청 상태에 대한 자세한 내용은 sys.dm_exec_requests를 참조하세요.

작업

작업은 요청을 수행하기 위해 완료해야 하는 작업 단위를 나타냅니다. 단일 요청에 하나 이상의 작업을 할당할 수 있습니다.

병렬 요청에는 하나의 상위 작업(또는 조정 작업)과 여러 개의 하위 작업으로 구성된 여러 개의 활성 작업이 순차적으로 실행되는 것이 아니라 동시에 실행됩니다. 병렬 요청에 대한 실행 계획에는 병렬로 실행되지 않는 연산자를 사용하는 계획의 일련 분기 영역이 포함되기도 합니다. 상위 작업은 이러한 직렬 연산자를 실행하는 역할도 담당합니다.
직렬 요청은 실행 중 특정 시점에 활성 작업이 1개만 있습니다. 작업은 수명 기간 동안 다양한 상태로 존재합니다. 작업 상태에 대한 자세한 내용은 sys.dm_os_tasks를 참조하세요. 작업이 일시 중단됨 상태일 경우 작업을 실행하는 데 필요한 리소스가 사용 가능해질 때까지 기다리고 있는 것입니다. 대기 태스크에 대한 자세한 내용은 sys.dm_os_waiting_tasks를 참조하세요.

작업자

SQL Server 작업자 스레드(작업자 또는 스레드라고도 함)는 운영 체제 스레드의 논리적 표현입니다. 직렬 요청을 실행할 때 SQL Server 데이터베이스 엔진은 활성 작업을 실행할 작업자를 생성합니다(1:1). 행 모드에서 병렬 요청을 실행할 때 SQL Server 데이터베이스 엔진은 상위 스레드(또는 조정 스레드)라고 하는 작업자를 할당하여 할당된 작업을 완료하는 하위 작업자를 조정합니다(역시 1:1). 상위 스레드에는 연결된 상위 작업이 있습니다. 상위 스레드는 요청의 진입점이며 엔진이 쿼리를 구문 분석하기 전에도 존재합니다. 상위 스레드의 주요 책임은 다음과 같습니다:

병렬 검색을 조정합니다.
병렬 하위 작업자를 시작합니다.
병렬 스레드에서 행을 수집하여 클라이언트로 전송합니다.
로컬 및 글로벌 집계를 수행합니다.

참고 항목

쿼리 계획에 직렬 및 병렬 분기가 있는 경우 병렬 작업 중 하나가 직렬 분기 실행을 담당합니다.

각 작업에 대해 생성되는 작업자 스레드의 수는 다음에 따라 달라집니다.

쿼리 최적화 도구에 의해 결정된 요청이 병렬 처리에 적합한지 여부.
현재 부하를 기준으로 시스템에서 실제 사용 가능한 병렬 처리 정도(DOP). 이는 최대 병렬 처리 수준(MAXDOP)에 대한 서버 구성을 기반으로 하는 예상 DOP와 다를 수 있습니다. 예를 들어 MAXDOP에 대한 서버 구성은 8이지만 런타임에 사용 가능한 DOP는 단지 2일 수 있습니다. 이것이 쿼리 성능에 영향을 미칩니다. 메모리 압력과 작업자 부족은 런타임에 사용 가능한 DOP를 감소시키는 두 가지 조건입니다.

참고 항목

MAXDOP(최대 병렬 처리 수준) 제한은 요청별이 아니라 태스크별로 설정됩니다. 즉, 병렬 쿼리 실행 중에 단일 요청이 MAXDOP 한도까지 여러 작업을 생성할 수 있으며 각 작업은 하나의 작업자를 사용하게 됩니다. MAXDOP에 대한 자세한 내용은 최대 병렬 처리 수준 서버 구성 옵션 구성을 참조하세요.

스케줄러

SOS 스케줄러라고도 하는 스케줄러는 작업을 대신하여 작업을 수행하는 데 프로세스 시간이 필요한 작업자 스레드를 관리합니다. 각 스케줄러는 개별 프로세서(CPU)에 매핑됩니다. 작업자가 스케줄러에서 활성 상태로 유지될 수 있는 시간을 OS 양자라고 하며, 최대 4ms입니다. 양자 시간이 만료되면 작업자는 CPU 리소스에 액세스해야 하는 다른 작업자에게 자신의 시간을 양보하고 상태를 변경합니다. CPU 리소스에 대한 액세스를 최대화하기 위한 작업자 간의 이러한 협력을 협력적 스케줄링이라고 하며, 비선점 스케줄링이라고도 합니다. 작업자 상태 변경은 해당 작업자와 연결된 태스크, 그리고 해당 태스크와 연결된 요청에 전파됩니다. 작업자 상태에 대한 자세한 내용은 sys.dm_os_workers를 참조하세요. 스케줄러에 대한 자세한 내용은 sys.dm_os_schedulers를 참조하세요.

요약하면 요청은 작업 단위를 수행하기 위해 하나 이상의 작업을 생성할 수 있습니다. 각 작업은 작업을 완료할 책임이 있는 작업자 스레드에 할당됩니다. 각 작업자 스레드는 작업의 활성 실행을 위해 예약(스케줄러에 배치)되어야 합니다.

다음 시나리오를 살펴 보십시오.

작업자 1은 디스크 기반 테이블에 대한 미리 읽기를 사용하는 읽기 쿼리처럼 오래 실행되는 작업입니다. 작업자 1은 필요한 데이터 페이지가 이미 버퍼 풀에 있으므로 I/O 작업을 기다리기 위해 양보할 필요가 없으며, 산출하기 전에 전체 양자를 소비할 수 있습니다.
작업자 2는 밀리초 미만의 짧은 작업을 수행하므로 전체 양자가 소진되기 전에 산출해야 합니다.

이 시나리오와 SQL Server 2014(12.x)까지는 기본적으로 작업자 1이 더 많은 전체 양자 시간을 유지함으로써 스케줄러를 독점할 수 있습니다.

SQL Server 2016(13.x)부터는 협력 스케줄링에 LDF(큰 적자 우선) 스케줄링이 포함됩니다. LDF 스케줄링을 사용하면 양자 사용 패턴이 모니터링되고 하나의 작업자 스레드가 스케줄러를 독점하지 않습니다. 동일한 시나리오에서 작업자 2는 작업자 1이 더 많은 양자를 허용받기 전에 반복된 양자를 소비할 수 있으므로 작업자 1이 비우호적인 패턴으로 스케줄러를 독점하는 것을 방지할 수 있습니다.

병렬 작업의 스케줄

MaxDOP 8로 구성된 SQL Server가 있고 CPU 선호도가 NUMA 노드 0과 1에 걸쳐 24개의 CPU(스케줄러)에 대해 구성되었다고 가정해 보겠습니다. 스케줄러 0~11은 NUMA 노드 0에 속하고, 스케줄러 12~23은 NUMA 노드 1에 속합니다. 애플리케이션이 데이터베이스 엔진에 다음 쿼리(요청)를 보냅니다.

SELECT h.SalesOrderID,
    h.OrderDate,
    h.DueDate,
    h.ShipDate
FROM Sales.SalesOrderHeaderBulk AS h
INNER JOIN Sales.SalesOrderDetailBulk AS d
    ON h.SalesOrderID = d.SalesOrderID
WHERE (h.OrderDate >= '2014-3-28 00:00:00');

팁

예시 쿼리는 AdventureWorks2016_EXT 샘플 데이터베이스 데이터베이스를 사용하여 실행할 수 있습니다. 테이블 Sales.SalesOrderHeader 및 Sales.SalesOrderDetail은(는) 50배 확대되어 Sales.SalesOrderHeaderBulk 및 Sales.SalesOrderDetailBulk(으)로 이름이 변경되었습니다.

실행 계획은 두 테이블 간의 해시 조인을 표시하며, 화살표 두 개가 있는 노란색 원을 보면 알 수 있듯이 각 연산자는 병렬로 실행됩니다. 각 병렬 처리 연산자는 계획에서 서로 다른 분기입니다. 따라서 다음 실행 계획에는 3개의 분기가 있습니다.

병렬 쿼리 계획을 보여주는 다이어그램.

참고 항목

실행 계획을 트리로 생각하면 분기는 병렬 처리 연산자 사이에 하나 이상의 연산자를 그룹화하는 계획의 영역으로, 교환 반복자라고도 합니다. 계획 연산자에 대한 자세한 내용은 실행 계획 논리 및 물리 연산자 참조를 참조하세요.

실행 계획에는 분기 세 개가 있지만 이 실행 계획에서는 실행 중 다음 분기 두 개만 동시에 실행할 수 있습니다.

Sales.SalesOrderHeaderBulk(조인의 빌드 입력)에서 클러스터형 인덱스 스캔이 사용되는 분기가 단독으로 실행됩니다.
그런 다음 Sales.SalesOrderDetailBulk(조인의 프로브 입력)에서 클러스스터형 인덱스 스캔이 사용된 분기는 Bitmap이 생성되고 현재 Hash Match가 실행되고 있는 분기와 동시에 실행됩니다.

실행 계획 XML은 16개의 작업자 스레드가 NUMA 노드 0에서 예약되고 사용되었음을 보여줍니다.

<ThreadStat Branches="2" UsedThreads="16">
  <ThreadReservation NodeId="0" ReservedThreads="16" />
</ThreadStat>

스레드 예약은 데이터베이스 엔진이 요청에 필요한 모든 작업을 수행하기에 충분한 작업자 스레드를 갖도록 보장합니다. 스레드는 여러 NUMA 노드에 걸쳐 예약할 수도 있고, 하나의 NUMA 노드에만 예약할 수도 있습니다. 스레드 예약은 실행이 시작되기 전에 런타임에 수행되며 스케줄러 로드에 따라 달라집니다. 예약된 작업자 스레드의 수는 일반적으로 concurrent branches * runtime DOP 수식에서 파생되며 상위 작업자 스레드는 제외됩니다. 각 분기는 MaxDOP와 동일한 수의 작업자 스레드로 제한됩니다. 이 예시에서는 두 개의 동시 분기가 있고 MaxDOP가 8로 설정되어 있으므로 2 * 8 = 16입니다.

참고로, 하나의 분기가 완료되고 두 개의 분기가 동시에 실행되고 있는 라이브 쿼리 통계의 라이브 실행 계획을 관찰합니다.

라이브 병렬 쿼리 계획을 보여주는 다이어그램.

SQL Server 데이터베이스 엔진은 활성 작업(1:1)을 실행하기 위해 작업자 스레드를 할당하며, 이는 쿼리 실행 중에 sys.dm_os_tasks를 쿼리하여 관찰할 수 있습니다. DMV를 쿼리하면 다음 예시에서 볼 수 있습니다.

SELECT parent_task_address, task_address,
       task_state, scheduler_id, worker_address
FROM sys.dm_os_tasks
WHERE session_id = <insert_session_id>
ORDER BY parent_task_address, scheduler_id;

팁

상위 작업에 대해 parent_task_address 열은 항상 NULL입니다.

팁

매우 바쁜 SQL Server 데이터베이스 엔진에서는 예약 스레드가 설정한 제한을 초과하는 활성 작업이 많이 표시될 수 있습니다. 이러한 작업은 더 이상 사용되지 않는 분기에 속해 있으며 정리를 기다리는 일시적인 상태일 수 있습니다.

결과 집합은 다음과 같습니다. 현재 실행 중인 분기에는 17개의 활성 작업이 있습니다: 예약된 스레드에 해당하는 16개의 하위 작업과 상위 작업 또는 조정 작업입니다.

parent_task_address	task_address	task_state	scheduler_id	worker_address
NULL	`0x000001EF4758ACA8`	SUSPENDED	3	0x000001EFE6CB6160
0x000001EF4758ACA8	0x000001EFE43F3468	SUSPENDED	0	0x000001EF6DB70160
0x000001EF4758ACA8	0x000001EEB243A4E8	SUSPENDED	0	0x000001EF6DB7A160
0x000001EF4758ACA8	0x000001EC86251468	SUSPENDED	5	0x000001EEC05E8160
0x000001EF4758ACA8	0x000001EFE3023468	SUSPENDED	5	0x000001EF6B46A160
0x000001EF4758ACA8	0x000001EFE3AF1468	SUSPENDED	6	0x000001EF6BD38160
0x000001EF4758ACA8	0x000001EFE4AFCCA8	SUSPENDED	6	0x000001EF6ACB4160
0x000001EF4758ACA8	0x000001EFDE043848	SUSPENDED	7	0x000001EEA18C2160
0x000001EF4758ACA8	0x000001EF69038108	SUSPENDED	7	0x000001EF6AEBA160
0x000001EF4758ACA8	0x000001EFCFDD8CA8	SUSPENDED	8	0x000001EFCB6F0160
0x000001EF4758ACA8	0x000001EFCFDD88C8	SUSPENDED	8	0x000001EF6DC46160
0x000001EF4758ACA8	0x000001EFBCC54108	SUSPENDED	9	0x000001EFCB886160
0x000001EF4758ACA8	0x000001EC86279468	SUSPENDED	9	0x000001EF6DE08160
0x000001EF4758ACA8	0x000001EFDE901848	SUSPENDED	10	0x000001EFF56E0160
0x000001EF4758ACA8	0x000001EF6DB32108	SUSPENDED	10	0x000001EFCC3D0160
0x000001EF4758ACA8	0x000001EC8628D468	SUSPENDED	11	0x000001EFBFA4A160
0x000001EF4758ACA8	0x000001EFBD3A1C28	SUSPENDED	11	0x000001EF6BD72160

16개의 하위 작업 각각에 다른 작업자 스레드가 할당되어 있지만(worker_address 열에 표시됨) 모든 작업자가 동일한 8개 스케줄러 풀(0,5,6,7,8,9,10,11)에 할당되어 있고 상위 작업은 이 풀 외부의 스케줄러(3)에 할당되어 있음을 관찰합니다.

Important

특정 분기의 첫 번째 병렬 작업 세트가 예약되면 데이터베이스 엔진은 다른 분기의 추가 작업에 대해 동일한 스케줄러 풀을 사용합니다. 즉, 전체 실행 계획의 모든 병렬 작업에 동일한 스케줄러 세트가 사용되며, MaxDOP에 의해서만 제한됩니다.

SQL Server 데이터베이스 엔진은 항상 작업 실행을 위해 동일한 NUMA 노드에서 스케줄러를 할당하도록 시도하고, 스케줄러를 사용할 수 있는 경우 순차적으로(라운드 로빈 방식) 할당합니다. 그러나 부모 태스크에 할당된 작업자 스레드는 다른 태스크와 다른 NUMA 노드에 배치할 수 있습니다.

작업자 스레드는 해당 양자(4ms) 동안만 스케줄러에서 활성 상태를 유지할 수 있으며, 해당 양자가 경과한 후에는 다른 작업에 할당된 작업자 스레드가 활성 상태가 될 수 있도록 스케줄러를 양보해야 합니다. 작업자의 양자가 만료되어 더 이상 활성화되지 않으면 해당 작업은 래치나 잠금과 같이 현재 사용할 수 없는 리소스에 대한 액세스가 필요하지 않다고 가정하고 다시 실행 상태로 이동할 때까지 해당 작업은 실행 가능 상태가 아닌 일시 중단 상태로 FIFO 큐에 배치되며, 이 경우 해당 리소스를 사용할 수 있을 때까지 작업은 실행 가능 상태가 아닌 일시 중단 상태로 배치됩니다.

팁

위에 표시된 DMV 출력의 경우 모든 활성 작업이 SUSPENDED 상태입니다. 대기 태스크에 대한 자세한 내용은 dm_os_waiting_tasks DMV를 쿼리하여 확인할 수 있습니다.

요약하자면, 병렬 요청은 여러 작업을 생성합니다. 각 작업은 단일 작업자 스레드에 할당되어야 합니다. 각 작업자 스레드는 하나의 스케줄러에 할당되어야 합니다. 따라서 사용 중인 스케줄러의 수는 분기당 병렬 작업 수를 초과할 수 없으며, 이는 MaxDOP 구성 또는 쿼리 힌트에 의해 설정됩니다. 조정 스레드는 MaxDOP 제한에 영향을 주지 않습니다.

CPU에 스레드 할당

기본적으로 SQL Server의 각 인스턴스는 각 스레드를 시작하고 운영 체제는 로드를 기반으로 컴퓨터의 프로세서(CPU)에 SQL Server 인스턴스의 스레드를 배포합니다. affinity 프로세스가 운영 체제 수준에서 사용하도록 설정된 경우, 운영 체제에서 각 스레드를 특정 CPU에 할당합니다. 이와는 대조적으로 SQL Server 데이터베이스 엔진은 라운드 로빈 방식으로 CPU 간에 스레드를 균등하게 배포하는 스케줄러에 SQL Server 작업자 스레드를 할당합니다.

멀티태스킹을 수행하기 위해, 예를 들어 여러 애플리케이션이 동일한 CPU 세트에 액세스할 때 운영 체제는 때때로 작업자 스레드를 서로 다른 CPU 간에 이동합니다. 운영 체제 측면에서는 효율적이지만 각 프로세서 캐시에 데이터가 반복적으로 다시 로드되어 시스템 로드가 많은 경우 이 활동으로 인해 SQL Server 성능이 저하될 수 있습니다. 특정 스레드에 CPU를 할당하면 프로세서 재로드를 제거하고 CPU 간 스레드 이동을 줄임으로써(컨텍스트 전환을 줄임으로써) 이러한 조건에서 성능을 향상할 수 있으며, 이러한 스레드와 프로세서 간의 연결을 프로세서 선호도라고 합니다. 선호도가 활성화된 경우 운영 체제는 각 스레드를 특정 CPU에 할당합니다.

선호도 마스크 옵션은 ALTER SERVER CONFIGURATION을 사용하여 설정합니다. 선호도 마스크가 설정되지 않은 경우 SQL Server 인스턴스는 마스크가 해제되지 않은 스케줄러 간에 작업자 스레드를 균등하게 할당합니다.

주의

운영 체제에서 CPU 선호도를 구성하지 말고 SQL Server에서도 선호도 마스크를 구성하지 않습니다. 이러한 설정은 동일한 결과를 달성하기 위한 것으로, 구성이 일치하지 않으면 예측할 수 없는 결과가 발생할 수 있습니다. 자세한 내용은 선호도 마스크 옵션을 참조하세요.

스레드 풀링은 많은 수의 클라이언트가 서버에 연결되어 있을 때 성능을 최적화하는 데 도움이 됩니다. 일반적으로 각각의 쿼리 요청마다 별도의 운영 체제 스레드가 만들어집니다. 하지만 서버에 대한 수백 개의 연결에서 쿼리 요청마다 하나씩 스레드를 사용하면 많은 양의 시스템 리소스가 소모될 수 있습니다. 최대 작업자 스레드 옵션을 사용하면 SQL Server에서 많은 수의 쿼리 요청을 처리하는 작업자 스레드 풀을 만들어 성능을 개선할 수 있습니다.

경량 풀링 옵션 사용

스레드 컨텍스트 전환과 관련된 오버헤드는 그리 크지 않을 수 있습니다. 대부분의 SQL Server 인스턴스에서는 경량 풀링 옵션을 0 또는 1로 설정해도 성능 차이가 없습니다. 다음과 같은 특성을 가진 컴퓨터에서 실행되는 인스턴스만 경량 풀링의 이점을 활용할 수 있는 SQL Server 인스턴스입니다.

대규모 다중 CPU 서버
모든 CPU가 최대 용량에 가깝게 실행되는 경우
컨텍스트 전환 수준이 높은 경우

이러한 시스템은 경량 풀링 값을 1로 설정하면 성능이 약간 향상될 수 있습니다.

Important

일상 작업을 예약하는 데에는 파이버 모드를 사용하지 않습니다. 이렇게 하면 컨텍스트 전환의 일반적인 이점이 억제되어 성능이 저하될 수 있으며, SQL Server의 일부 구성 요소가 파이버 모드에서 올바르게 작동하지 않기 때문입니다. 자세한 내용은 경량 풀링을 참조하세요.

스레드 및 파이버 실행

Microsoft Windows에서는 1~31 사이의 숫자 우선순위 시스템을 사용하여 실행할 스레드를 예약합니다. 0은 운영 체제용으로 예약됩니다. 여러 스레드가 실행을 대기 중인 경우 우선순위가 가장 높은 스레드가 실행됩니다.

기본적으로 SQL Server의 각 인스턴스의 우선 순위는 7이며, 이를 일반 우선 순위라고 합니다. 이 기본값은 다른 애플리케이션에 부정적인 영향을 주지 않으면서 충분한 CPU 리소스를 확보할 수 있을 만큼 높은 우선순위를 SQL Server 스레드에 부여합니다.

Important

SQL Server의 이후 버전에서는 이 기능이 제거됩니다. 새 개발 작업에서는 이 기능을 사용하지 않도록 하고, 현재 이 기능을 사용하는 애플리케이션은 수정하세요.

우선 순위 높임 구성 옵션을 사용하면 SQL Server 인스턴스에서 스레드의 우선순위를 13으로 높일 수 있습니다. 이를 높은 우선 순위라고 합니다. 이 설정은 대부분의 다른 애플리케이션보다 높은 우선 순위를 SQL Server 스레드에 제공합니다. 따라서 SQL Server 스레드는 일반적으로 실행할 준비가 되면 다른 애플리케이션의 스레드에 의해 선점되지 않고 언제든 디스패치됩니다. 이렇게 하면 서버에서 다른 애플리케이션 없이 SQL Server 인스턴스만 실행 중인 경우 성능을 향상할 수 있습니다. 그러나 SQL Server에서 메모리 집약적인 작업이 발생하는 경우 다른 애플리케이션의 우선 순위가 SQL Server 스레드를 선점할 만큼 높지 않을 가능성이 높습니다.

컴퓨터에서 SQL Server의 여러 인스턴스를 실행 중인 경우 일부 인스턴스에 대해서만 우선 순위 향상을 설정하면 일반 우선 순위로 실행 중인 모든 인스턴스의 성능에 부정적인 영향을 미칠 수 있습니다. 또한 우선 순위 높임이 켜져 있으면 서버의 다른 애플리케이션 및 구성 요소의 성능이 저하될 수 있습니다. 따라서 엄격하게 제어되는 환경에서만 이 설정을 사용해야 합니다.

Hot add CPU

Hot add CPU는 실행 중인 시스템에 CPU를 동적으로 추가할 수 있는 기능입니다. CPU는 새 하드웨어를 추가하여 물리적으로 추가하거나, 온라인으로 하드웨어를 분할하여 논리적으로 추가하거나, 가상화 계층을 통해 가상으로 추가할 수 있습니다. SQL Server는 핫 추가 CPU를 지원합니다.

hot add CPU 요구 사항

핫 추가 CPU를 지원하는 하드웨어가 필요합니다.
지원되는 버전의 Windows Server Datacenter 또는 Enterprise 버전이 필요합니다. Windows Server 2012부터 핫 추가는 Standard 버전에서 지원됩니다.
SQL Server Enterprise 버전이 필요합니다.
소프트 NUMA를 사용하도록 SQL Server를 구성할 수 없습니다. 소프트 NUMA에 대한 자세한 내용은 Soft-NUMA(SQL Server)를 참조하세요.

SQL Server는 CPU를 추가한 후에는 자동으로 사용하지 않습니다. 이렇게 하면 다른 목적으로 추가될 수 있는 CPU를 SQL Server가 사용하지 못하게 됩니다. CPU를 추가한 후 RECONFIGURE 문을 실행하면 SQL Server에서 새로운 CPU를 사용할 수 있는 리소스로 인식하게 됩니다.

참고 항목

affinity64 마스크가 구성된 경우 새 CPU를 사용하려면 affinity64 마스크를 수정해야 합니다.

CPU가 64개를 초과하는 컴퓨터에서 SQL Server를 실행하기 위한 모범 사례

CPU에 하드웨어 스레드 할당

선호도 마스크 및 affinity64 마스크 서버 구성 옵션을 사용하여 프로세서를 특정 스레드에 바인딩하지 않아야 합니다. 이러한 옵션은 CPU가 최대 64개일 때만 사용할 수 있습니다. 대신, ALTER SERVER CONFIGURATION의 SET PROCESS AFFINITY 옵션을 사용합니다.

트랜잭션 로그 파일 크기 관리

트랜잭션 로그 파일의 크기를 늘리기 위해 자동 증가를 사용하지 마세요. 트랜잭션 로그를 늘리는 것은 연속적인 프로세스여야 합니다. 로그를 확장하면 로그 확장이 완료될 때까지 트랜잭션 쓰기 작업이 진행되지 않을 수 있습니다. 대신 파일 크기를 환경의 일반적인 워크로드를 지원할 수 있을 만큼 큰 값으로 설정하여 로그 파일에 대한 공간을 미리 할당합니다.

인덱스 작업의 최대 병렬 처리 수준 설정

데이터베이스의 복구 모델을 일시적으로 대량 로그 또는 단순 복구 모델로 설정하면 CPU가 많은 컴퓨터에서 인덱스 생성 또는 재구성과 같은 인덱스 작업의 성능을 향상할 수 있습니다. 이러한 인덱스 작업은 상당한 로그 활동을 생성할 수 있으며 로그 경합은 SQL Server에서 선택한 최상의 병렬 처리 수준(DOP)에 영향을 미칠 수 있습니다.

최대 병렬 처리 정도(MAXDOP) 서버 구성 옵션을 조정하는 것 외에도 MAXDOP 옵션을 사용하여 인덱스 작업에 대한 병렬 처리를 조정하는 것을 고려하세요. 자세한 내용은 병렬 인덱스 작업 구성을 참조하세요. 최대 병렬 처리 정도 서버 구성 옵션 조정에 대한 자세한 내용과 지침은 최대 병렬 처리 정도 서버 구성 옵션 구성을 참조하세요.

최대 작업자 스레드 수 옵션

SQL Server는 시작할 때 최대 작업자 스레드 서버 구성 옵션을 동적으로 구성합니다. SQL Server는 문서화된 수식을 사용하여 시작 중에 사용 가능한 CPU 수와 시스템 아키텍처를 사용하여 이 서버 구성을 결정합니다.

이 옵션은 고급 옵션으로, 숙련된 데이터베이스 관리자나 공인된 SQL Server 전문가만이 변경해야 합니다. 성능 문제가 의심되는 경우, 작업자 스레드의 가용성 때문이 아닐 수 있습니다. 원인은 작업자 스레드가 대기하게 하는 I/O와 같은 것일 가능성이 높습니다. 최대 작업자 스레드 설정을 변경하기 전에 성능 문제의 근본 원인을 찾는 것이 가장 바람직합니다. 그러나 최대 작업자 스레드 수를 수동으로 설정해야 하는 경우 이 구성 값은 항상 시스템에 있는 CPU 수의 7배 이상의 값으로 설정해야 합니다. 자세한 내용은 최대 작업자 스레드 구성을 참조하세요.

SQL 추적 및 SQL Server Profiler 사용 피하기

프로덕션 환경에서는 SQL 추적과 SQL Server Profiler를 사용하지 않는 것이 좋습니다. CPU 수가 늘어날수록 이러한 도구의 실행으로 인한 오버헤드도 늘어납니다. 프로덕션 환경에서 SQL 추적을 사용해야 하는 경우 추적 이벤트의 수를 최소로 제한합니다. 로드 중인 각 추적 이벤트를 신중하게 프로파일 및 테스트하고 성능에 큰 영향을 주는 이벤트 조합을 사용하지 않도록 합니다.

Important

SQL 추적 및 SQL Server Profiler는 사용되지 않습니다. SQL Server 추적 및 재생 개체가 포함된 Microsoft.SqlServer.Management.Trace 네임스페이스도 더 이상 사용되지 않습니다.

대신 확장 이벤트를 사용합니다. 확장 이벤트에 대한 자세한 내용은 빠른 시작: SQL Server의 확장 이벤트 및 SSMS XEvent Profiler를 참조하세요.

참고 항목

분석 서비스 워크로드용 SQL Server Profiler는 더 이상 사용되지 않으며 계속 지원됩니다.

`tempdb` 데이터 파일 수 설정

보조 데이터 파일의 수는 컴퓨터의 (논리적) 프로세서 수에 따라 달라집니다. 일반적으로 논리 프로세서 수가 8보다 작거나 같으면 논리 프로세서와 동일한 개수의 데이터 파일을 사용합니다. 논리 프로세서 수가 8개보다 많으면 8개의 데이터 파일을 사용한 다음 경합이 계속되면 경합이 허용 가능한 수준으로 줄어들 때까지 데이터 파일 수를 4의 배수만큼 늘리거나 워크로드/코드를 변경합니다. 또한 SQL Server의 임시 데이터베이스 성능 최적화에서 제공되는 tempdb에 대한 다른 권장 사항도 염두에 두어야 합니다.

그러나 tempdb의 동시성 요구 사항을 신중하게 고려하면 데이터베이스 관리 오버헤드를 줄일 수 있습니다. 예를 들어, 시스템에 64개의 CPU가 있고 일반적으로 32개의 쿼리만 tempdb를 사용하는 경우, tempdb 파일 수를 64개로 늘려도 성능이 향상되지 않습니다.

64개를 초과하는 CPU를 사용할 수 있는 SQL Server 구성 요소

다음 테이블에는 SQL Server 구성 요소가 나열되어 있으며 64개 이상의 CPU를 사용할 수 있는지 여부를 나타냅니다.

프로세스 이름	실행 프로그램	64개 이상의 CPU 사용
SQL Server 데이터베이스 엔진	Sqlserver.exe	예
Reporting Services	Rs.exe	아니요
Analysis Services	As.exe	아니요
통합 서비스	Is.exe	아니요
Service Broker	Sb.exe	아니요
전체 텍스트 검색	Fts.exe	아니요
SQL Server 에이전트	Sqlagent.exe	아니요
SQL Server Management Studio	Ssms.exe	아니요
SQL Server 설정	Setup.exe	아니요

다음을 통해 공유

스레드 및 태스크 아키텍처 가이드

운영 체제 태스크 예약

SQL Server 작업 스케줄링

작업

작업자

스케줄러

병렬 작업의 스케줄

CPU에 스레드 할당

경량 풀링 옵션 사용

스레드 및 파이버 실행

Hot add CPU

CPU가 64개를 초과하는 컴퓨터에서 SQL Server를 실행하기 위한 모범 사례

CPU에 하드웨어 스레드 할당

트랜잭션 로그 파일 크기 관리

인덱스 작업의 최대 병렬 처리 수준 설정

최대 작업자 스레드 수 옵션

SQL 추적 및 SQL Server Profiler 사용 피하기

`tempdb` 데이터 파일 수 설정

64개를 초과하는 CPU를 사용할 수 있는 SQL Server 구성 요소

피드백

추가 리소스

다음을 통해 공유

스레드 및 태스크 아키텍처 가이드

운영 체제 태스크 예약

SQL Server 작업 스케줄링

작업

작업자

스케줄러

병렬 작업의 스케줄

CPU에 스레드 할당

경량 풀링 옵션 사용

스레드 및 파이버 실행

Hot add CPU

CPU가 64개를 초과하는 컴퓨터에서 SQL Server를 실행하기 위한 모범 사례

CPU에 하드웨어 스레드 할당

트랜잭션 로그 파일 크기 관리

인덱스 작업의 최대 병렬 처리 수준 설정

최대 작업자 스레드 수 옵션

SQL 추적 및 SQL Server Profiler 사용 피하기

tempdb 데이터 파일 수 설정

64개를 초과하는 CPU를 사용할 수 있는 SQL Server 구성 요소

피드백

추가 리소스

`tempdb` 데이터 파일 수 설정