適用対象:
SQL Server - Linux
この記事では、SQL Server on Linux に接続するデータベース アプリケーションのパフォーマンスを最大化するためのベスト プラクティスと推奨事項について説明します。 これらの推奨事項は、Linux プラットフォームでの実行に固有のものです。 インデックスの設計など、通常の SQL Server の推奨事項はすべて引き続き適用されます。
次のガイドラインには、SQL Server と Linux オペレーティング システム (OS) の両方を構成する場合の推奨事項が含まれています。 SQL Server のインストールで最適なパフォーマンスを得るために、次の構成設定を使用することを検討してください。
ストレージの構成に関する推奨事項
データ、トランザクション ログ、およびその他の関連ファイル (インメモリ OLTP のチェックポイント ファイルなど) をホストする記憶域サブシステムでは、平均とピークのワークロードの両方を適切に管理できる必要があります。
適切な IOPS、スループット、冗長性を備えた記憶域サブシステムを使用する
オンプレミス環境では、通常、ストレージ ベンダーは、適切な IOPS、スループット、冗長性を確保するために、複数のディスク間でストライピングを行う適切なハードウェア RAID 構成をサポートしています。 ただし、このサポートは、異なるストレージ ベンダーや、アーキテクチャが異なるさまざまなストレージ オファリングによって異なる場合があります。
Azure Virtual Machines にデプロイされた SQL Server on Linux の場合は、ソフトウェア RAID を使用して適切な IOPS とスループットの要件を確保することを検討してください。 同様のストレージに関する考慮事項と共に Azure 仮想マシン上で SQL Server を構成する場合は、「Azure VM の SQL Server 向けのストレージを構成する」を参照してください。
次の例は、Azure 仮想マシン上の Linux でソフトウェア RAID を作成する方法を示しています。 データ、トランザクション ログ、tempdb IO の要件に基づくボリュームに必要なスループットと IOPS に応じて、適切な数のデータ ディスクを使用する必要があることに注意してください。 次の例では、8 つのデータ ディスクが VM に接続されています。データ ファイルをホストする場合は 4 つ、トランザクション ログには 2 つ、 tempdb ワークロードには 2 つ。
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
ログ アレイは、64 KB のストライプを備えた 6 ドライブ RAID-10 です。 ご覧のとおり、
-
sunit=16 blksの場合、16 * 4096 ブロック サイズ = 64 KB は、ストライプ サイズと一致します。 -
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
永続メモリ ファイル システムに関する推奨事項
永続メモリ デバイスでのファイルシステム構成の場合は、基になるファイルシステムのブロック割り当てを 2 MB に設定します。 詳細については、「 技術的な考慮事項」を参照してください。
オープン ファイル制限
運用環境では、1024 個という既定のオープン ファイル制限より多くの接続が必要になる場合があります。 ソフトとハードの制限を 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 (ユニバーサル一意識別子) を使用してドライブを参照します。
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) 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 機能をサポートし、そのために構成されている記憶域サブシステムやハードウェア
推奨構成:
トレース フラグ 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 または ext4 ファイルシステムを使用する必要があり、FUA をサポートする必要があります (ext4 はバージョン 5.6 より前の Linux カーネルでは FUA をサポートしていません)。 この設定を有効にするには、あらかじめ Linux ディストリビューション ベンダーとストレージ ベンダーに問い合わせて、OS とストレージ サブシステムが FUA オプションをサポートしていることを確認してください。 Kubernetes では、次のコマンドを使用してファイルシステムの種類に対するクエリを実行できます。ここで
<pvc-name>はPersistentVolumeClaimです。kubectl describe pv <pvc-name>出力内で、XFS に設定されている
fstypeを探します。SQL Server ポッドをホスティングするワーカー ノードは、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 を使用してカーネル設定を構成する
Red Hat Enterprise Linux (RHEL) ユーザーの場合、 TuneD スループット パフォーマンス プロファイルによって、一部のカーネルと CPU の設定 (C-States を除く) が自動的に構成されます。 RHEL 8.0 以降、mssql という名前の TuneD プロファイルは Red Hat と共に共同開発されており、SQL Server ワークロードに対する Linux のパフォーマンス関連のきめ細かなチューニングが提供されています。 このプロファイルには、RHEL のスループット パフォーマンス プロファイルが含まれており、このプロファイルを使用しない他の 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 周波数ガバナー | パフォーマンス | cpupower コマンドを参照してください |
| ENERGY_PERF_BIAS | パフォーマンス | x86_energy_perf_policy コマンドを参照してください |
| 最小性能割合 (min_perf_pct) | 100 | intel p-state に関するドキュメントを参照してください |
| C-States | C1 のみ | C-States が C1 のみに確実に設定する方法については、Linux またはシステムのドキュメントを参照してください |
説明に従って TuneD を使用すると、CPU 周波数ガバナー、 ENERGY_PERF_BIAS、および min_perf_pct 設定が自動的に構成されます。
mssql プロファイルのベースとしてスループット パフォーマンス プロファイルが使用されます。 Linux またはシステム ディストリビューターによって提供されるドキュメントに従って、C-States パラメーターを手動で構成する必要があります。
ディスク設定に関する推奨事項
次の表に、ディスク設定に関する推奨事項を示します。
| 設定 | [値] | 詳細 |
|---|---|---|
ディスク 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 はバッファー プールをデータ ページ キャッシュとして使用し、信頼性の高い回復のためにファイルシステム キャッシュをバイパスする物理ハードウェアへの書き込みを強く好むため、積極的なスワップ構成は、高パフォーマンスで専用の SQL Server に役立ちます。詳細については、/proc/sys/vm/ - #swappiness のドキュメントを参照してください。
vm.dirty_*: SQL Server ファイルの書き込みアクセスはキャッシュされないため、そのデータの整合性要件が満たされます。 これらのパラメーターを使用すると、効率的な非同期書き込みパフォーマンスを実現し、フラッシュを調整しながら十分な大きさのキャッシュを許可することで Linux での書き込みのキャッシュのストレージ IO への影響を軽減できます。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 オプションが構成されます。
Transparent Huge Pages (THP) を有効なままにする
ほとんどの 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 の場合、推奨されるバッファー サイズは 4 KB (4096) です。 事前設定された最大値を確認し、次の例を使用して構成します。次のコマンドを使用して、プリセットの最大値を確認します。
eth0をユーザーの NIC 名で置き換えます。ethtool -g eth0rx(受信) とtx(送信) の両方のバッファー サイズを 4 KB に設定します。ethtool -G eth0 rx 4096 tx 4096以下のコマンドで、値が正しく構成されていることを確認します。
ethtool -g eth0ジャンボ フレームを有効にします。. ジャンボ フレームを有効にする前に、クライアントと SQL Server との間のネットワーク パケット パスに必要なすべてのネットワーク スイッチ、ルーター、およびその他で、ジャンボ フレームがサポートされていることを確認します。 その場合にのみ、ジャンボ フレームを有効にするとパフォーマンスが向上します。 ジャンボ フレームが有効になった後、次の例に示すように、
sp_configureを使用して SQL Server に接続し、ネットワーク パケット サイズを 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 結合のポートを設定します。つまり、パケット レートが低い場合の待機時間を改善し、パケット レートが高い場合のスループットを向上させるために割り込み配信が調整されます。 この設定はネットワーク インフラストラクチャ全体で使用できない可能性があるため、既存のネットワーク インフラストラクチャを確認し、この設定がサポートされていることを確認してください。 例は、intel ベースの NIC である
eth0という名前の 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 eth0受信側スケーリング (RSS) を有効にし、既定では、RSS キューの RX 側と TX 側を組み合わせます。 MICROSOFT サポートを使用する場合、RSS を無効にするとパフォーマンスも向上する特定のシナリオがあります。 運用環境に適用する前に、テスト環境でこの設定をテストしてください。 次の例は、Intel NIC の場合です。
プリセットの最大値を取得します。
ethtool -l eth0キューを、プリセットの "Combined" 最大値で報告された値と組み合わせます。 この例では、値は
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_THROUGHPUTハードウェア アフィニティを、NIC とそのポートを物理的にホスティングする 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 の展開でよく使用されるため、
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 の構成
SQL Server on Linux をインストールした後、次の構成タスクを実行して、アプリケーションに最適なパフォーマンスを実現します。
ベスト プラクティス
ノードや CPU に PROCESS AFFINITY を使用する
ALTER SERVER CONFIGURATIONを使用して、Linux OS 上の SQL Server で使用しているすべてのNUMANODEおよび CPU に対してPROCESS AFFINITYを設定します（通常はすべての NODE および CPU に対して行います）。 プロセッサ関係は、効率的な Linux および SQL スケジューリングの動作を維持するために役立ちます。
NUMANODE オプションを使用するのが最も簡単な方法です。 コンピューター上に NUMA ノードが 1 つしかない場合でも、PROCESS AFFINITY を使用します。
PROCESS AFFINITY の設定方法について詳しくは、 に関する記事を参照してください。
複数の tempdb データ ファイルを構成する
SQL Server on Linux のインストールには複数の tempdb ファイルを構成するオプションが用意されていないため、インストール後に複数の tempdb データ ファイルを作成することを検討することをお勧めします。 詳細については、「Tempdb データベースを SQL Server に割り当て時の競合を減らすための推奨事項」を参照してください。
詳細な構成
次の推奨事項は、SQL Server on Linux のインストール後に選択できるオプションの構成設定です。 これらの選択肢は、ご利用の Linux OS のワークロードと構成の要件に基づいています。
mssql-conf を使用してメモリ制限を設定する
Linux オペレーティング システムに十分な空き物理メモリがあることを確認するために、SQL Server プロセスでは既定で 80% の物理 RAM のみが使用されます。 物理 RAM が大量にあるシステムによっては、20% が多い場合があります。
たとえば、1 TB の RAM が搭載されたシステムでは、既定の設定では約 200 GB の 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 チャートを使用して SQL Server Linux コンテナーを Kubernetes にデプロイする
- Linux カーネル cgroup v2 のドキュメント
- コントロール グループ v2
メモリ制限の設定に関するガイドライン
SQL Server on Linux のメモリ制限を設定する場合は、次のガイドラインを考慮してください。
cgroupを使用して、コンテナーで使用可能なメモリ全体を制限します。 この設定により、コンテナー内のすべてのプロセスの上限が確立されます。メモリ制限 (
memorylimitmbまたはMSSQL_MEMORY_LIMIT_MB環境変数によって設定される) は、SQL Server on Linux がすべてのコンポーネント (バッファー プール、SQLPAL、SQL Server エージェント、LibOS、PolyBase、Full-Text Search、および Linux 上の SQL Server に読み込まれたその他のプロセスなど) に割り当てることができる合計メモリを制御します。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 の全体的なメモリ使用量は制御されません。 SQLPAL、SQL Server エージェント、LibOS、PolyBase、Full-Text Search、および SQL Server on Linux に読み込まれたその他のプロセスなど、他のコンポーネントに十分なメモリが残るように、常に
memorylimitmbよりも小さい値を設定します。