パフォーマンスのベスト プラクティスと SQL Server on Linux の構成ガイドライン
適用対象: 
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 については、適切な IOPS とスループットの要件が確実に満たされるようにソフトウェア RAID の使用を検討してください。 同様のストレージに関する考慮事項と共に Azure 仮想マシン上で SQL Server を構成する場合は、SQL Server VM のストレージ構成に関する記事を参照してください。
以下の例は、Azure Virtual Machines 上の Linux でソフトウェア RAID を作成する方法を示しています。 データ、トランザクション ログ、tempdb IO の要件に基づくボリュームに必要なスループットと IOPS に応じて、適切な数のデータ ディスクを使用する必要があることに注意してください。 以下の例では、8 つのデータ ディスクが Azure 仮想マシンに接続されています。つまり、データ ファイルのホスト用に 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 の両方のファイルシステムがサポートされます。 Microsoft では、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
永続メモリ ファイル システムに関する推奨事項
永続メモリ デバイスでのファイル システムの構成の場合、基になるファイル システムのブロック割り当てを 2 MB にする必要があります。 この記事について詳しくは、「技術的な考慮事項」の記事を参照してください。
オープン ファイル制限
運用環境では、1,024 個という既定のオープン ファイル制限より多くの接続が必要になる場合があります。 ソフトとハードの制限を 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 ファイルに追加します。 ドライブを参照するために、デバイス名 (/dev/sdc1 など) だけでなく、UUID (汎用一意識別子) も /etc/fstab で使用する必要があります。
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 以降)
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 ポッドをホスティングするワーカー ノードは、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 スループットパフォーマンス プロファイルで、(C-States を除く) 一部のカーネルおよび CPU 設定が自動的に構成されます。 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 プロファイルを有効にするには、これらの定義を /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 周波数ガバナー | パフォーマンス | 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 プロファイルのベースとしてスループット パフォーマンス プロファイルが使用されているためです。 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 の場合、バッファー プールをデータ ページ キャッシュとして使用し、信頼性の高い復旧ができるようにするために、ファイルシステム キャッシュをバイパスして物理ハードウェアに書き込むことが強く優先されます。そのため、パフォーマンスの高い専用の SQL Server に対しては、積極的な swappiness の構成が効果的な可能性があります。 詳細については、/proc/sys/vm/ - #swappiness のドキュメントを参照してください。vm.dirty_*: SQL Server ファイルの書き込みアクセスはキャッシュされないため、そのデータの整合性要件が満たされます。 これらのパラメーターを使用すると、効率的な非同期書き込みパフォーマンスを実現し、フラッシュを調整しながら十分な大きさのキャッシュを許可することで Linux での書き込みのキャッシュのストレージ I/O への影響を軽減できます。kernel.sched_*: これらのパラメーター値は、Linux カーネルの Completely Fair Scheduling (CFS) アルゴリズムを微調整するための現在の推奨事項を表します。これにより、スレッドのプロセス間のプリエンプションと再開に関して、ネットワークおよびストレージの I/O 呼び出しのスループットが向上します。
mssql TuneD プロファイルを使用すると、vm.swappiness、vm.dirty_*、kernel.sched_* の設定が構成されます。 blockdev コマンドを使用したディスク readahead 構成はデバイスごとに行われるため、手動で実行する必要があります。
マルチノード NUMA システムのカーネル設定の自動 NUMA バランシング
マルチノード NUMA システムに SQL Server をインストールすると、次の kernel.numa_balancing カーネル設定が既定で有効になります。 NUMA システムでの効率が最大になるように SQL Server を運用するには、マルチノード 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 との間のネットワーク パケット パスに必要なすべてのネットワーク スイッチ、ルーター、およびその他で、ジャンボ フレームがサポートされていることを確認します。 そうした場合にのみ、ジャンボ フレームを有効にするとパフォーマンスが向上します。 ジャンボ フレームが有効になったら、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 9014EXEC 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 eth0Receive Side Scaling (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 のデプロイによく使用されるため、
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 (通常はすべてのノードと CPU) について、ALTER SERVER CONFIGURATION を使用して PROCESS AFFINITY を設定します。 プロセッサ関係は、効率的な Linux および SQL スケジューリングの動作を維持するために役立ちます。 NUMANODE オプションを使用するのが最も簡単な方法です。 コンピューター上に NUMA ノードが 1 つしかない場合でも、PROCESS AFFINITY を使用します。 PROCESS AFFINITY の設定方法について詳しくは、PROCESS AFFINITY に関する記事を参照してください。
複数の tempdb データ ファイルを構成する
SQL Server on Linux のインストールには複数の tempdb ファイルを構成するオプションが用意されていないため、インストール後に複数の tempdb データ ファイルを作成することを検討することをお勧めします。 詳細については、「Tempdb データベースを SQL Server に割り当て時の競合を減らすための推奨事項」を参照してください。
詳細な構成
次の推奨事項は、SQL Server on Linux のインストール後に選択できるオプションの構成設定です。 これらの選択肢は、ご利用の Linux OS のワークロードと構成の要件に基づいています。
mssql-conf を使用してメモリ制限を設定する
Linux OS に十分な空き物理メモリを確保するために、SQL Server プロセスには既定で物理 RAM の 80% のみが使用されます。 物理 RAM のサイズが大きな一部のシステムの場合、20% でも大きな数値になることがあります。 たとえば、1 TB の RAM が搭載されたシステムでは、既定の設定では約 200 GB の RAM が未使用のままになります。 このような状況では、メモリの制限をより大きな値に構成することができます。 mssql-conf ツールと、SQL Server に表示されるメモリ (MB 単位) を制御する memory.memorylimitmb 設定のドキュメントを参照してください。
この設定を変更する場合は、この値を高く設定しすぎないように注意してください。 十分なメモリを残さないと、Linux OS やその他の Linux アプリケーションで問題が発生するおそれがあります。