SQL Server on Linux의 성능 모범 사례 및 구성 지침

적용 대상:SQL Server on Linux

이 문서에서는 SQL Server on Linux에 연결하는 데이터베이스 애플리케이션의 성능을 최대화하기 위한 모범 사례 및 권장 사항을 제공합니다. 이 권장 사항은 Linux 플랫폼에서 실행하는 경우에 해당됩니다. 인덱스 디자인과 같은 일반적인 SQL Server 권장 사항은 모두 그대로 적용됩니다.

다음 지침에는 SQL Server 및 Linux OS(운영 체제)를 구성하기 위한 권장 사항이 포함되어 있습니다. SQL Server 설치 시 성능을 최대화하려면 이러한 구성 설정을 사용하는 것이 좋습니다.

• 스토리지 구성 권장 사항
• 고성능을 위한 커널 및 CPU 설정
• SQL Server 구성

스토리지 구성 권장 사항

데이터, 트랜잭션 로그 및 기타 관련 파일(예: 메모리 내 OLTP에 대한 검사점 파일)을 호스팅하는 스토리지 하위 시스템은 평균 워크로드와 최대 워크로드를 모두 정상적으로 관리할 수 있어야 합니다.

IOPS, 처리량, 중복도가 적절한 스토리지 하위 시스템 사용

온-프레미스 환경에서 스토리지 공급업체는 일반적으로 적절한 IOPS, 처리량 및 중복성을 보장하기 위해 여러 디스크에서 스트라이프를 사용하여 적절한 하드웨어 RAID 구성을 지원합니다. 그러나 이 지원은 다양한 아키텍처를 사용하는 여러 스토리지 공급업체 및 다른 스토리지 제품 간에 다를 수 있습니다.

Azure Virtual Machines에 배포된 Linux의 SQL Server의 경우 소프트웨어 RAID를 사용하여 적절한 IOPS 및 처리량 요구 사항을 보장하는 것이 좋습니다. 비슷한 스토리지 고려 사항을 사용하여 Azure 가상 머신에서 SQL Server를 구성하는 경우 Azure VM에서 SQL Server에 대한 스토리지 구성을 참조 하세요.

다음 예제에서는 Azure Virtual Machine의 Linux에서 소프트웨어 RAID를 만드는 방법을 보여 줍니다. 데이터, 트랜잭션 로그, tempdb I/O 요구 사항에 따라 볼륨에 필요한 처리량 및 IOPS에 적합한 수의 데이터 디스크를 사용해야 합니다. 다음 예제에서는 8개의 데이터 디스크가 VM에 연결되었습니다. 4개는 데이터 파일을 호스트하고, 2개는 트랜잭션 로그에, 2개는 워크로드용으로 tempdb 호스트합니다.

RAID를 만들기 위한 디바이스(예: /dev/sdc)를 찾으려면 lsblk 명령을 사용합니다.

# For Data volume, using 4 devices, in RAID 5 configuration with 8KB stripes
mdadm --create --verbose /dev/md0 --level=raid5 --chunk=8K --raid-devices=4 /dev/sdc /dev/sdd /dev/sde /dev/sdf

# For Log volume, using 2 devices in RAID 10 configuration with 64KB stripes
mdadm --create --verbose /dev/md1 --level=raid10 --chunk=64K --raid-devices=2 /dev/sdg /dev/sdh

# For tempdb volume, using 2 devices in RAID 0 configuration with 64KB stripes
mdadm --create --verbose /dev/md2 --level=raid0 --chunk=64K --raid-devices=2 /dev/sdi /dev/sdj

디스크 분할 및 구성 권장 사항

SQL Server의 경우 RAID 구성을 사용합니다. 배포된 파일 시스템 스트라이프 단위(sunit) 및 스트라이프 너비는 RAID 기하 도형과 일치합니다. 예를 들어 다음 예제에서는 로그 볼륨에 대한 XFS 기반 구성을 보여 줍니다.

# Creating a log volume, using 6 devices, in RAID 10 configuration with 64KB stripes
mdadm --create --verbose /dev/md3 --level=raid10 --chunk=64K --raid-devices=6 /dev/sda /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf

mkfs.xfs /dev/md3 -f -L log
meta-data=/dev/md3               isize=512    agcount=32, agsize=18287648 blks
         =                       sectsz=4096  attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1
data     =                       bsize=4096   blocks=585204384, imaxpct=5
         =                       sunit=16     swidth=48 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=285744, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

로그 배열은 64KB 스트라이프가 있는 6 드라이브 RAID-10입니다. 보시다시피:

