适用于:SQL Server - Linux
本文提供了最佳做法和建议,以最大程度地提高连接到 Linux 上的 SQL Server 的数据库应用程序的性能。 这些建议特定在 Linux 平台上运行。 所有正常 SQL Server 建议(例如索引设计)仍适用。
以下指南包含配置 SQL Server 和 Linux 操作系统 (OS) 的建议。 请考虑使用这些配置设置来体验 SQL Server 安装的最佳性能。
存储配置建议
托管数据、事务日志和其他关联文件(如内存中 OLTP 的检查点文件)的存储子系统应能够正常管理平均和峰值工作负载。
使用具有适当 IOPS、吞吐量和冗余的存储子系统
在本地环境中,存储供应商通常支持适当的硬件 RAID 配置,并跨多个磁盘进行条带化,以确保适当的 IOPS、吞吐量和冗余。 但是,此支持在不同存储供应商和具有不同体系结构的不同存储产品/服务之间可能有所不同。
对于部署在 Azure 虚拟机上的 Linux 上的 SQL Server,请考虑使用软件 RAID 来确保适当的 IOPS 和吞吐量要求。 在 Azure 虚拟机上配置具有类似存储注意事项的 SQL Server 时,请参阅为 Azure VM 上的 SQL Server 配置存储。
以下示例演示如何在 Azure 虚拟机上的 Linux 中创建软件 RAID。 请注意,应该根据数据、事务日志和 tempdb I/O 要求,使用适当数量的数据磁盘,为卷提供所需的吞吐量和 IOPS。 在以下示例中,已将 8 个数据磁盘附加到 VM;四个用于托管数据文件,两个用于事务日志,两个用于 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
日志阵列是一个由六个驱动器构成的 RAID-10,其条带大小为 64 KB。 正如你所见:
- 对于
sunit=16 blks,16 * 4096 块大小 = 64 KB,与条带大小匹配。 - 对于
swidth=48 blks,swidth/sunit= 3,这是阵列中的数据驱动器数量,不包括奇偶校验驱动器。
建议的文件系统配置
SQL Server 支持 ext4 和 XFS 文件系统来托管数据库、事务日志和其他文件,例如 SQL Server 中内存中 OLTP 的检查点文件。 使用 XFS 文件系统托管 SQL Server 数据和事务日志文件。
使用 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
PMEM 文件系统建议
对于永久性内存设备上的文件系统配置,请将基础文件系统的块分配设置为 2 MB。 有关详细信息,请参阅 技术注意事项。
打开文件限制
生产环境可能需要比默认打开文件限制 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 该文件。 使用 UUID(通用唯一标识符) /etc/fstab 来引用驱动器,而不仅仅是设备名称(例如 /dev/sdc1)。
对任何存储 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 的影响,请参阅 Linux 上的 SQL Server:强制单元访问 (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 时,应使用 XFS 文件系统托管 SQL Server 数据和事务日志文件。 从内核版本 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>在输出中查找
fstype,它设置为 XFS。托管 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 来配置内核设置
对于 Red Hat Enterprise Linux(RHEL)用户, TuneD 吞吐量性能配置文件会自动配置一些内核和 CPU 设置(C 状态除外)。 自 RHEL 8.0 起,与 Red Hat 共同开发了名为 mssql 的 TuneD 配置文件,它可为 SQL Server 工作负载提供更精细的 Linux 性能相关优化。 此配置文件包含 RHEL 吞吐量-性能配置文件,我们在本文中提供了它的定义,供你查看其他没有此配置文件的 Linux 发行版和 RHEL 版本。
对于 SUSE Linux Enterprise Server 12 SP5、Ubuntu 18.04 和 Red Hat Enterprise Linux 7.x,可以手动安装包 tuned 。 使用它创建和配置 mssql 配置文件,如以下部分所述。
建议的 Linux 设置,它们使用 TuneD mssql 配置文件
以下示例为 Linux 上的 SQL Server 提供 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
如果你使用的 Linux 发行版的内核版本高于 4.18,请按如下所示注释以下选项;否则,如果你使用的发行版的内核版本低于 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 状态 | 仅限 C1 | 请参阅 Linux 或系统文档,了解如何确保将 C 状态设置为仅限 C1 |
如前所述使用 TuneD 时,它会自动配置 CPU 频率调控器 ENERGY_PERF_BIAS以及 min_perf_pct 设置。 它使用吞吐量性能配置文件作为 mssql 配置文件的基础。 必须根据 Linux 或系统分发服务器提供的文档手动配置 C 状态参数。
磁盘设置建议
下表提供了磁盘设置的建议:
| 设置 | 值 | 详细信息 |
|---|---|---|
磁盘 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 缓存写入的存储 I/O 影响。kernel.sched_*:这些参数值表示在 Linux 内核中调整完全公平计划 (CFS) 算法的当前建议。 在进程间抢占和恢复线程方面,它们提高了网络和存储 I/O 调用的吞吐量。
使用mssql的 TuneD 配置文件配置vm.swappiness、vm.dirty_*和kernel.sched_*设置。 必须针对每个设备,使用 blockdev 命令手动配置磁盘 readahead 设置。
多节点 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)
默认情况下,大多数 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 类型和供应商。
配置网络端口缓冲区大小。 在此示例中,Intel 基于的网卡被命名为
eth0。 对于基于 Intel 的 NIC,推荐的缓冲区大小为 4 KB (4096)。 验证预设的最大值,然后使用以下示例进行配置:使用以下命令检查预设最大值。 将
eth0替换为你的 NIC 名称:ethtool -g eth0将
rx(接收)和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默认情况下,为自适应 RX/TX IRQ 合并设置端口,这意味着中断传递经过调整,以提高数据包速率较低时的延迟,并在数据包速率较高时提高吞吐量。 此设置在网络基础结构中可能不可用,因此请查看现有的网络基础结构并确认支持此设置。 该示例适用于名为
eth0NIC 的 NIC,它是基于 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 eth0设置
rx-usecs和irq参数。rx-usecs指定在生成中断之前至少收到一个数据包之后的微秒数。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将队列与预设的“组合”最大值中报告的值组合在一起。 在此示例中,值设置为
8:ethtool -L eth0 combined 8验证以下设置:
ethtool -l eth0使用 NIC 端口 IRQ 关联。 若要通过调整 IRQ 相关性来实现预期性能,请考虑几个重要参数,如 Linux 处理服务器拓扑、NIC 驱动程序堆栈、默认设置和
irqbalance设置。 NIC 端口 IRQ 关联设置的优化通过了解服务器拓扑、禁用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进行上述更改后,请使用以下命令验证 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) 多队列目标配置为使用dm_mod.use_blk_mq=y基础结构。 默认值为n(已禁用)。 当基础 SCSI 设备使用blk-mq时,此设置可减少 DM 层的锁定开销。 若要详细了解如何配置多路径 I/O,请参阅 Linux 发行版的文档。
配置交换文件
请确保已正确配置交换文件,以免出现内存不足的问题。 有关如何创建交换文件并正确调整其大小的详细说明,请参阅 Linux 文档。
虚拟机和动态内存
如果在虚拟机中运行 Linux 上的 SQL Server,请确保选择选项来修复为虚拟机预留的内存量。 请勿使用 Hyper-V 动态内存等功能。
SQL Server 配置
在 Linux 上安装 SQL Server 以实现应用程序的最佳性能后,请执行以下配置任务。
最佳做法
对节点和/或 CPU 使用 PROCESS AFFINITY
用ALTER SERVER CONFIGURATION来为 Linux OS 上用于 SQL Server 的所有 NUMANODE 和 CPU(通常指所有 NODE 和 CPU)设置PROCESS AFFINITY。 处理器关联有助于保持高效的 Linux 和 SQL 计划行为。 使用 NUMANODE 选项是最简单的方法。 即使你的计算机上只有一个 NUMA 节点,也请使用 PROCESS AFFINITY。 有关如何设置 PROCESS AFFINITY 的详细信息,请参阅 ALTER SERVER CONFIGURATION 一文。
配置多个 tempdb 数据文件
由于 Linux 上的 SQL Server 安装不提供配置多个 tempdb 文件的选项,因此建议在安装后考虑创建多个 tempdb 数据文件。 有关详细信息,请参阅建议以减少 SQL Server tempdb 数据库中的分配争用一文。
高级配置
以下建议是可选的配置设置,你可以选择在安装 Linux 上的 SQL Server 之后执行这些设置。 这些选项取决于你的工作负载和 Linux OS 配置的要求。
使用 mssql-conf 设置内存限制
为了确保 Linux作系统有足够的可用物理内存,SQL Server 进程默认仅使用物理 RAM 的 80%。 对于具有大量物理 RAM 的某些系统,20 个% 可能是一个很大的数字。
例如,在具有 1 TB RAM 的系统上,默认设置将保留 200 GB RAM 不使用。 在这种情况下,你可能希望将内存限制配置为较高的值。 可以使用 mssql-conf 工具调整此值。 有关详细信息,请参阅 memory.memorylimitmb 设置,该设置控制 SQL Server 可见的内存(以 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
有关详细信息,请参阅以下资源:
设置内存限制指南
在 Linux 上设置 SQL Server 的内存限制时,请考虑以下准则:
用于
cgroup限制容器可用的总内存。 此设置为容器内的所有进程建立上限。内存限制(无论是按
memorylimitmb还是MSSQL_MEMORY_LIMIT_MB环境变量设置)控制 Linux 上的 SQL Server 可以跨其所有组件分配的总内存,例如缓冲池、SQLPAL、SQL Server 代理、LibOS、PolyBase、Full-Text 搜索以及 Linux 上 SQL Server 中加载的任何其他进程。环境变量
MSSQL_MEMORY_LIMIT_MB优先于在mssql.conf中定义的memorylimitmb。memorylimitmb不能超过主机系统的实际物理内存。将
memorylimitmb设置为低于主机系统内存和 cgroup 限制(如果存在),以确保 Linux 操作系统有足够的可用物理内存。 如果未显式设置memorylimitmb,则 SQL Server 使用系统内存总量和 cgroup 限制(如果存在)之间较小值的 80%。max_server_memory服务器配置选项仅限制 SQL Server 缓冲池的大小,并且不会控制 Linux 上的 SQL Server 的总体内存使用情况。 始终将此值设置为低于
memorylimitmb,以确保为其他组件(如 SQLPAL、SQL Server 代理、LibOS、PolyBase、全文搜索,以及载入 Linux 上 SQL Server 的任何其他进程)保留足够的内存。