SQL Server on Linux의 성능 모범 사례 및 구성 지침
적용 대상: 
SQL Server - Linux
이 문서에서는 SQL Server on Linux에 연결하는 데이터베이스 애플리케이션의 성능을 최대화하기 위한 모범 사례 및 권장 사항을 제공합니다. 이 권장 사항은 Linux 플랫폼에서 실행하는 경우에 해당됩니다. 인덱스 디자인과 같은 일반적인 SQL Server 권장 사항은 모두 그대로 적용됩니다.
다음 지침에는 SQL Server 및 Linux OS(운영 체제)를 구성하기 위한 권장 사항이 포함되어 있습니다. SQL Server 설치 시 성능을 최대화하려면 이러한 구성 설정을 사용하는 것이 좋습니다.
스토리지 구성 권장 사항
데이터, 트랜잭션 로그 및 기타 관련 파일(예: 메모리 내 OLTP에 대한 검사점 파일)을 호스팅하는 스토리지 하위 시스템은 평균 워크로드와 최대 워크로드를 모두 정상적으로 관리할 수 있어야 합니다.
IOPS, 처리량, 중복도가 적절한 스토리지 하위 시스템 사용
일반적으로 온-프레미스 환경에서 스토리지 공급업체는 여러 디스크에서 스트라이프하는 적절한 하드웨어 RAID 구성을 지원하여 적절한 IOPS, 처리량, 중복도를 보장합니다. 그러나 스토리지 공급업체와 다양한 아키텍처를 사용하는 스토리지 제품마다 다를 수 있습니다.
Azure Virtual Machine에 배포된 SQL Server on Linux의 경우 소프트웨어 RAID를 사용하여 적절한 IOPS 및 처리량 요구 사항이 충족되도록 하는 것이 좋습니다. 비슷한 스토리지 고려 사항을 사용하여 Azure 가상 머신에서 SQL Server를 구성하는 경우 Azure VM에서 SQL Server에 대한 스토리지 구성을 참조 하세요.
다음 예시에서는 Azure Virtual Machines의 Linux에서 소프트웨어 RAID를 만드는 방법을 보여줍니다. 데이터, 트랜잭션 로그, tempdb I/O 요구 사항에 따라 볼륨에 필요한 처리량 및 IOPS에 적합한 수의 데이터 디스크를 사용해야 합니다. 다음 예시에서는 8개의 데이터 디스크가 Azure 가상 머신에 연결되었습니다. 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 에코시스템에서 자주 사용되는 구성은 아니지만 호환성을 위해 사용할 수는 있습니다.
예를 들어 다음 명령을 실행할 수 있습니다. -n version=ci는 대/소문자를 구분하지 않는 XFS 파일 시스템을 구성하는 데 사용됩니다.
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)만 사용하는 것이 아니라 /dev/sdc1의 UUID(Universally Unique Identifier)를 같이 사용하여 드라이브를 참조해야 합니다.
SQL Server 데이터 및 로그 파일을 저장하는 모든 파일 시스템에 noatime 특성을 사용합니다. 이 특성을 설정하는 방법은 해당 Linux 설명서를 참조하세요. Azure 가상 머신에 탑재된 볼륨에 대해 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부터 시작)
SQL Server 스토리지용 XFS 파일 시스템
FUA 기능을 지원하고 이 기능용으로 구성된 스토리지 하위 시스템 및/또는 하드웨어
권장 구성:
추적 플래그 3979를 시작 매개 변수로 사용.
mssql-conf를 사용하여
control.writethrough = 1및control.alternatewritethrough = 0구성.
위의 조건을 충족하지 않는 거의 모든 다른 구성에서 권장되는 구성은 다음과 같습니다.
추적 플래그 3982를 시작 매개 변수로 사용(Linux 에코시스템의 SQL Server인 경우 기본값)하여 추적 플래그 3979가 시작 매개 변수로 사용되지 않도록 합니다.
mssql-conf를 사용하여
control.writethrough = 1및control.alternatewritethrough = 1구성.
Kubernetes에 배포된 SQL Server 컨테이너에 대한 FUA 지원
SQL Server는
overlayfs가 아닌 지속형 탑재 스토리지를 사용해야 합니다.스토리지는 XFS 파일 시스템을 사용해야 하며 FUA를 지원해야 합니다. 이 설정을 사용하도록 설정하기 전에 Linux 배포 및 스토리지 공급업체와 협력하여 OS 및 스토리지 하위 시스템이 FUA 옵션을 지원하는지 확인해야 합니다. Kubernetes에서 다음 명령을 사용하여 파일 시스템 형식을 쿼리할 수 있습니다. 여기서
<pvc-name>는 다음과PersistentVolumeClaim같습니다.kubectl describe pv <pvc-name>출력에서 XFS로 설정된
fstype를 찾습니다.SQL Server Pod를 호스팅하는 작업자 노드는 FUA 기능을 지원하는 Linux 배포 및 버전을 사용해야 합니다(Red Hat Enterprise Linux 8.0, SUSE Linux Enterprise Server 12 SP5 또는 Ubuntu 18.04부터 시작).
위의 조건이 충족되면 다음 권장 FUA 설정을 사용할 수 있습니다.
추적 플래그 3979를 시작 매개 변수로 사용.
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 프로필을 사용하려면 /usr/lib/tuned/mssql 폴더 아래의 tuned.conf 파일에 이러한 정의를 저장하고 다음 명령을 사용하여 프로필을 사용하도록 설정합니다.
chmod +x /usr/lib/tuned/mssql/tuned.conf
tuned-adm profile mssql
다음 명령을 사용하여 프로필이 활성 상태인지 확인합니다.
tuned-adm active
또는
tuned-adm list
CPU 설정 권장 사항
다음 표에서는 CPU 설정 권장 사항을 제공합니다.
| 설정 | 값 | 자세한 정보 |
|---|---|---|
| CPU frequency governor | 성능 | cpupower 명령을 참조하세요. |
| ENERGY_PERF_BIAS | 성능 | x86_energy_perf_policy 명령을 참조하세요. |
| min_perf_pct | 100 | Intel p-state는 해당 설명서를 참조하세요. |
| C-States | C1 only | C-States가 C1 only로 설정되었는지 확인하는 방법은 해당 Linux 또는 시스템 설명서를 참조하세요. |
앞에서 설명한 대로 TuneD를 사용하면 mssql 프로필의 기반으로 사용되는 처리량-성능 프로필로 인해 CPU frequency governor, ENERGY_PERF_BIAS 및 min_perf_pct 설정이 적절하게 자동으로 구성됩니다. C-States 매개 변수는 Linux 또는 시스템 배포자가 제공한 설명서에 따라 수동으로 구성해야 합니다.
디스크 설정 권장 사항
다음 표에서는 디스크 설정 권장 사항을 제공합니다.
| 설정 | 값 | 자세한 정보 |
|---|---|---|
디스크 readahead |
4096 | blockdev 명령을 참조하세요. |
| sysctl 설정 | kernel.sched_min_granularity_ns = 15000000kernel.sched_wakeup_granularity_ns = 2000000vm.dirty_ratio = 80vm.dirty_background_ratio = 3vm.swappiness = 1 |
sysctl 명령을 참조하세요. |
설명
vm.swappiness: 이 매개 변수는 파일 시스템 캐시 대비 런타임 프로세스 메모리 교환에 지정되는 상대 가중치를 제어합니다. 이 매개 변수의 기본값은 60으로, 파일 시스템 캐시 페이지 제거 대비 런타임 프로세스 메모리 페이지 교환의 비율이 60:140임을 나타냅니다. 값 1을 설정하면 런타임 프로세스 메모리를 파일 시스템 캐시 대신 실제 메모리에 보관하는 것이 크게 선호됨을 나타냅니다. SQL Server는 버퍼 풀을 데이터 페이지 캐시로 사용하며 안정적인 복구를 위해 파일 시스템 캐시를 무시하고 실제 하드웨어에 쓰는 것을 크게 선호하므로 과감한 swappiness 구성은 고성능의 전용 SQL Server에 유용할 수 있습니다. /proc/sys/vm/ 설명서 - #swappiness에서 추가 정보를 확인할 수 있습니다.vm.dirty_*: SQL Server 파일 쓰기 액세스가 캐시되지 않아 데이터 무결성 요구 사항을 충족합니다. 이러한 매개 변수는 효율적인 비동기 쓰기 성능을 허용하며, 플러시를 제한하면서 충분히 큰 캐싱을 허용하여 Linux 캐싱 쓰기의 스토리지 I/O 효과를 낮춥니다.kernel.sched_*: 이러한 매개 변수 값은 Linux 커널의 CFS(Completely Fair Scheduling) 알고리즘 조정에 대한 현재 권장 사항을 나타내며, 프로세스 간 선점 및 스레드 다시 시작과 관련된 네트워크 처리량 및 스토리지 I/O 호출을 개선합니다.
mssql TuneD 프로필을 사용하면 vm.swappiness, vm.dirty_* 및 kernel.sched_* 설정이 구성됩니다. blockdev 명령을 사용하는 디스크 readahead 구성은 디바이스 단위이며 수동으로 수행해야 합니다.
다중 노드 NUMA 시스템의 커널 설정 auto NUMA balancing
다중 노드 NUMA 시스템에 SQL Server를 설치하면 다음 kernel.numa_balancing 커널 설정이 기본적으로 사용하도록 설정됩니다. SQL Server가 NUMA 시스템에서 최대한 효율적으로 작동할 수 있게 하려면 다중 노드 NUMA 시스템에서 auto NUMA balancing을 사용하지 않도록 설정합니다.
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 유형 및 공급업체에 따라 다릅니다.
네트워크 포트 버퍼 크기 구성. 아래 예시에서 NIC의 이름은 Intel 기반 NIC인
eth0입니다. Intel 기반 NIC에 권장되는 버퍼 크기는 4KB(4096)입니다. 미리 설정된 최대값을 확인한 후 다음 예시를 사용하여 구성합니다.다음 명령을 사용하여 미리 설정된 최대값을 확인합니다.
eth0을 사용자의 이름으로 바꿉니다.ethtool -g eth0rx(수신) 및tx(전송) 버퍼 크기를 모두 4KB로 설정합니다.ethtool -G eth0 rx 4096 tx 4096값이 올바르게 구성되었는지 확인합니다.
ethtool -g eth0점보 프레임을 사용하도록 설정합니다. 점보 프레임을 사용하도록 설정하기 전에 모든 네트워크 스위치, 라우터, 클라이언트와 SQL Server 간의 네트워크 패킷 경로에 있는 기타 모든 필수 항목이 점보 프레임을 지원하는지 확인합니다. 지원하는 경우에만 점보 프레임을 사용하여 성능을 향상할 수 있습니다. 점보 프레임을 사용하도록 설정한 후 SQL Server에 연결한 다음, 아래와 같이
sp_configure를 사용하여 네트워크 패킷 크기를 8060으로 변경합니다.# 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 9014EXECUTE sp_configure 'network packet size', '8060'; GO RECONFIGURE WITH OVERRIDE; GO기본적으로 적응형 RX/TX IRQ 병합을 위한 포트를 설정하는 것이 좋습니다. 이렇게 하면 패킷 속도가 낮을 때는 대기 시간을 줄이고, 패킷 속도가 높을 때는 처리량을 높이도록 인터럽트 전달이 조정됩니다. 네트워크 인프라에 따라 이 설정을 사용하지 못할 수도 있으므로 기존 네트워크 인프라를 검토하여 지원되는지 확인합니다. 아래 예시는 이름이
eth0인 Intel 기반 NIC와 관련된 것입니다.적응형 RX/TX IRQ 병합에 대한 포트 설정:
ethtool -C eth0 adaptive-rx on ethtool -C eth0 adaptive-tx on설정 확인:
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 eth0rx-usecs및irq매개 변수를 설정합니다.rx-usecs는 인터럽트를 생성하기 전에 1개 이상의 패킷이 수신된 후의 마이크로초 수를 지정합니다.irq매개 변수는 인터럽트 비활성화 시 상태 업데이트의 해당 지연을 지정합니다. Intel 기반 NIC의 경우 다음 설정을 사용할 수 있습니다.ethtool -C eth0 rx-usecs 100 tx-frames-irq 512변경을 확인합니다.
ethtool -c eth0RSS(수신 측 크기 조정)를 사용하도록 설정하고 기본적으로 RSS 큐의 RX 쪽과 TX 쪽을 결합하는 것이 좋습니다. Microsoft 지원과 협업할 때 RSS를 사용하지 않도록 설정하여 성능이 향상된 특정 시나리오도 있었습니다. 프로덕션 환경에 적용하기 전에 테스트 환경에서 이 설정을 테스트합니다. 다음 예시는 Intel NIC용입니다.
미리 설정된 최대값 가져오기:
ethtool -l eth0미리 설정된 ‘결합된’ 최대값에 보고된 값과 큐를 결합합니다. 이 예시에서는 값이
8로 설정됨:ethtool -L eth0 combined 8설정 확인:
ethtool -l eth0NIC 포트 IRQ 선호도 사용. IRQ 선호도를 조정하여 필요한 성능을 얻으려면 Linux의 서버 토폴로지 처리, NIC 드라이버 스택, 기본 설정, irqbalance 설정과 같은 몇 가지 중요한 매개 변수를 고려합니다. NIC 포트 IRQ 선호도 설정을 최적화하려면 서버 토폴로지에 대한 지식이 필요하며 irqbalance를 사용하지 않도록 설정하고 NIC 공급업체별 설정을 사용해야 합니다.
Mellanox 특정 네트워크 인프라의 다음 예시는 구성을 설명하는 데 도움이 됩니다. 자세한 내용을 확인하고 Mellanox mlnx를 다운로드하려면 Mellanox 네트워크 어댑터용 성능 튜닝 도구를 참조하세요. 명령은 환경에 따라 변경됩니다. 추가 지침은 NIC 공급업체에 문의하세요.
irqbalance를 사용하지 않도록 설정하거나, IRQ 설정의 스냅샷을 얻고 디먼을 강제로 종료합니다.systemctl disable irqbalance.service또는
irqbalance --oneshotcommon_irq_affinity.sh가 실행 가능한지 확인합니다.chmod +x common_irq_affinity.shMellanox NIC 포트에 대한 IRQ 선호도 표시(예:
eth0):./show_irq_affinity.sh eth0Mellanox 도구를 사용하여 최상의 처리량 성능 최적화:
./mlnx_tune -p HIGH_THROUGHPUTNIC 및 해당 포트를 물리적으로 호스팅하는 NUMA 노드에 하드웨어 선호도 설정:
./set_irq_affinity_bynode.sh `\cat /sys/class/net/eth0/device/numa_node` eth0IRQ 선호도 확인:
./show_irq_affinity.sh eth0IRQ 병합 최적화 추가
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위의 변경 작업을 수행한 후 다음 명령을 통해 NIC 속도를 검사하여 예상 속도와 일치하는지 확인합니다.
ethtool eth0 | grep -i Speed
고급 커널 및 OS 구성
최상의 스토리지 I/O 성능을 위해 블록 디바이스에 Linux 다중 큐 예약을 사용하면 블록 계층 성능이 빠른 SSD(반도체 드라이브) 및 다중 코어 시스템으로 잘 확장될 수 있습니다. Linux 배포에서 기본적으로 사용하도록 설정되어 있는지 설명서를 확인합니다. 대부분의 경우
scsi_mod.use_blk_mq=y로 커널을 부팅하면 사용하도록 설정되지만 사용 중인 Linux 배포판의 설명서에 추가 지침이 있을 수 있습니다. 이는 업스트림 Linux 커널과 일치합니다.다중 경로 I/O는 SQL Server 배포에 자주 사용되므로
dm_mod.use_blk_mq=y커널 부팅 옵션을 사용하도록 설정하여blk-mq인프라를 사용하도록 DM(디바이스 매퍼) 다중 큐 대상도 구성해야 합니다. 기본값은n(사용 안 함)입니다. 기본 SCSI 디바이스에서blk-mq를 사용하는 경우 이 설정은 DM 계층의 잠금 오버헤드를 줄입니다. 다중 경로 I/O를 구성하는 방법에 대한 자세한 내용은 Linux 배포판의 설명서를 참조하세요.
스왑 파일 구성
메모리 부족 문제를 방지하려면 올바르게 구성된 swapfile이 있어야 합니다. swapfile을 만들고 올바른 크기를 지정하는 방법은 해당 Linux 설명서를 참조하세요.
가상 머신 및 동적 메모리
가상 머신에서 SQL Server on Linux를 실행하는 경우 가상 머신에 대해 예약된 메모리 크기를 수정하는 옵션을 선택해야 합니다. Hyper-V 동적 메모리와 같은 기능을 사용하지 않도록 합니다.
SQL Server 구성
애플리케이션 성능을 최대화하려면 SQL Server on Linux를 설치한 후에 다음 구성 태스크를 수행합니다.
모범 사례
노드 및/또는 CPU에 대해 PROCESS AFFINITY 사용
Linux OS의 SQL Server에 사용하는 모든 NUMANODE 및/또는 CPU(일반적으로 모든 NODE 및 CPU)에 대해 ALTER SERVER CONFIGURATION을 사용하여 PROCESS AFFINITY를 설정합니다. 프로세서 선호도는 효율적인 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 OS에서 충분한 실제 메모리를 사용할 수 있도록 하기 위해 SQL Server 프로세스는 기본적으로 실제 RAM의 80%만 사용합니다. 실제 RAM이 큰 일부 시스템에서는 20%도 상당한 크기일 수 있습니다. 예를 들어 RAM이 1TB인 시스템에서 기본 설정을 사용할 경우 약 200GB RAM이 사용되지 않는 상태로 유지됩니다. 이런 상황에서는 메모리 한도를 더 큰 값으로 구성하는 것이 좋습니다. SQL Server에 표시되는 메모리(MB 단위)를 제어하는 memory.memorylimitmb 설정과 mssql-conf 도구는 설명서를 참조하세요.
이 설정을 변경하는 경우 값을 너무 높게 설정하지 않도록 주의합니다. 충분한 메모리를 유지하지 않으면 Linux OS와 기타 Linux 애플리케이션에서 문제가 발생할 수 있습니다.