• sunit=16 blks의 경우 16 * 4096 블록 크기 = 64KB는 스트라이프 크기와 일치합니다.
• swidth=48 blks의 경우 swidth / sunit = 3은 패리티 드라이브를 제외한 배열 내 데이터 드라이브 수입니다.

권장되는 파일 시스템 구성

SQL Server는 데이터베이스, 트랜잭션 로그 및 SQL Server의 메모리 내 OLTP에 대한 검사점 파일과 같은 기타 파일을 호스트하는 ext4 및 XFS 파일 시스템을 모두 지원합니다. SQL Server 데이터 및 트랜잭션 로그 파일을 호스팅하는 데 XFS 파일 시스템을 사용합니다.

XFS 파일 시스템을 사용하여 볼륨 포맷:

mkfs.xfs /dev/md0 -f -L datavolume
mkfs.xfs /dev/md1 -f -L logvolume
mkfs.xfs /dev/md2 -f -L tempdb

XFS 볼륨을 만들고 서식을 지정할 때 대/소문자를 구분하지 않는 XFS 파일 시스템을 구성할 수 있습니다. 이 구성은 Linux 에코시스템에서 자주 사용되지 않지만 호환성을 위해 사용할 수 있습니다.

예를 들어 다음 명령을 실행할 수 있습니다. 대/소문자를 구분하지 않는 XFS 파일 시스템을 구성하는 데 사용합니다 -n version=ci .

mkfs.xfs /dev/md0 -f -n version=ci -L datavolume

영구 메모리 파일 시스템 권장 사항

영구 메모리 디바이스의 파일 시스템 구성의 경우 기본 파일 시스템에 대한 블록 할당을 2MB로 설정합니다. 자세한 내용은 기술 고려 사항을 참조하세요.

파일 열기 제한 사항

프로덕션 환경에는 기본 파일 열기 제한인 1,024보다 더 많은 연결이 필요할 수 있습니다. 소프트 및 하드 제한을 1,048,576으로 설정할 수 있습니다. 예를 들어 RHEL에서 다음 값을 사용하도록 /etc/security/limits.d/99-mssql-server.conf 파일을 편집합니다.

mssql - nofile 1048576

참고

이 설정은 systemd에서 시작한 SQL Server 서비스에는 적용되지 않습니다. 자세한 내용은 RHEL 및 systemd에서 서비스에 대한 제한을 설정하는 방법을 참조하세요.

SQL Server 데이터 및 로그 파일에 대해 파일 시스템에 마지막으로 액세스한 날짜 및 시간 사용 안 함

시스템에 연결된 드라이브가 다시 시작 후 자동으로 재탑재되도록 하려면 /etc/fstab 파일에 추가하세요. 디바이스 이름(예: /etc/fstab)이 아닌 UUID(유니버설 고유 식별자/dev/sdc1)를 사용하여 드라이브를 참조합니다.

SQL Server 데이터 및 로그 파일을 저장하는 모든 파일 시스템에 noatime 특성을 사용합니다. 이 특성을 설정하는 방법은 해당 Linux 설명서를 참조하세요. 다음 예제에서는 Azure Virtual Machine에 noatime 탑재된 볼륨에 대한 옵션을 사용하도록 설정하는 방법을 보여 줍니다.

/etc/fstab의 마운트 지점 항목:

UUID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" /data1 xfs rw,attr2,noatime 0 0

이전 예시에서 UUID는 blkid 명령을 사용하여 찾을 수 있는 디바이스를 나타냅니다.

SQL Server 및 FUA(Forced Unit Access) I/O 하위 시스템 기능

특정 버전의 지원되는 Linux 배포에서는 FUA I/O 하위 시스템 기능을 지원하여 데이터 내구성을 제공합니다. SQL Server는 FUA 기능을 사용하여 SQL Server 워크로드에 대한 매우 효율적이고 안정적인 I/O를 제공합니다. Linux 배포의 FUA 지원과 SQL Server에 미치는 영향에 대한 자세한 내용은 SQL Server On Linux: FUA(강제 단위 액세스) 내부 항목을 참조하세요.

SUSE Linux Enterprise Server 12 SP5, Red Hat Enterprise Linux 8.0 및 Ubuntu 18.04는 I/O 하위 시스템에서 FUA 기능을 지원합니다. SQL Server 2017(14.x) CU 6 이상 버전을 사용하고 있는 경우 SQL Server에서 FUA를 사용하여 성능이 뛰어나고 효율적인 I/O를 구현하려면 다음 구성을 사용해야 합니다.

다음 조건이 충족되는 경우 권장 구성을 사용합니다.

• SQL Server 2017 (14.x) CU 6 이상 버전

