반응형
SQL 서버 내에서 발생하는 대기 상태는 수많이 존재한다. SQL 서버가 비교적 작은 규모로 사용되고 있는 경우는각각의대기 시간을 짧아 크게 문제가 되는 일은 없다.
그러나 SQL 서버가 보다 큰 사이즈의 데이터베이스를 관리하고 보다 많은 클라이언트의 리퀘스트를 효율적으로 처리하기 위해서는 모든 스레드의 스케줄러 관리를 윈도우 스케줄러에만 맡길 게 아니라 DBMS 자체의 컴포넌트를 사용하게된다.
SQLOS 스케줄러
SQLOS 스케줄러는 SQL 서버라는 애플리케이션 내부의 컴포넌트이다. SQL 서버는 윈도우 하에서 동작하는 애플리케이션이므로 여전히 윈도우 스케줄러의 지배하에 있다. 윈도우 스케줄러의 지배하에 있으면서 효율적으로 CPU 리소스를 사용케 하는 장치가 SQLOS 스케줄러이다.
SQLOS 스케줄러를 구성하는 컴포넌트
1.스케줄러
SQL 서버의 동작 시에 CPU 수 또는 코어 수와 같은 수의 스케줄러가 작성된다.다만 SQL 서버의 에디션이나 Affinity Mask 의 설정에 따라서는 컴퓨터에 탑재되어 있는 CPU 수 또는 코어 수보다 적은 경우가 있다.스케줄러는 작업자의 관리를 수행한다.
또한, 스케줄러는 한 번에 하나의 작업자만을 CPU 리소스의 할당이 가능한 상태로 한다.
**Affinity Mask 란
SQL 서버 인스턴스가 사용하는 CPU 수를 제어하기 위한 설정이다.예를들어 8개의 CPU가 탑재되어 있는 컴퓨터에서 2개의 SQL 서버 인스턴스를 동작시키는 경우 각 워크로드의 부하에 따라서 인스턴스 A에서는 2개의 CPU를 할당하고 인스턴스B 에는 6개의 CPU를 할당할 수 있다.
2.작업자
작업자는 SQL 서버에서 테스크를 실행하기 위해 반드시 필요한 컴포넌트이다. 클라이언트로부터의 리퀘스트는 다양한단계를 거친 후 최종적으로는 하나 이상의 작업자에 링크되어 처리된다.작업자는 SQL 서버 내의 오브젝트이지만 윈도우의 관리 오브젝트인 스레드와 링크되어 있다.
하나의 작업자에 대해 반드시 윈도우 스레드가 하나 존재한다.
** 비선점형(non-preemptive), 선점형(preemptive) 관리방법
멀티스레드 환경에서 CPU 리소스를 관리하는 방법에는 비선점형, 선점형의 2종류가 있다.
"비선점형"에서는 OS는 CPU 리소스의 사용권을 관리하지 않는다. CPU의 사용권은 각 애플리케이션이 다른 애플리케이션으로 자발적으로 양보할 필요가 있다."선점형"은 타임 슬라이스 등의 룰에 기초해서 OS가 각 애플리케이션의 CPU 리소스 사용을 관리한다.(일정 시간이 경과 하면 다른 애플리케이션으로 사용권을 양보한다.)
비선점형은 OS가 CPU리소스 관리를 수행하지 않는 만큼 그 비용은 줄일 수 있다. 다만, 언제까지나 CPU 리소스를 점유하는 애플리케이션이 존재하면 다른 애플리케이션은 동작하지 못해 시스템 전체에 악영향을 미친다.한편 선점형에서는 애플리케이션의 동작에 의존하지 않고 OS가 CPU 리소스의 사용권을 관리하기 때문에 모든 애플리케이션에 안정적으로 CPU 리소스를 할당할 수 있다. 그런만큼 OS의 구현이 복잡해지고 비용이 높아진다.예전에는 문제라고 여겼던 OS가 CPU에 미치는 부하도 오늘날의 CPU 성능의 향상으로 거의 무시할 수 있는 수준이 됐다. 때문에 주요한 OS는 모두 선점형 방식을 채용하고 있다.
그러나 SQLOS 스케줄러에는 비선점형 방식이 도입되어 있다. 일단 SQLOS 스케줄러상에서 실행 상태가 된 스레드는 스스로 양보하기까지 스케줄러의 사용권을 거론할 수는 없다.하나의 스레드가 사용권을 유지하면 당연히 SQL 서버 전체의 스루풋은 저하한다. 때문에 길어도 각 스레드는 수밀리초동안 스케줄러를 점유한 후에는 다른 스레드에 사용권을 양보하도록 코딩되어있다. 이 작업 단위별로 스레드 간에서 CPU의 사용권을 주고받음으로써 CPU를 쓸데없이 대기 시키는 기회를 줄여 시스템의 스루풋을 높인다.
SQLOS 스케쥴러의 관리 범위 내에서 비선점형이라고 해도 SQL 서버 자체가 윈도우하에서 동작하는 애플리케이션이기때문에, 윈도우 스케줄러의 관점에서 본 경우는 SQLOS스케줄러 배하의 모든 스레드는 선점형으로 동작하고 있다.
** 스레드 풀 이란?
스레드를 미리 만들어 놓은 하나의 풀장이라고 생각하면된다.군대를 빗대어보면, 전쟁이 나서 사방팔방에서 국지전을 펼친다고 생각해보자. 그때그때 추가병력을 요청할때마다 당신이 지휘관이라면, 1명씩 지원을 보내는 것보다 미리 100명의 군인을 섭외해서 다중적으로 발생되는 대비해 예비 병력을 갖추고 즉각 국지전에 대응해야한다.
"스레드"가 생성될 때 컴퓨터 내부적으로 운영체제(OS)가 요청을 받아들여 메모리공간을 확보해주고 그 메모리를 스레드에게 할당해준다. 스레드는 동일한 메모리영역에서 생성되고 관리되지만, 생성/수거에 드는 비용을 무시할 수 없다.그렇기 때문에 요청이 들어올 때 마다 스레드를 생성하고 일을 다하면 수거하고 하는 작업은 프로그램 퍼포먼스에 지대한 영향을 줄 수 있다. 따라서 스레드를 미리 만들어 놓는 것이다.
우리가 만든 어플리케이션에서 사용자로부터 들어온 요청을 작업큐에 넣고 스레드풀은 작업큐에 들어온 Task일감을 미리 생성해놓은 Tread들에게 일감을 할당한다. 일을 다 처리한 Thread들은 다시 어플리케이션에게 결과값을 리턴한다. (아래의 그림 참고)
만약 작업자 스레드 풀에 사용가능한 작업자가 존재하지 않을 때는 작업자의 사용 요구가 있으면 최댓값에 달하지 않는경우는 새로 작업자를 작성한다. 이미 최댓값에 달한 경우는 사용 요구를 한클라이언트는 워크 리퀘스트 큐에 추가되어대기 상태가 된다.
4.러너블 큐(Runnable Queue)
각 스케줄러는 하나의 러너블 큐를 갖고 있다. 스케줄러는 하나의 작업자만을 액티브로 한다. 만약 둘 이상의 작업자가실행가능한 경우는 러너블 큐에 리스트되어 스케줄러가 사용 가능하기를 기다린다.
5.워크 리퀘스트 큐(Work Request Queue)
각 스케줄러는 작업을 실행하기 위한 작업자를 작업자 스레드 풀에 보관하고 있다. 그러나 많은 처리 리퀘스트가 발생하면 드물게 작업자의 수가 부족할 때가 있다. 작업자가 부족해서 처리를 실행하지 못하는 태스크는 워크 리퀘스트 큐 에 리스트 되어 작업자가 사용 가능해질 때까지 기다린다. 작업자가 부족한 일반적인 원은은 블로킹이나 과도한 병렬처리이다.
6.I/O 리퀘스트 리스트(I/O Request List)
I/O 리퀘스트를 발행한 작업자는 요구한 I/O가 완료되기까지 I/O 리퀘스트 리스트에 추가된다."I/O 완료"는 윈도우에서 본 경우 "I/O"의 완료에 추가해 SQL 서버가 필요한 I/O의 후처리까지 포함한다. 이들이 모두 종료한 시점에서 I/O 리퀘스트가 완료했다고 간주한다.
7.웨이터 리스트(Waiter List)
작업자의 처리 실행 시에 필요한 SQL 서버 내의 리소스를 획득할 수 없는 경우에 작업자는 웨이터 리스트에 추가된다.웨이터 리스트는 다른 큐나 리스트와 달리 스케줄러가 직접 관리하지 않는다. 웨이터 리스트는 SQL 서버 내의 오브젝트별로 존재한다. 락을 유지하고 있던 작업자는 락이 불필요해진 시점에서 락을 해제하는 동시에 웨이터 리스트 앞에 있는 작업자에게 락 획득권을 양보한다.
반응형
'DB ARCHITECTURE' 카테고리의 다른 글
트랜잭션의 정의 및 동작 원리 (0) | 2021.12.16 |
---|---|
SQL-SERVER SCHEDULER : sqlserver 스케쥴러(2) (7) | 2021.12.15 |
SQL-SERVER SCHEDULER : 윈도우 스케쥴러 (0) | 2021.12.15 |
정규화(Normalization) (0) | 2021.08.02 |
함수적 종속 (0) | 2021.07.30 |