- 对 Linux 内核进行调优需要结合架构配置、sysctl 和面向延迟的 CPU 调度。
- 自定义内核和 PREEMPT_RT 补丁可以大幅降低延迟,但它们会增加复杂性和维护难度。
- 网络、内存、磁盘和系统服务的优化应该始终通过严格的监控和基准测试来衡量。
- 迭代式、指标驱动的方法可以将内核改进转化为应用程序和用户的实际利益。

当我们谈论Linux的性能时,几乎所有问题最终都指向同一个地方: 内核作为控制延迟、稳定性和资源利用的核心组件适当的微调可以决定一个系统是仅仅“勉强够用”还是能够在服务器、桌面、云环境甚至其他设备上流畅运行。 非常老旧的硬件.
本指南重点介绍如何 优化 Linux 内核,在不影响安全性和可维护性的前提下,最大限度地降低延迟。我们将涵盖从基本架构概念到使用 sysctl 进行调整、编译自定义内核、使用实时补丁、针对低延迟网络(如 EC2)进行调优,以及监控和基准测试技术,以衡量您所做的调整是否真的有所改进。
Linux 内核架构及延迟关键点
Linux 内核充当应用程序和硬件之间的中间层,负责管理 内存、进程、中断、驱动程序和文件系统。 上 整体式但模块化设计由于采用了可加载模块,因此无需重新编译整个系统即可灵活地激活或停用功能。
要了解延迟的来源,关键在于了解几个子系统: 流程规划器(调度器)内存管理和中断处理至关重要。即使使用强大的硬件,配置不当的调度器、激进的内存策略或过多的不受控制的中断也会导致响应速度缓慢。
内核配置涉及以下选项: CONFIG_PREEMPT、CONFIG_PREEMPT_VOLUNTARY 或 CONFIG_SMP这些因素决定了内核在多大程度上可以被中断以处理更紧急的任务,以及如何利用多核系统。选择合适的抢占模型会显著改变桌面电脑、低延迟服务器或工业系统上的感知延迟。
在现代服务器中,硬件拓扑结构也很重要: 核心、插槽、NUMA 和缓存层次结构的分布微调 CPU 亲和性和 NUMA 策略(例如,将进程和内存固定到同一节点)有助于减少访问时间并提高缓存命中率,这对于我们想要最大限度地减少抖动和不可预测的延迟至关重要。
此外,CPU调度器与子系统之间的交互 I/O(磁盘和网络)决定吞吐量和端到端延迟 应用程序可以看到这些更改。在进行任何更改之前,建议记录当前状态(内核配置、sysctl、GRUB、已加载模块),以便在更改导致性能下降时可以快速回滚。
通过 sysctl 进行调整以改善延迟和性能
接口 sysctl 允许您动态修改内核参数 通过 /proc/sys 进行配置,无需重新编译。这是开始进行调优的理想切入点,无需先陷入编译的繁琐步骤。
在网络领域,诸如以下参数: net.core.rmem_max、net.core.wmem_max 或 net.ipv4.tcp_congestion_control 它们直接影响吞吐量、延迟和 TCP 连接行为。对于高流量 Web 服务器或低延迟云实例而言,正确调整缓冲区和拥塞算法至关重要。
对于内存而言,诸如以下的值 vm.swappiness、vm.dirty_ratio、vm.vfs_cache_pressure 或 vm.overcommit_memory 它们允许您控制交换空间的使用量、页面缓存的管理方式以及虚拟内存的行为。降低交换空间使用率(例如,降至 10)通常有助于防止系统过于频繁地使用交换空间,从而减少磁盘 I/O 延迟峰值。
如果您使用大型数据库或应用程序,并且这些应用程序使用大量的共享内存,那么调整内存使用情况至关重要。 kernel.shmmax,kernel.shmall 以及用以下方式打开的最大文件数 fs.file-max 和 fs.nr_open这些尺寸不合理的限制可能会导致瓶颈和错误,而这些错误在负载下很难诊断。
最佳方法是先实施小幅改动,用监测工具衡量其影响,然后再进行大幅度调整。 它们会被保存到 /etc/sysctl.conf 或 /etc/sysctl.d/ 中。在容器化环境中,请记住许多内核参数对于主机是全局的:随意更改它们可能会影响所有服务,因此将 sysctl 与 cgroups 和命名空间结合使用几乎是强制性的。
编译和维护自定义内核
当你需要编译自定义内核时,它仍然是一个非常强大的工具。 降低延迟、消除不必要的开销或支持稀有硬件虽然发行版都配备了相当通用的内核,但在某些情况下,特定的内核却能起到至关重要的作用。
传统的流程包括从以下位置下载代码: kernel.org 或像 xanmod 这样的打过补丁的内核树 利可力克斯并使用诸如此类的工具 make menuconfig 选择选项。将 .config 文件与构建脚本一起保存到您自己的 Git 仓库中,可以让您重现构建过程并保持版本之间的一致性。
如果您使用 Debian 或其衍生发行版,编译“Debian 风格“获取内核、头文件和相关库的 .deb 软件包。这样,您只需安装这些软件包,并使用您自己的存储库管理版本,即可在多台机器上部署该自定义内核。”
在现实世界中,当你使用……时,手动编译通常是有意义的。 老旧或功能非常有限的硬件一个典型的例子是 旧上网本 配备 Atom CPU 和 1 GB 内存的电脑,其现代通用内核充满了不必要的驱动程序和服务器选项,引入了你无法承受的延迟和额外的 CPU 消耗。
一种常见的策略是从当前的内核配置开始(例如,通过复制以下文件): /启动配置),然后从那里进行裁剪或调整。您可以将抢占模型更改为“抢占式内核(低延迟桌面)“优先处理交互式桌面响应,或添加特定的 I/O 调度程序,例如……” BFQ 以模块的形式,改善机械碟的使用体验。
为了避免把半辈子都耗在编译上,最好在性能更强的机器上进行编译,必要时还可以使用…… 交叉编译 (例如,只需调整架构和相应的工具链,即可在 x86_64 PC 上为 Atom 编译 32 位内核)。然后,只需在目标机器上安装 .deb 文件,并在 GRUB 中添加相应的条目即可。
棘手之处在于维护:建议 在加那利群岛节点上测试新内核在启动管理器中设置清晰的回滚路径,并在转换过程中记录日志和指标,以检测性能或驱动程序兼容性方面的退化。
低延迟系统的抢占模型和 PREEMPT_RT 补丁
内核的抢占模型决定了正在运行的任务可以被中断多少次,以便让优先级更高的任务接管,这直接影响到…… 响应延迟这包括标准配置选项和实时补丁。
通用内核提供多种选项:无抢占(更注重服务器吞吐量)、自愿抢占和 桌面抢占式内核这样可以优先保证交互式应用程序的快速响应时间。调整此设置可以显著提升桌面系统、音频设备,甚至是负载较高的老旧机器的性能。
当您需要进一步操作时,会出现以下内容: PREEMPT 和 PREEMPT_RT 补丁这些修改会改变内核的重要部分,以最大限度地减少不可抢占部分。PREEMPT_RT 适用于最坏情况延迟(而不仅仅是平均延迟)必须非常低且可预测的系统,例如工业自动化、专业音频、电信或高频交易。
引入 PREEMPT_RT 的决定不应基于时尚,而应基于 延迟和抖动的具体测量首先,建议充分利用调度程序设置、CPU 亲和性、sysctl 以及(如果适用)动态无滴答等配置,然后再用 RT 树使维护变得复杂。
兼容性也需要考虑:一些 驱动程序和子系统尚未完全适应实时 可能需要特定版本或额外的补丁。明智的做法是制定维护计划,明确规定何时以及如何将主内核的新版本与RT分支集成。RT分支会定期同步,但仍然会略微滞后。
CPU调度调优、无滴答运行和核心隔离
除了选择抢占模型之外,您还可以通过调整 CPU 调度和内核定时器行为来微调延迟,尤其是在像 RHEL 这样的面向企业的发行版中。
例如,Red Hat Enterprise Linux 8 自带一个 默认情况下,空闲 CPU 的内核不会进行滴答操作。这样可以避免核心空闲时周期性中断,从而降低能耗。可以启用针对延迟敏感型工作负载的模式。 一组内核中的动态无滴答这样,就只有一个 CPU(“主核心”)处理大部分基于时间的任务,其余的 CPU 则尽可能避免周期性中断。
这种配置是通过添加适当的参数来完成的。 GRUB中的内核命令行重新生成配置,然后调整关键内核线程(例如 RCU 线程或线程)的亲和性 bdi-flush以便它们能够驻留在为维护而预留的核心区域。
这种方法可以与参数结合使用。 异亮氨酸这样可以将核心与普通用户空间任务隔离开来。在低延迟场景中,通常会预留几个核心专门用于关键应用程序,而系统的其余部分(守护进程、中断等)则由其他核心处理。
为了验证动态无滴答模式是否正常工作,可以运行简单的测试。 stress 或者编写脚本,让 CPU 保持忙碌一秒钟,然后观察结果。 计时器滴答计数器 在孤立的内核中,每秒中断次数从数千次骤降至仅一次,这表明周期性定时器已经消失。
内存和存储管理,重点关注延迟
内核管理内存和磁盘 I/O 的方式对性能有着巨大的影响。 应用程序感知到的延迟尤其是在执行许多小型且频繁操作的数据库和服务中。
在内存方面,减少 虚拟机交换性 尽量减少交换空间的使用(交换空间几乎总是比内存慢得多), vm.vfs_cache_压 它控制系统清除 inode 和 dentry 缓存的速度,以及 vm.nr_hugepages 它允许为数据库或 JVM 等高负载保留静态 HugePages,从而减少 TLB 开销。
在存储方面,选择 根据磁盘类型选择合适的 I/O 调度器 这至关重要。在现代固态硬盘上,通常最好使用…… none o mq-deadline而在机械磁盘和多任务系统中,为公平性而设计的算法可能更好,例如: BFQ此外,还可以使用诸如以下选项挂载文件系统: noatime y nodiratime 避免每次访问文件或目录时都进行不必要的写入。
关于文件系统, ext4 和 XFS 这些仍然是最常见的选择:经过良好调优的 ext4 文件系统是稳妥之选,而 XFS 在高并发场景下往往具有更好的扩展性。对于要求极高的场景,将 RAID(数据库使用 RAID 10,临时存储使用 RAID 0)与优秀的调度器结合使用,可以降低平均延迟,尤其能有效降低延迟波动。
Linux 和 EC2 中的网络和内核优化,以实现低延迟
在高性能网络应用中,延迟不仅取决于硬件或距离,还取决于…… TCP/IP协议栈和内核本身的配置方式这一点在像 Amazon EC2 这样具有 ENA 接口的云实例中尤为明显。
首先,关键在于减少外部因素,例如……的数量 网络跳数 软件包的性能体现在:使用更直接的拓扑结构、靠近后端的负载均衡器或优化的可用区,甚至可以在接触操作系统之前,将传输时间减少几毫秒。
在内核中,网络配置涉及增加 文件描述符(ulimit -n)调整接收和发送缓冲区的大小 net.core.rmem_max、net.core.wmem_max、net.ipv4.tcp_rmem、net.ipv4.tcp_wmem并激活以下选项: TCP快速打开 减少连接建立延迟。
在 AWS ENA 接口中,中断调节发挥着重要作用:默认情况下,驱动程序将数据包分组以减少 IRQ 的数量。 接收微秒和发送微秒如果您想将延迟降至最低,可以通过以下方式禁用此功能: ethtool -C将 rx-usecs 和 tx-usecs 设置为零可以降低延迟,但会增加中断开销,因此必须根据负载找到一个平衡点。
它也可以使用 irqbalance 用于将 IRQ 分配到多个核心上或者禁用它,并手动将中断和网络队列 (RSS/RPS) 亲和性设置为特定核心,这在超低延迟环境或使用 DPDK 并跳过内核堆栈的大部分时非常典型。
另一个需要考虑的参数是 CPU C 状态深度睡眠状态可以降低功耗,但会在核心“唤醒”时引入延迟。为了减少响应延迟,您可以限制深度睡眠状态的持续时间,但这会造成更高的功耗,并降低其他核心睿频加速的可用空间。每种环境都有其最佳的功耗和延迟之间的平衡点。
优化 CPU、服务和应用程序以降低延迟
除了内核本身之外,周围环境对整体延迟也有很大影响:从 系统中的活跃服务 具体到每个应用程序的具体配置。
高性能服务器应该只运行 真正必要的恶魔后端机器上的蓝牙、打印或网络自动发现(CUPS、Avahi 等)等服务只会消耗 CPU、内存和 I/O 资源,却没有任何实际收益。 systemctl list-unit-files --state=enabled 禁用不必要的功能是最便宜、最有效的方法之一。
为了优先处理关键流程,您可以使用以下工具: renice、chrt 和 taskset调整进程的优先级(renice)、赋予其实时调度(chrt -f 99)或将其分配给特定核心(taskset)可以减少对其他任务的干扰,从而提高数据库、VoIP、流媒体或交易服务的 CPU 可预测性。
在应用层,调优与内核调优同等重要。例如,Web 服务器 Nginx 或 Apache 他们需要对工作进程、保持连接机制、缓存和压缩进行微调。数据库如 PostgreSQL 或 MySQL 他们需要审查缓冲区大小、检查点、连接池和同步写入参数,以实现低而稳定的延迟。
JVM 也发挥着作用:选择垃圾回收器,例如 G1GC 或 ZGC 调整堆大小可以减少暂停,从外部视角来看,这些暂停表现为延迟。在虚拟化和容器化环境中,合理的内存分配至关重要。 虚拟CPU、虚拟内存和I/O配额 它避免了无声争用,而这种争用之后会在磁盘上表现为无尽的队列或 CPU 饱和。
内核和系统监控与基准测试
如果不衡量其影响,所有这些调整都毫无意义。关键在于综合运用。 通过可复现的性能测试进行持续监测。这样,对内核或 sysctl 的每一次更改都可以用客观数据进行评估。
要查看系统的整体状态,您可以使用诸如以下经典工具: htop、vmstat、iotop o sar当您需要更多详细信息时,就需要使用特定的内核工具,例如 perf 和 ftrace这使您可以相当准确地跟踪调度程序、中断和内部调用的行为。
在生产环境中,建议部署诸如以下的指标系统。 Prometheus、collectd 或 sysstat 以及导出器 它可以显示 CPU 计数器、I/O、磁盘和网络延迟、进程队列等信息。这些数据在 Grafana 或类似工具中可视化,有助于在最终用户注意到问题之前检测到回归或异常情况。
对于基准测试而言,其理念是复制实际工作负载,并比较每次更改前后的结果。诸如此类的工具 系统工作台 (适用于CPU和数据库) FIO (用于光盘) iperf3 (对于网络而言)它们允许构建可重复的场景。文档记录至关重要。 内核版本、sysctl 配置、硬件和测试参数 这样,随着时间的推移,比较结果才有意义。
实际上,Linux 内核优化是一个迭代过程:你需要测试一系列调整,衡量结果,保留真正有效的调整,并舍弃其余部分。通过良好的变更管理,你可以将新内核版本(例如最近几个版本在调度器、图形、电源或网络方面的改进)中的提升转化为应用程序可衡量的性能收益,无论这些应用程序部署在本地服务器、云端还是高要求的工作站上。
内核架构知识、使用 sysctl 进行微调、受控编译、选择性地使用实时补丁以及良好的指标体系相结合,能够帮助管理员或运维团队实现以下目标: 更快的响应速度、更低的延迟和更高的整体稳定性 无需因轻微挑衅而更换硬件,也不会损害系统安全。