• FUA 기능을 지원하는 Linux 배포 및 버전(Red Hat Enterprise Linux 8.0, SUSE Linux Enterprise Server 12 SP5 또는 Ubuntu 18.04부터 시작)

• Linux 커널 4.18 이상 버전의 SQL Server 스토리지용 XFS 파일 시스템입니다.

• Linux 커널 5.6 이상 버전의 SQL Server 스토리지용 ext4 파일 시스템입니다.

  참고

  Linux 커널 버전이 5.6보다 낮은 경우 SQL Server 데이터 및 트랜잭션 로그 파일을 호스팅하는 데 XFS 파일 시스템을 사용해야 합니다. 커널 버전 5.6부터 특정 요구 사항에 따라 XFS 와 ext4 중에서 선택할 수 있습니다.

• FUA 기능을 지원하고 이 기능용으로 구성된 스토리지 하위 시스템 및/또는 하드웨어

권장 구성:

1. 추적 플래그 3979를 시작 매개 변수로 사용하도록 설정합니다.

2. mssql-conf를 사용하여 control.writethrough = 1 및 control.alternatewritethrough = 0 구성.

위의 조건을 충족하지 않는 거의 모든 다른 구성에서 권장되는 구성은 다음과 같습니다.

1. 추적 플래그 3982를 시작 매개 변수(Linux 에코시스템에서 SQL Server의 기본값)로 사용하도록 설정하고 추적 플래그 3979가 시작 매개 변수로 사용하도록 설정되지 않았는지 확인합니다.

2. mssql-conf를 사용하여 control.writethrough = 1 및 control.alternatewritethrough = 1 구성.

Kubernetes에 배포된 SQL Server 컨테이너에 대한 FUA 지원

1. SQL Server는 overlayfs가 아닌 지속형 탑재 스토리지를 사용해야 합니다.

2. 스토리지는 XFS 또는 ext4 파일 시스템을 사용해야 하며 FUA를 지원해야 합니다(ext4 는 버전 5.6 이전의 Linux 커널에서 FUA를 지원하지 않음). 이 설정을 사용하도록 설정하기 전에 Linux 배포 및 스토리지 공급업체와 협력하여 OS 및 스토리지 하위 시스템이 FUA 옵션을 지원하는지 확인해야 합니다. Kubernetes에서 다음 명령을 사용하여 파일 시스템 형식을 쿼리할 수 있습니다. 여기서 <pvc-name> 는 다음과 PersistentVolumeClaim같습니다.

   kubectl describe pv <pvc-name>
   

   출력에서 XFS로 설정된 fstype를 찾습니다.

3. SQL Server Pod를 호스팅하는 작업자 노드는 FUA 기능을 지원하는 Linux 배포 및 버전을 사용해야 합니다(Red Hat Enterprise Linux 8.0, SUSE Linux Enterprise Server 12 SP5 또는 Ubuntu 18.04부터 시작).

위의 조건이 충족되면 다음 권장 FUA 설정을 사용할 수 있습니다.

1. 추적 플래그 3979를 시작 매개 변수로 사용하도록 설정합니다.

2. mssql-conf를 사용하여 control.writethrough = 1 및 control.alternatewritethrough = 0 구성.

고성능을 위한 커널 및 CPU 설정

다음 섹션에서는 SQL Server 설치의 고성능 및 처리량과 관련하여 권장되는 Linux OS 설정에 대해 설명합니다. 이 설정을 구성하는 프로세스는 Linux 배포판 설명서를 참조하세요. 설명된 대로 TuneD를 사용하여 다음 섹션에 설명된 많은 CPU 및 커널 구성을 구성할 수 있습니다.

TuneD를 사용하여 커널 설정 구성

RHEL(Red Hat Enterprise Linux) 사용자의 경우 TuneD 처리량 성능 프로필은 일부 커널 및 CPU 설정(C-States 제외)을 자동으로 구성합니다. RHEL 8.0부터 mssql이라는 TuneD 프로필이 Red Hat과 공동으로 개발되었으며, SQL Server 워크로드에 대해 더욱 정교한 Linux 성능 관련 튜닝을 제공합니다. 이 프로필은 RHEL 처리량-성능 프로필을 포함하므로 Microsoft는 이 프로필 없이 다른 Linux 배포판 및 RHEL 릴리스와 함께 검토할 수 있도록 이 문서에 해당 정의를 제공합니다.

SUSE Linux Enterprise Server 12 SP5, Ubuntu 18.04 및 Red Hat Enterprise Linux 7.x의 경우 패키지를 수동으로 설치할 tuned 수 있습니다. 다음 섹션에 설명된 대로 mssql을(를) 사용하여 프로필을 만들고 구성하십시오.

