適用対象:
Linux 上の SQL Server
この記事では、ストレージ、カーネル、CPU、ネットワーク設定など、SQL Server on Linuxのパフォーマンスを最大化するためのオペレーティング システムとハードウェアの構成に関する推奨事項について説明します。
Note
メモリ構成とコンテナーのメモリ制限については、「パフォーマンスのベスト プラクティス: Linux でのメモリのSQL Server」を参照してください。
ストレージの構成に関する推奨事項
データ、トランザクション ログ、およびその他の関連ファイル (インメモリ OLTP のチェックポイント ファイルなど) をホストするストレージ サブシステムは、平均ワークロードとピーク ワークロードの両方を適切に管理する必要があります。
適切な IOPS、スループット、冗長性を備えた記憶域サブシステムを使用する
オンプレミス環境では、通常、ストレージ ベンダーは、適切な IOPS、スループット、冗長性を確保するために、複数のディスク間でストライピングを行う適切なハードウェア RAID 構成をサポートしています。 ただし、このサポートは、異なるストレージ ベンダーや、アーキテクチャが異なるさまざまなストレージ オファリングによって異なる場合があります。
Azure 仮想マシンに展開SQL Server on Linux場合は、ソフトウェア RAID を使用して適切な IOPS とスループットを確保することを検討してください。 Azure仮想マシンでSQL Serverを構成する場合のストレージに関する考慮事項については、Azure VM でのSQL Serverのストレージの構成に関するページを参照してください。
次の例は、Azure 仮想マシン上の Linux でソフトウェア RAID を作成する方法を示しています。 データ、トランザクション ログ、 tempdb I/O の要件に基づいて、ボリュームに必要なスループットと 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,024) よりも多くの接続が必要になる場合があります。 ソフト制限とハード制限を 1048576 (1,048,576) に設定できます。 たとえば、RHEL で、次の値を持つように /etc/security/limits.d/99-mssql-server.conf ファイルを編集します。
mssql - nofile 1048576
Note
この設定は、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 ディストリビューションでは、データの持続性を確保するために、I/O サブシステム レベルで強制ユニット アクセス (FUA) が実装されています。 SQL Server では、この機能を利用して、Linux ワークロードに効率的で信頼性の高い I/O パフォーマンスを提供します。 Linux ディストリビューション全体での FUA サポートとその SQL Server への影響の詳細については、「 SQL Server on Linux: Forced Unit Access (FUA) Internals」を参照してください。
I/O サブシステムでの FUA のサポートは、SUSE Linux Enterprise Server 12 SP5、Red Hat Enterprise Linux 8.0、Ubuntu 18.04 で導入されました。 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 以降)
Note
SQL Server 2025 (17.x) 以降、SUSE Linux Enterprise Server (SLES) はサポートされていません。
Linux カーネル 4.18 以降のバージョンの SQL Server ストレージ用の XFS ファイル システム。
linux カーネル 5.6 以降のバージョンの SQL Server ストレージ用 ext4 ファイル システム。
Note
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 プロファイルを使用して、SQL Serverワークロードに対してより細かい Linux パフォーマンス関連のチューニングを提供できます。 このプロファイルは、RHEL スループット パフォーマンス プロファイルに基づいています。
mssql プロファイルではすべての設定が公開されるため、このプロファイルを含まない他の Linux ディストリビューションまたは RHEL リリースに合わせて確認して調整できます。
SUSE Linux Enterprise Server 12 SP5、Ubuntu 18.04、Red Hat Enterprise Linux 7.x では、 tuned パッケージを手動でインストールできます。 これを使用して、次のセクションで説明するように mssql プロファイルを作成して構成します。
Note
SQL Server 2025 (17.x) 以降、SUSE Linux Enterprise Server (SLES) はサポートされていません。
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 設定に関する推奨事項を示します。
| Setting | Value | 詳細情報 |
|---|---|---|
| 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 パラメーターを手動で構成する必要があります。
ディスク設定に関する推奨事項
次の表に、ディスク設定に関する推奨事項を示します。
| Setting | Value | 詳細情報 |
|---|---|---|
ディスク 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 コマンドを参照してください |
Description
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 (65,536) であり、SQL Serverインストールでは十分に高くない可能性があります。 このため、SQL Server展開のvm.max_map_count値を少なくとも 262144 (262,144) に変更します。 これらのカーネル パラメーターのチューニングの詳細については、「 TuneD mssql プロファイルを使用して提案された Linux 設定 」セクションを参照してください。
vm.max_map_countの最大値は2147483647 (2,147,483,647) です。
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 との間のネットワーク パケット パスに必要なすべてのネットワーク スイッチ、ルーター、およびその他で、ジャンボ フレームがサポートされていることを確認します。 その場合にのみ、ジャンボ フレームを有効にするとパフォーマンスが向上します。 ジャンボ フレームを有効にした後、次の例に示すように、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アダプティブ IRQ 結合を構成します。 既定では、アダプティブ RX/TX IRQ 結合のポートを設定します。つまり、パケット レートが低い場合の待機時間を改善し、パケット レートが高い場合のスループットを向上させるために割り込み配信が調整されます。 この設定はネットワーク インフラストラクチャ全体で使用できない可能性があるため、既存のネットワーク インフラストラクチャを確認し、この設定がサポートされていることを確認してください。 例は、intel ベースの NIC である
eth0という名前の NIC です。アダプティブ RX/TX IRQ コアレッシング用のポートを設定します。
ethtool -C eth0 adaptive-rx on ethtool -C eth0 adaptive-tx on設定を確認します。
ethtool -c eth0Note
ベンチマークの環境など、高パフォーマンス環境で予測可能な動作を行う場合は、アダプティブ 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_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 eth0NIC の速度を確認します。 上記の変更を行った後、次のコマンドを使用して、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 をインストールした後、次の構成タスクを実行して、アプリケーションに最適なパフォーマンスを実現します。
ベスト プラクティス
次のプラクティスは、すべてのSQL Server on Linuxデプロイに適用されます。
ノードと CPU に PROCESS AFFINITY を使用する
Linux OS で SQL Server に使用しているすべてのNUMANODEと CPU（通常はすべてのNODEと CPU）に対してPROCESS AFFINITYを設定するには、ALTER SERVER CONFIGURATIONを使用します。 プロセッサ アフィニティは、効率的な Linux と SQL のスケジュール動作を維持するのに役立ちます。
NUMANODE オプションを使用するのが最も簡単な方法です。 コンピューターに 1 つの NUMA ノードしかない場合でも、 PROCESS AFFINITY を使用します。
PROCESS AFFINITYの設定方法の詳細については、ALTER SERVER CONFIGURATIONの記事を参照してください。
複数の tempdb データ ファイルを構成する
SQL Server on Linuxインストールには複数のtempdb ファイルを構成するオプションがないため、インストール後に複数のtempdb データ ファイルを作成することを検討してください。 詳細については、「推奨事項」を参照して、SQL Server tempdb データベースでの割り当ての競合を減らします。
詳細な構成
mssql-confメモリ制限、cgroup 設定、Docker コンテナー のメモリ例、スワップ領域に関する考慮事項などのメモリ構成オプションについては、「パフォーマンスのベスト プラクティス: Linux でのメモリのSQL Server」を参照してください。