적용 대상:SQL Server on Linux
이 문서에서는 메모리 제한, 제어 그룹(mssql-conf) 설정, Docker 컨테이너 메모리 예제 및 스왑 공간 고려 사항을 포함하여 cgroup SQL Server on Linux 대한 메모리 구성에 대해 설명합니다.
메모
스토리지, 커널, CPU 및 네트워크 권장 사항은 성능 모범 사례( SQL Server on Linux 스토리지, 커널, CPU 및 네트워크)를 참조하세요.
mssql-conf를 사용하여 메모리 제한 설정
Linux 운영 체제에 대해 사용 가능한 실제 메모리가 충분한지 확인하기 위해 SQL Server 프로세스는 기본적으로 실제 RAM의 80%만 사용합니다. 실제 RAM이 많은 일부 시스템의 경우 20%가 상당한 수일 수 있습니다. 예를 들어 RAM이 1TB인 시스템에서 기본 설정은 약 200GB의 RAM을 사용하지 않습니다. 이런 상황에서는 메모리 한도를 더 큰 값으로 구성하는 것이 좋습니다.
mssql-conf 도구 또는 MSSQL_MEMORY_LIMIT_MB 환경 변수를 사용하여 이 값을 조정할 수 있습니다. 자세한 내용은 SQL Server에 표시되는 메모리를 제어하는 memory.memorylimitmb 설정을 참조하세요(MB 단위). 자세한 크기 조정 지침은 Linux 및 컨테이너에서 메모리 제한을 설정하기 위한 지침을 참조하세요.
제어 그룹(cgroup) v2 지원
SQL Server SQL Server 2025(17.x) 및 SQL Server 2022(16.x) CU(누적 업데이트) 20부터 제어 그룹(cgroup) v2 제약 조건을 검색하고 적용합니다. 이러한 제약 조건은 CPU 및 메모리 리소스에 대한 Linux 커널의 세분화된 제어를 제공하고 Docker, Kubernetes 및 OpenShift 환경에서 리소스 격리를 개선합니다.
이전 버전에서는 SQL Server 컨테이너 사양에 정의된 메모리 제한을 적용하지 않았기 때문에 Kubernetes 클러스터의 컨테이너화된 배포(예: Azure Kubernetes Service v1.25 이상)에 OOM(메모리 부족) 오류가 발생할 수 있습니다. cgroup v2에 대한 지원은 이 문제를 해결합니다.
cgroup 버전 확인
stat -fc %T /sys/fs/cgroup
결과는 다음과 같습니다.
| Result | Description |
|---|---|
cgroup2fs |
cgroup v2를 사용합니다. |
cgroup |
cgroup v1 사용 |
cgroup v2로 전환
가장 쉬운 경로는 cgroup v2를 지원하는 배포를 선택하는 것입니다.
수동으로 전환해야 하는 경우 GRUB 구성에 다음 매개 변수를 추가합니다.
systemd.unified_cgroup_hierarchy=1
그런 다음 GRUB를 업데이트합니다. 예를 들어 Ubuntu에서 다음을 실행합니다.
sudo update-grub
RHEL(Red Hat Enterprise Linux)에서 다음을 실행합니다.
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
cgroup v2를 사용하여 CPU 제한 보고
cgroup v2를 사용하여 CPU 제한을 구성하는 경우 SQL Server 구성된 CPU 코어 수를 오류 로그에 표시하지 않습니다. 대신 총 호스트 CPU 수를 계속 보고합니다.
SQL Server 스케줄러 및 쿼리 계획(예: 병렬 처리 결정)을 cgroup v2에 정의된 의도된 CPU 수에 맞추려면 다음 구성을 적용합니다.
프로세서 선호도 구성
cgroup 실행 할당량과 일치하도록 SQL Server 프로세서 선호도를 명시적으로 설정합니다. 다음 예제에서 cgroup 할당량은 8코어 호스트의 CPU 4개입니다.
ALTER SERVER CONFIGURATION
SET PROCESS AFFINITY CPU = 0 TO 3;
이 구성을 통해 SQL Server 의도한 수의 CPU에 대해서만 스케줄러를 만듭니다. 자세한 내용은 ALTER SERVER CONFIGURATION 및 노드 및/또는 CPU에 PROCESS AFFINITY 사용을(를) 참조하세요.
추적 플래그 8002 사용(권장)
SQLPAL 계층에서 소프트 선호도를 사용하려면 추적 플래그 8002를 사용하도록 설정합니다.
sudo /opt/mssql/bin/mssql-conf traceflag 8002 on
기본적으로 스케줄러는 선호도 마스크에 정의된 특정 CPU에 바인딩됩니다. 추적 플래그 8002를 사용하면 스케줄러가 CPU 간에 이동할 수 있으므로 일반적으로 선호도 및 cgroup 제약 조건을 유지하면서 성능이 향상됩니다. 자세한 내용은 DBCC TRACEON - 추적 플래그를 참조하세요.
추적 플래그를 사용하도록 설정한 후 SQL Server 다시 시작합니다.
예상되는 행동
다시 시작한 후:
SQL Server 선호도 설정(예: 4개의 스케줄러)으로 정의된 스케줄러 수만 만듭니다.
Linux 커널은 계속해서 cgroup v2 CPU 실행 할당량을 적용합니다.
쿼리 최적화 및 병렬 처리 결정은 전체 호스트 CPU가 아닌 의도된 CPU 수를 기반으로 합니다.
메모
SQL Server 오류 로그는 총 호스트 CPU 수를 계속 표시할 수 있습니다. 이 로깅 및 표시 동작은 cgroup v2 또는 프로세서 선호도에 의한 실제 CPU 사용량, 스케줄러 생성 또는 CPU 적용에 영향을 주지 않습니다.
자세한 내용은 다음 리소스를 참조하세요.
Linux 및 컨테이너에서 메모리 제한을 설정하기 위한 지침
SQL Server on Linux 서로 다른 수준에서 작동하는 여러 메모리 컨트롤이 있습니다. 다음 표와 다이어그램은 각 수준이 호스트 RAM에서 버퍼 풀까지 사용 가능한 메모리의 범위를 좁히는 방법을 보여 줍니다.
| 수준 | 설정한 사람 | Description |
|---|---|---|
| Host | 하드웨어/VM 구성 | 서버 또는 VM(가상 머신)의 물리적 RAM입니다. |
cgroup 제한(docker run --memory, systemd, 또는 수동) |
컨테이너 런타임, systemd 슬라이스 또는 수동 cgroup 구성 |
cgroup의 모든 프로세스에 대한 커널에 의해 강제되는 상한값(memory.max) 베어메탈 Linux에서는 선택 사항입니다. |
SQL Server 프로세스(memorylimitmb / MSSQL_MEMORY_LIMIT_MB) |
mssql-conf 또는 환경 변수 |
모든 SQL Server 구성 요소의 총 메모리입니다. 제한(있는 경우) 또는 호스트 메모리보다 cgroup 낮아야 합니다. |
버퍼 풀 (max_server_memory) |
sp_configure |
8KB 데이터 페이지의 캐시입니다.
memorylimitmb보다 낮아야 합니다. |
| 헤드룸 | 계산됨(제한 사이의 간격) |
cgroup한도(또는 호스트 메모리)와 memorylimitmbOS 오버헤드 및 보조 프로세스를 위해 예약된 부분 사이의 차이입니다. |
SQL Server on Linux에 대한 메모리 제한을 설정할 때 다음 지침을 고려합니다.
컨테이너 배포에서 컨테이너에 사용할 수 있는 전체 메모리를 제한하는 데 사용합니다
cgroup. 이 설정은 컨테이너 내의 모든 프로세스에 대한 상한을 설정합니다.메모리 제한(이는
memorylimitmb에 의해 설정되든 환경 변수에 의해 설정되든 관계없이)은 버퍼 풀, SQLPAL, SQL Server 에이전트, LibOS, PolyBase, Full-Text Search 및 기타 SQL Server on Linux에 로드된 프로세스를 포함한 모든 구성 요소에 대해 SQL Server on Linux에서 할당할 수 있는 총 메모리를 제어합니다.환경 변수는
MSSQL_MEMORY_LIMIT_MB에 정의된memorylimitmb값보다mssql.conf우선합니다.memorylimitmb는 호스트 시스템의 실제 실제 메모리를 초과할 수 없습니다.호스트 시스템 메모리 및
memorylimitmb제한(있는 경우)보다 낮게 설정cgroup하여 Linux 운영 체제에 충분한 실제 메모리가 있는지 확인합니다. 명시적으로 설정memorylimitmb하지 않으면 SQL Server 총 시스템 메모리와cgroup제한(있는 경우) 사이의 작은 값의 80%를 사용합니다.max_server_memory 서버 구성 옵션은 SQL Server 버퍼 풀의 크기만 제한하며 Sql Server on Linux의 전체 메모리 사용량을 제어하지 않습니다. 이전 글머리 기호에 설명된 다른 구성 요소에 충분한 메모리가 남아 있는지 확인하려면 항상 이 값을 보다
memorylimitmb낮게 설정합니다.
SQL Server와 컨테이너 메모리 제한 사이의 여유 공간
컨테이너에서 SQL Server를 설정된 메모리 제한(예: cgroup 설정 memory.max)과 함께 실행하는 경우, memory.memorylimitmb와 컨테이너 메모리 제한 사이에 여유 공간을 유지하세요. 이 헤드룸은 컨테이너 내부의 운영 체제 오버헤드 및 보조 프로세스를 제공합니다.
대부분의 배포의 경우 운영 체제 및 비 SQL Server 프로세스에 대해 컨테이너 메모리의 10~20%를 예약하고 나머지 용량 아래로 설정합니다
memory.memorylimitmb.대용량 메모리 구성의 경우 백분율 기반 버퍼는 필요한 것보다 더 많은 메모리를 예약할 수 있습니다. 예를 들어 256GB 컨테이너의 10%는 약 25GB이며 운영 체제 오버헤드에 적합합니다. 그러나 512GB 컨테이너의 10%는 약 51GB이며 운영 체제에 필요한 것보다 많을 수 있습니다. 이러한 경우 고정 버퍼를 대신 사용하고 워크로드 및 운영 체제 오버헤드에 적절하게 크기를 조정하고 나머지는 SQL Server 할당합니다.
워크로드 특성, 컨테이너에서 실행되는 다른 서비스 및 호스트 구성에 따라 버퍼를 조정합니다.
메모
모든 환경에는 권장되는 단일 헤드룸 값이 적용되지 않습니다. 테스트를 통해 메모리 설정의 유효성을 검사하여 최대 부하에서 시스템 안정성을 보장합니다.
사용 가능한 메모리보다 높은 메모리 제한을 구성하지 않습니다.
호스트에서 사용 가능한 실제 메모리보다 높거나 컨테이너 적용 메모리 제한보다 높게 구성 memory.memorylimitmb 하지 마세요. 이 경우 SQL Server 적극적으로 메모리를 소비하여 운영 체제 및 지원 프로세스에 대한 용량이 부족할 수 있습니다. 이 구성으로 인해 다음이 발생할 수 있습니다.
- 메모리 압력이 증가했습니다.
- 시스템 안정성 감소 및 예기치 않은 서비스 중단
- 메모리 부족(OOM) 상태로 인해 운영 체제가
sqlservr프로세스를 종료함.
호스트 또는 컨테이너에서 사용할 수 있는 유효 메모리 아래에 SQL Server 메모리 제한을 구성하고 운영 체제 및 런타임 서비스에 적절한 버퍼 공간을 남겨 둡니다.
Docker 메모리 구성 예제
이 docker run --memory 옵션은 컨테이너의 cgroup 메모리 제한을 설정합니다. 이 제한은 컨테이너의 모든 프로세스에 대해 커널 적용 하드 한도입니다.
MSSQL_MEMORY_LIMIT_MB(또는memory.memorylimitmb) 는 SQL Server 사용할 수 있는 메모리의 양을 제어합니다.
이전 지침에 설명된 대로 운영 체제와 보조 프로세스를 위한 여유 공간을 확보하려면 항상 MSSQL_MEMORY_LIMIT_MB를 컨테이너 메모리 제한보다 낮게 설정합니다.
다음 예제에서는 16GB RAM이 있는 호스트를 사용합니다. 환경에 맞게 값을 조정하세요.
권장되지 않음: 컨테이너 메모리 제한 없음
docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" \
-e "MSSQL_MEMORY_LIMIT_MB=14336" \
-p 1433:1433 \
-d mcr.microsoft.com/mssql/server:2022-latest
--memory이 없으면 컨테이너에는 cgroup 상한이 없습니다.
MSSQL_MEMORY_LIMIT_MB는 SQL Server 제한하지만 컨테이너 내의 다른 프로세스는 여전히 바인딩되지 않은 호스트 메모리를 사용할 수 있습니다.
권장되지 않음: 메모리 제한은 SQL Server 메모리 제한과 같습니다.
docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" \
-e "MSSQL_MEMORY_LIMIT_MB=12288" \
--memory 12g \
-p 1433:1433 \
-d mcr.microsoft.com/mssql/server:2022-latest
두 제한 모두 12GB(--memory 12g = 12,288MB)로 설정됩니다. 운영 체제 오버헤드나 보조 프로세스에 사용할 여유 공간이 남아 있지 않아 OOM 종료가 발생할 수 있습니다.
권장되지 않음: SQL Server 메모리 제한이 컨테이너 제한을 초과함
docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" \
-e "MSSQL_MEMORY_LIMIT_MB=14336" \
--memory 12g \
-p 1433:1433 \
-d mcr.microsoft.com/mssql/server:2022-latest
MSSQL_MEMORY_LIMIT_MB (14GB)가 컨테이너 제한(12GB)을 초과합니다. 이 시나리오는 사용 가능한 메모리보다 높은 메모리 제한 구성 방지에 설명된 OOM 조건으로 이어집니다.
권장: 운영 체제를 위한 여유를 둔 컨테이너 한도
docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" \
-e "MSSQL_MEMORY_LIMIT_MB=10240" \
--memory 12g \
-p 1433:1433 \
-d mcr.microsoft.com/mssql/server:2022-latest
컨테이너는 12GB(--memory 12g)로 제한되며 SQL Server 최대 10GB(MSSQL_MEMORY_LIMIT_MB=10240)를 사용하도록 구성됩니다. 나머지 2GB(약 17%)는 운영 체제 및 기타 프로세스를 위한 헤드룸을 제공합니다.
스왑 공간 고려 사항
컨테이너에서 SQL Server 실행하는 경우 호스트 수준에서 스왑 공간을 사용하도록 설정하여 운영 체제 및 비 SQL Server 프로세스를 보호합니다. 그러나 구성된 메모리 제한 내에서 작동하도록 SQL Server 구성하고 정상 작업 중에 교환을 사용하지 않습니다.
메모리 제한 지침에 따라 SQL Server 실제 메모리 또는 해당
cgroup메모리 제한 내에서 작동하는지 확인합니다.스왑을 사용하는 경우 안정적인 상태 SQL Server 워크로드의 용량이 아니라 호스트의 일시적인 메모리 압력을 위한 안전망으로 처리합니다.
Important
메모리 압력으로 인해 교환이 발생하는 경우 SQL Server 성능이 크게 저하됩니다. 적절한 메모리 크기 조정은 메모리 관련 오류를 방지하기 위한 기본 메커니즘입니다.