TuneD mssql 프로필을 사용하는 권장 Linux 설정

다음 예시에서는 SQL Server on Linux에 대한 TuneD 구성을 제공합니다.

[main]
summary=Optimize for Microsoft SQL Server
include=throughput-performance

[cpu]
force_latency=5

[sysctl]
vm.swappiness = 1
vm.dirty_background_ratio = 3
vm.dirty_ratio = 80
vm.dirty_expire_centisecs = 500
vm.dirty_writeback_centisecs = 100
vm.transparent_hugepages=always
# For multi-instance SQL deployments, use
# vm.transparent_hugepages=madvise
vm.max_map_count=1600000
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048576
kernel.numa_balancing=0

커널 버전이 4.18보다 큰 Linux 배포를 사용하는 경우 표시된 대로 다음 옵션을 주석으로 처리합니다. 그렇지 않으면 4.18 이전의 커널 버전에서 배포를 사용하는 경우 다음 옵션의 주석 처리를 제거합니다.

# kernel.sched_latency_ns = 60000000
# kernel.sched_migration_cost_ns = 500000
# kernel.sched_min_granularity_ns = 15000000
# kernel.sched_wakeup_granularity_ns = 2000000

이 TuneD 프로필을 사용하려면 tuned.conf 폴더 아래의 /usr/lib/tuned/mssql 파일에 이러한 정의를 저장하고 다음 명령을 사용하여 프로필을 사용하도록 설정합니다.

chmod +x /usr/lib/tuned/mssql/tuned.conf
tuned-adm profile mssql

다음 명령을 사용하여 프로필이 활성 상태인지 확인합니다.

tuned-adm active

또는

tuned-adm list

CPU 설정 권장 사항

다음 표에서는 CPU 설정 권장 사항을 제공합니다.

설정	값	자세한 정보
CPU frequency governor(주파수 조절기)	성능	cpupower 명령을 참조하세요.
에너지 성능 편향	성능	x86_energy_perf_policy 명령을 참조하세요.
최소_성능_백분율 (min_perf_pct)	100	Intel p-state에 관한 사용자 설명서를 참조하십시오.
C-States	C1만	C-States가 C1 only로 설정되었는지 확인하는 방법은 해당 Linux 또는 시스템 설명서를 참조하세요.

설명된 대로 TuneD를 사용하면 CPU 주파수 관리자 ENERGY_PERF_BIAS및 min_perf_pct 설정이 자동으로 구성됩니다. 처리량 성능 프로필을 mssql 프로필의 기반으로 사용합니다. Linux 또는 시스템 배포자에서 제공하는 설명서에 따라 C-States 매개 변수를 수동으로 구성해야 합니다.

디스크 설정 권장 사항

다음 표에서는 디스크 설정 권장 사항을 제공합니다.

설정	값	자세한 정보
디스크 readahead	4096	blockdev 명령을 참조하세요.
sysctl 설정	kernel.sched_min_granularity_ns = 15000000 kernel.sched_wakeup_granularity_ns = 2000000 vm.dirty_ratio = 80 vm.dirty_background_ratio = 3 vm.swappiness = 1	sysctl 명령을 참조하세요.

설명

• vm.swappiness: 이 매개 변수는 파일 시스템 캐시에 비해 런타임 프로세스 메모리를 교환하는 데 지정된 상대적 가중치를 제어합니다. 이 매개 변수의 기본값은 60이며, 이는 60:140의 비율로 파일 시스템 캐시 페이지를 제거하는 것과 비교하여 런타임 프로세스 메모리 페이지를 교환하는 것을 나타냅니다. 값을 1로 설정하면 파일 시스템 캐시를 희생하면서 런타임 프로세스 메모리를 실제 메모리에 유지하는 것이 좋습니다. SQL Server는 버퍼 풀을 데이터 페이지 캐시로 사용하고 신뢰할 수 있는 복구를 위해 파일 시스템 캐시를 우회하는 물리적 하드웨어를 통해 쓰는 것을 선호하므로 적극적인 스와핑 구성은 고성능 전용 SQL Server에 도움이 될 수 있습니다.

  /proc/sys/vm/ 설명서 - #swappiness에서 추가 정보를 확인할 수 있습니다.

• vm.dirty_*: SQL Server 파일 쓰기 액세스가 캐시되지 않아 데이터 무결성 요구 사항을 충족합니다. 이러한 매개 변수는 효율적인 비동기 쓰기 성능을 허용하며, 플러시를 제한하면서 충분히 큰 캐싱을 허용하여 Linux 캐싱 쓰기의 스토리지 I/O 효과를 낮춥니다.

• kernel.sched_*: 이러한 매개 변수 값은 Linux 커널에서 CFS(완전 공정 예약) 알고리즘을 조정하기 위한 현재 권장 사항을 나타냅니다. 스레드의 프로세스 간 선점 및 재개와 관련하여 네트워크 및 스토리지 I/O 호출의 처리량을 향상시킵니다.

mssql TuneD 프로필을 사용하면 vm.swappiness, vm.dirty_*, kernel.sched_* 설정이 구성됩니다. 각 디바이스에서 readahead 명령을 사용하여 blockdev 디스크 설정을 수동으로 구성해야 합니다.

다중 노드 NUMA 시스템을 위한 커널 설정 자동 NUMA 균형 조정

다중 노드 NUMA 시스템에 SQL Server를 설치하는 경우 기본적으로 다음 kernel.numa_balancing 커널 설정이 사용하도록 설정됩니다. SQL Server가 NUMA 시스템에서 최대 효율성으로 작동할 수 있도록 하려면 다중 노드 NUMA 시스템에서 자동 NUMA 분산을 사용하지 않도록 설정합니다.

sysctl -w kernel.numa_balancing=0

mssql TuneD 프로필을 사용하면 kernel.numa_balancing 옵션이 구성됩니다.

가상 주소 공간의 커널 설정

vm.max_map_count의 기본 설정(65536)이 SQL Server 설치에 충분히 높지 않을 수 있습니다. 이런 이유로, SQL Server 배포의 경우 vm.max_map_count 값을 262144 이상으로 변경합니다. 커널 매개 변수의 추가 튜닝에 대해서는 TuneD mssql 프로필을 사용하는 권장 Linux 설정 섹션을 참조하세요. vm.max_map_count의 최대값은 2147483647입니다.

sysctl -w vm.max_map_count=1600000

mssql TuneD 프로필을 사용하면 vm.max_map_count 옵션이 구성됩니다.

THP(Transparent Huge Pages)를 사용 상태로 유지

대부분의 Linux 설치에는 기본적으로 이 옵션이 있습니다. 가장 일관된 성능 환경을 위해 이 구성 옵션을 사용하도록 설정합니다. 그러나 여러 인스턴스가 있는 SQL Server 배포에서 메모리 페이징 작업이 많거나 서버에서 다른 메모리가 까다로운 애플리케이션과 함께 SQL Server를 실행하는 경우 다음 명령을 실행한 후 애플리케이션의 성능을 테스트합니다.

echo madvise > /sys/kernel/mm/transparent_hugepage/enabled

또는 다음 줄을 사용하여 mssql TuneD 프로필을 수정합니다.

vm.transparent_hugepages=madvise

그리고 수정 후 mssql 프로필이 활성 상태인지 확인합니다.

tuned-adm off
tuned-adm profile mssql

mssql TuneD 프로필을 사용하면 transparent_hugepage 옵션이 구성됩니다.

네트워크 설정 권장 사항

스토리지 및 CPU 권장 사항과 함께 네트워크 관련 권장 사항도 있습니다. 참조를 위해 나열된 권장 사항은 다음과 같습니다. 다음 예시의 모든 설정을 여러 NIC에서 사용할 수 있는 것은 아닙니다. 각 옵션에 대한 지침은 NIC 공급업체에 문의하세요. 프로덕션 환경에 적용하기 전에 개발 환경에서 테스트하고 구성합니다. 다음 옵션은 예시를 통해 설명되며, 사용되는 명령은 NIC 유형 및 공급업체에 따라 다릅니다.

1. 네트워크 포트 버퍼 크기 구성. 이 예제에서 NIC의 이름은 eth0Intel 기반 NIC입니다. Intel 기반 NIC에 권장되는 버퍼 크기는 4KB(4096)입니다. 미리 설정된 최대값을 확인한 후 다음 예시를 사용하여 구성합니다.

   다음 명령을 사용하여 미리 설정된 최대값을 확인합니다. eth0을 NIC 이름으로 바꾸세요.

   ethtool -g eth0
   

   rx(수신) 및 tx(전송) 버퍼 크기를 모두 4KB로 설정합니다.

   ethtool -G eth0 rx 4096 tx 4096
   

   값이 올바르게 구성되었는지 확인합니다.

   ethtool -g eth0
   

2. 점보 프레임을 사용하도록 설정합니다. 점보 프레임을 사용하도록 설정하기 전에 모든 네트워크 스위치, 라우터, 클라이언트와 SQL Server 간의 네트워크 패킷 경로에 있는 기타 모든 필수 항목이 점보 프레임을 지원하는지 확인합니다. 그런 다음 점보 프레임을 사용하도록 설정하면 성능이 향상됩니다. 점보 프레임을 사용하도록 설정한 후 다음 예제와 같이 SQL Server에 연결하고 네트워크 패킷 크기를 8060 sp_configure으로 변경합니다.

   # command to set jumbo frame to 9014 for a Intel NIC named eth0 is
   ifconfig eth0 mtu 9014
   # verify the setting using the command:
   ip addr | grep 9014
   

   EXECUTE sp_configure 'network packet size', '8060';
   GO
   
   RECONFIGURE WITH OVERRIDE;
   GO
   

3. 기본적으로 적응형 RX/TX IRQ 병합에 대한 포트를 설정합니다. 즉, 패킷 속도가 낮을 때 대기 시간을 개선하고 패킷 속도가 높을 때 처리량을 향상시키기 위해 인터럽트 배달이 조정됩니다. 이 설정은 네트워크 인프라에서 사용할 수 없으므로 기존 네트워크 인프라를 검토하고 이 설정이 지원되는지 확인합니다. eth0라는 Intel 기반 NIC에 대한 예제입니다.

   1. 적응형 RX/TX IRQ 통합을 위한 포트 설정:

      ethtool -C eth0 adaptive-rx on
      ethtool -C eth0 adaptive-tx on
      

   2. 설정 확인:

      ethtool -c eth0
      

   참고

   벤치마킹 환경과 같은 고성능 환경에서 예측 가능한 동작의 경우 적응형 RX/TX IRQ 병합을 사용하지 않도록 설정한 다음 RX/TX 인터럽트 병합을 구체적으로 설정합니다. RX/TX IRQ 병합을 사용하지 않도록 설정하고 값을 구체적으로 설정하는 예제 명령을 참조하세요.

   적응형 RX/TX IRQ 병합 기능 해제:

   ethtool -C eth0 adaptive-rx off
   ethtool -C eth0 adaptive-tx off
   

   변경을 확인합니다.

   ethtool -c eth0
   

   rx-usecs 및 irq 매개 변수를 설정합니다. rx-usecs 는 인터럽트를 생성하기 전에 하나 이상의 패킷이 수신된 후 마이크로초 수를 지정합니다. irq 매개 변수는 인터럽트 비활성화 시 상태 업데이트의 해당 지연을 지정합니다. Intel 기반 NIC의 경우 다음 설정을 사용할 수 있습니다.

   ethtool -C eth0 rx-usecs 100 tx-frames-irq 512
   

   변경을 확인합니다.

   ethtool -c eth0
   

4. RSS(수신측 크기 조정)를 사용하도록 설정하고 기본적으로 RSS 큐의 RX 및 TX 쪽을 결합합니다. Microsoft 지원과 협력하는 특정 시나리오에서 RSS를 사용하지 않도록 설정하면 성능이 향상되기도 합니다. 프로덕션 환경에 적용하기 전에 테스트 환경에서 이 설정을 테스트합니다. 다음 예시는 Intel NIC용입니다.

   미리 설정된 최대값 가져오기:

   ethtool -l eth0
   

   미리 설정된 '결합된' 최대값에 보고된 값을 사용하여 큐를 결합합니다. 이 예시에서는 값이 8로 설정됨:

   ethtool -L eth0 combined 8
   

   설정 확인:

   ethtool -l eth0
   

5. NIC 포트 IRQ 선호도를 사용합니다. IRQ 선호도를 조정하여 예상 성능을 달성하려면 서버 토폴로지, NIC 드라이버 스택, 기본 설정 및 설정의 Linux 처리와 irqbalance 같은 몇 가지 중요한 매개 변수를 고려합니다. NIC 포트의 IRQ affinity 설정 최적화는 서버의 토폴로지에 대한 이해를 바탕으로 이루어지며, irqbalance을 비활성화한 후, NIC 공급업체별 설정을 사용하여 수행됩니다.

   Mellanox 특정 네트워크 인프라의 다음 예시는 구성을 설명하는 데 도움이 됩니다. 자세한 내용을 확인하고 Mellanox mlnx를 다운로드하려면 Mellanox 네트워크 어댑터용 성능 튜닝 도구를 참조하세요. 명령은 환경에 따라 변경됩니다. 추가 지침은 NIC 공급업체에 문의하세요.

   irqbalance를 사용하지 않도록 설정하거나, IRQ 설정의 스냅샷을 얻고 디먼을 강제로 종료합니다.

   systemctl disable irqbalance.service
   

   또는

   irqbalance --oneshot
   

   common_irq_affinity.sh가 실행 가능한지 확인합니다.

   chmod +x common_irq_affinity.sh
   

   Mellanox NIC 포트에 대한 IRQ 선호도 표시(예: eth0):

   ./show_irq_affinity.sh eth0
   

   Mellanox 도구를 사용하여 최상의 처리량 성능 최적화:

   ./mlnx_tune -p HIGH_THROUGHPUT
   

   NIC 및 해당 포트를 물리적으로 호스팅하는 NUMA 노드에 하드웨어 선호도 설정:

   ./set_irq_affinity_bynode.sh `\cat /sys/class/net/eth0/device/numa_node` eth0
   

   IRQ 선호도 확인:

   ./show_irq_affinity.sh eth0
   

   IRQ 병합 최적화 기능 추가

   ethtool -C eth0 adaptive-rx off
   ethtool -C eth0 adaptive-tx off
   ethtool -C eth0  rx-usecs 750 tx-frames-irq 2048
   

   설정을 확인합니다.

   ethtool -c eth0
   

6. 위의 변경 내용을 적용한 후 다음 명령을 사용하여 NIC의 속도를 확인하여 예상과 일치하는지 확인합니다.

   ethtool eth0 | grep -i Speed
   

고급 커널 및 OS 구성

• 최상의 스토리지 I/O 성능을 위해 블록 디바이스에 대해 Linux 다중 큐 예약을 사용합니다. 이 예약 방법을 사용하면 블록 계층 성능이 빠른 SSD(반도체 드라이브) 및 멀티 코어 시스템으로 잘 확장될 수 있습니다. 설명서를 확인하여 Linux 배포에서 기본적으로 사용하도록 설정하는지 확인합니다. 대부분의 경우 커널 scsi_mod.use_blk_mq=y 을 부팅하여 사용하도록 설정할 수 있습니다. Linux 배포에 대한 설명서에는 이 설정에 대한 추가 지침이 있을 수 있습니다. 이 설정은 업스트림 Linux 커널과 일치합니다.

• 다중 경로 I/O는 SQL Server 배포에 자주 사용되므로, blk-mq 커널 부팅 옵션을 활성화하여 dm_mod.use_blk_mq=y 인프라를 사용하도록 디바이스 매퍼(DM) 다중 큐 대상을 구성합니다. 기본값은 n(사용 안 함)입니다. 이 설정은 기본 SCSI 디바이스에서 사용할 blk-mq때 DM 계층의 잠금 오버헤드를 줄입니다. 다중 경로 I/O를 구성하는 방법에 대한 자세한 내용은 Linux 배포판의 설명서를 참조하세요.

스왑 파일 구성

메모리 부족 문제를 방지하려면 올바르게 구성된 swapfile이 있어야 합니다. swapfile을 만들고 올바른 크기를 지정하는 방법은 해당 Linux 설명서를 참조하세요.

가상 머신 및 동적 메모리

가상 머신에서 SQL Server on Linux를 실행하는 경우 가상 머신에 대해 예약된 메모리 크기를 수정하는 옵션을 선택해야 합니다. Hyper-V 동적 메모리와 같은 기능을 사용하지 않도록 합니다.

SQL Server 구성

애플리케이션에 최상의 성능을 얻으려면 Linux에 SQL Server를 설치한 후 다음 구성 작업을 수행합니다.

모범 사례

노드 및/또는 CPU에 대해 PROCESS AFFINITY 사용

Linux OS에서 SQL Server를 위해 사용하는 모든 노드 및 CPU를 설정하기 위해 ALTER SERVER CONFIGURATIONPROCESS AFFINITY를 사용합니다(일반적으로 모든 노드 및 CPU에 해당). 프로세서 선호도는 효율적인 Linux 및 SQL 예약 동작을 유지 관리하는 데 도움이 됩니다. NUMANODE 옵션을 사용하는 것이 가장 간단한 방법입니다. 컴퓨터에 NUMA 노드가 하나뿐인 경우에도 PROCESS AFFINITY를 사용합니다. PROCESS AFFINITY를 설정하는 방법에 대한 자세한 내용은 ALTER SERVER CONFIGURATION 문서를 참조하세요.

여러 tempdb 데이터 파일 구성

SQL Server on Linux 설치는 여러 tempdb 파일을 구성하는 옵션을 제공하지 않으므로 설치 후에 여러 tempdb 데이터 파일을 만드는 것이 좋습니다. 자세한 내용은 SQL Server tempdb 데이터베이스에서 할당 경합을 줄이기 위한 권장 사항 문서의 지침을 참조하세요.

고급 구성

다음 권장 사항은 SQL Server on Linux 설치 후에 수행할 수 있는 선택적 구성 설정입니다. 이러한 선택 사항은 Linux OS의 워크로드 및 구성 요구 사항에 따라 다릅니다.

mssql-conf를 사용하여 메모리 한도 설정

Linux 운영 체제에 대해 사용 가능한 실제 메모리가 충분한지 확인하기 위해 SQL Server 프로세스는 기본적으로 실제 RAM의 80%만 사용합니다. 실제 RAM이 많은 일부 시스템의 경우 20개의% 상당한 수일 수 있습니다.

예를 들어 RAM이 1TB인 시스템에서 기본 설정을 사용할 경우 약 200GB RAM이 사용되지 않는 상태로 유지됩니다. 이런 상황에서는 메모리 한도를 더 큰 값으로 구성하는 것이 좋습니다. mssql-conf 도구를 사용하여 이 값을 조정할 수 있습니다. 자세한 내용은 SQL Server에 표시되는 메모리를 제어하는 memory.memorylimitmb 설정을 참조하세요(MB 단위).

참고

환경 변수를 사용하여 MSSQL_MEMORY_LIMIT_MB 메모리 제한을 구성할 수도 있습니다. 이 메서드는 컨테이너를 배포하거나 SQL Server 컨테이너 또는 패키지 기반 배포를 자동화할 때 일반적으로 사용됩니다. 환경 변수가 MSSQL_MEMORY_LIMIT_MB 설정보다 우선합니다 memory.memorylimitmb .

이 설정을 변경하는 경우 값을 너무 높게 설정하지 않도록 주의합니다. 충분한 메모리를 유지하지 않으면 Linux OS와 기타 Linux 애플리케이션에서 문제가 발생할 수 있습니다.

제어 그룹(cgroup) v2를 사용하여 메모리 제한 구성

SQL Server 2025(17.x) 및 SQL Server 2022(16.x) CU 20부터 SQL Server는 제어 그룹(cgroup) v2 제약 조건을 검색하고 적용하여 Docker, Kubernetes 및 OpenShift 환경에서 성능 안정성 및 리소스 격리를 개선합니다. 제어 그룹을 사용하면 CPU 및 메모리와 같은 시스템 리소스를 통해 Linux 커널에서 세분화된 제어를 사용할 수 있습니다.

cgroup v2 지원을 통해 SQL Server는 컨테이너화된 배포에서 이전에 관찰된 OOM(메모리 부족) 오류를 완화합니다. 특히 컨테이너 사양에 정의된 메모리 제한이 적용되지 않은 Kubernetes 클러스터(예: AKS v1.25 이상)에서 발생합니다.

cgroup 버전 확인

stat -fc %T /sys/fs/cgroup

결과는 다음과 같습니다.

결과	설명
cgroup2fs	cgroup v2를 사용하고 있습니다.
cgroup	cgroup v1을 사용하고 있습니다.

cgroup v2로 전환

가장 쉬운 경로는 cgroup v2를 지원하는 배포를 선택하는 것입니다.

수동으로 전환해야 하는 경우 GRUB 구성에 다음 줄을 추가합니다.

systemd.unified_cgroup_hierarchy=1

그런 다음, 다음 명령을 실행하여 GRUB를 업데이트합니다.

sudo update-grub

자세한 내용은 다음 리소스를 참조하세요.

• 빠른 시작: Helm 차트를 사용하여 Kubernetes에 SQL Server Linux 컨테이너 배포
• Linux 커널 cgroup v2 설명서
• 제어 그룹 v2

메모리 제한 설정 지침

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 는 호스트 시스템의 실제 실제 메모리를 초과할 수 없습니다.

• 호스트 시스템 메모리 및 cgroup 제한(있는 경우)보다 낮게 설정 memorylimitmb 하여 Linux 운영 체제에 충분한 실제 메모리가 있는지 확인합니다. 명시적으로 memorylimitmb를 설정하지 않으면, SQL Server는 총 시스템 메모리와 cgroup 제한(있는 경우) 중 더 작은 값의 80%를 사용합니다.

• max_server_memory 서버 구성 옵션은 SQL Server 버퍼 풀의 크기만 제한하며 Sql Server on Linux의 전체 메모리 사용량을 제어하지 않습니다. SQLPAL, SQL Server 에이전트, LibOS, PolyBase, Full-Text Search 및 SQL Server on Linux에 로드된 다른 프로세스와 같은 다른 구성 요소에 대해 충분한 메모리가 유지되도록 항상 이 값을 보다 memorylimitmb 낮게 설정합니다.

관련 콘텐츠

• SQL Server on Linux의 성능 기능에 대한 연습
• Linux에서 SQL Server란?