麒麟、统信操作系统性能优化之内核优化（同行共识总结）

一般建议使用发布的新版本kernel，修复bug、安全及性能问题。可以以集群级别作为升级的单位，针对单个集群/单个业务系统进行升级，做比对测试。如果有差异，则择优选择。

以我司为例，在使用过程中出现的问题，我们会对比差异，如有必要升级，则后续新装版本直接升级，旧有系统则暂时保持不变，只处理有问题机器，再在经运维、基础设施、OS团队评估后合适时间统一做升级。

对于因硬件兼容性导致的问题，一般不做内核升级，而是通过kernel module做更新管理，这样就避免版本的变化，但带来弊端是需要对模块升级做记录，并持续追踪，增加了管理成本。

◉ Ciao：

目前信创操作系统的更新也较多，但是对于生产系统来说，主要追求稳定性，对于内核及打本更更新一般会伴随系统测试，耗时耗力。对于系统版本的更新建议考虑基本方面:

1、 重大安全漏洞需要全量更新。

2、 系统bug需要分析bug触发原因，如果生产系统无触发风险，建议不更新，反之则要更新。

3、 建议生产上系统版本维持在2-3个，否则会提高维护的复杂性。

4、 操作系统以稳定为主，系统稳定以后，无安全风险的补丁尽量不要打。

◉ 三虎：

◉ Ciao：

服务器操作系统

（1） 从性能层面：麒麟服务器操作系统对关键业务具备更高的承载能力，且兼容主流国产数据库、中间件，提供企业级高可用集群解决方案及增强的安全性能。

（2）成熟度层面：麒麟服务器操作系统已在大型证券公司、银行、保险等金融机构核心系统中获得大量应用， 对恒生、同花顺等交易软件适配并稳定运行。

（3）从案例层面，麒麟服务器操作系统市场占有远远大于统信服务器操作系统，更受市场认可。

桌面操作系统

（1） 办公生态层面：统信桌面操作系统，依托于自己的社区，在自主开发能力、持续改造能力、版本更新能力强。

（2）适配性层面：统信的操作系统及其配套的组件均为自主研发,而且采用了异构同源的技术架构支持不同的CPU架构，可以大大降低应用迁移成本。统信通过Deepin-Wine技术，可以实现对windows应用的迁移，并且完成 11 万余款的外设适配，适配性更好。

（3）行业案例层面，统信桌面操作系统市场占有远远大于麒麟桌面操作系统，更受市场认可。

但是麒麟桌面系统依托于服务器操作系统，在性能兼容性上发展很快，对于选型上可以对比测试。

◉ 三虎：

几个方面去考虑该问题：

1、生态建设，把这个作为第一要义，说明产品是否能用，是我们支持xc的大前提，比如你需要打印文件，但软件库里没打印机驱动，从功能都不能满足的话，再谈好不好用等就是白搭了。所以：

1）对于桌面产品，生态市场中的各类软件是否足够丰富，是否满足客户的需求，软件升级迭代的速度，都是考量产品的核心因素，因为既然是桌面产品，受众人是很多的，一旦投产，再想换就比较费劲了。

2）对于服务器产品（包括容器底座、云底座），对计算类、网络类、存储类硬件产品的适配兼容，是需要进行确认甚至进行POC测试的，比如某操作系统，长期运行稳定，但随着xc产品引入，虽然也说能用，但经常出现网络卡顿、中断情况，软硬件商均表示产品无问题，但二者摆到一起，兼容上就出现了问题，不能使用。

2、源头社区，即发行版的上游社区，比如欧拉、龙蜥等开源社区，开源社区的贡献度、成熟度、迭代速度等将直接影响各家发行版产品，所以跟对了“老大”，产品的更新维护就省心很多，比如不少CPU会经常加入新特性来提升性能和修 复 缺陷，社区如果及时更近并发布相应补丁包，用户也可以及时获得同步。

3、安全稳定，既然是xc产品，那就要尽可能提高安全，为国家安全做贡献。所以漏洞少、安全加固好的产品，是我们更应该选择的。哪家产品在漏洞修复方面更加全面，漏洞修复发布更及时，哪家产品的安全加固策略更加丰富，是衡量安全性的重要指标。稳定性方面，通过各种应用场景下的疲劳测试来确认运行状况，或者通过同业调研来发现特定组合场景下的问题缺陷。

4、技术服务能力，随着国家大力发展xc，各类软硬件产品层出不穷，那在适配中出现的问题，客户提出的个性化需求，各种组合创新的需求等等，这些都提到产品的技术服务那里，对于操作系统后线是一个巨大的考验，技术团队是否能在一定时间内解决各类问题，也是需要重点考察的方面。

5、成本问题：这没什么好说的，采购时总要在技术和财务之间做平衡；

◉ Ciao：

传统Linux 在开启 tcp_timestamps和tcp_tw_recycle 是会存在问题 ，因为tcp_timestamps缺省就是开启的，所以当tcp_tw_recycle被开启后，实际上这种行为就被激活了，触发PAWS机制，在NAT环境下就会有概率丢包。对于高并发短连接环境，由于会产生大量time_wait状态连接，可能会引发端口耗尽，可以考虑连接 快速回收 或者 链接复用 进行优化。调整 tcp_max_tw_buckets ， 在TIME_WAIT 数量等于 tcp_max_tw_buckets 时，不会有新的 TIME_WAIT 产生 。在time_wait数量等于此参数时，就会快速回收，对端会收到一个reset包，由于time_wait就是连接关闭阶段，连接注定要关闭，所以也不会有什么问题。tcp_tw_reuse ， 在 收到最后一个包后超过1s，可以达到快速复用TIME_WAIT状态的socket链接 。

◉ 三虎：

1、调整网卡的ringBuffer大小。接收数据包后，首先会通过DMA引擎将数据送到RingBuffer中。使用ethtool -g <网卡名>可查看RingBuffer的大小。RingBuffer是收发中转站，如果瞬间接收的请求数超过了软中断（ksoftirqd）处理能力，那在RingBuffer填满后，再来的包会被网卡直接丢弃。丢包的统计查询：ethtool -S <网卡名>

2、多队列网卡RSS调优。网卡的每个队列对应一个中断进程，即一个CPU来处理中断，如果队列数越多，也就会有更多的CPU参与到数据包的接收上来。详细信息可查看/proc/interrupts。中断号和CPU的对应关系通过smp_affinity网卡亲和性来控制的，一般通过irqbalance服务来自动管理，即中断进程尽量都使用不同的CPU来poll包。所以通过查看当前配置和支持的最大队列数（ethtool -l <网卡>），来调大网卡队列数(ethtool -L <网卡>)，将提高数据接收的性能。

（*注意：这里针对信创环境下的调优需要特别说明！部分国产品牌的CPU，在跨路访问方面，会有高延迟问题，之前在别的回答中也提到，使用NUMA绑定来减少跨路访问。但在一些批处理高IO的场景下，并不能完全解决问题，网卡队列池满、主机卡顿也会偶尔出现，针对此，关闭irqbalance服务，调整中断进程的亲和性（/proc/irq/<中断号>/smp_affinity），将网卡中断号都固定到一个物理CPU的不同core上，将能避免跨物理CPU的网卡中断。如主机有2颗CPU，CPU 0对应的core id为0-31，如果主机有64个中断进程，可以对0-31顺序挑选，并写入到/proc/irq/<中断号>/smp_affinity文件中，减少网卡中断的跨路。)

3、合并参数的优化。检查网卡的硬中断合并是否打开（ethtool -c <网卡>），看Adaptive是否为on；接收处理合并是否打开(ethtool -k)， 确认receive-offload是否为on；

4、优化软中断一次处理的包数量。内核参数net.cor.netdev_budget来控制，增加这个值，让CPU每次多处理一些网络包接收工作，再让出CPU，以提高效率。

5、使用mmap或sendfile等系统调用来减少用户态和内核态之间的内存拷贝。

6、TCP三次握手优化，在内核参数上，加速端口回收，开启端口重用等，但需要注意在NAT下参数配置防止冲突，可能会因为包的时间戳问题，导致后发送的包先到，进而造成先发的包因为晚到而被丢弃。

7、大招，ebpf可以绕开协议栈的本地网络IO，其实数据包送到网卡，直到送给应用程序这中间的环节好开销还是很多的。那么如果能利用ebpf的sockmap等，将大大提高效率。

◉ Ciao：

高并发优化策略方法论与传统linux操作系统类似，都是从硬件、系统参数、网络、 存储、应用这几个方面考虑。

硬件优化：

垂直扩展：提升单机处理能力，如增加CPU核数、升级更好的网卡（如万兆网卡）、升级更好的硬盘（如SSD）并扩充硬盘容量、扩充系统内存等。

水平扩展：通过增加服务器数量来线性扩充系统性能。这可以使用负载均衡器来分发请求到多个服务器上。

系统配置优化：

文件句柄限制：Linux内核为每个进程都有一个文件描述符(file descriptor)数组。在高并发场景下，进程所需的文件描述符数量会增加。可以通过 ulimit -n 命令来调整文件句柄限制。

进程数量限制：在高并发场景下，进程数量可能会增加。可以通过修改/etc/security/limits.conf 文件来调整进程数量限制。

TCP/IP参数优化：

对于TCP/IP连接，可以调整相关的内核参数来提高性能，如 net.ipv4.tcp_synack_retries 、 net.ipv4.tcp_max_syn_backlog 等。

I/O调度器 ：选择合适的I/O调度器（如NOOP、DEADLINE、CFQ、BFQ等）以适应不同的工作负载。

网络优化：

负载均衡：使用负载均衡器来分发请求到多个服务器上，以实现水平扩展。

连接池：使用连接池来复用TCP连接，减少连接建立和断开的开销。

压缩传输：使用压缩算法（如gzip、brotli等）来压缩传输的数据，减少网络带宽的使用。

应用程序优化：

使用事件驱动（如select/poll/epoll/kqueue等）的非阻塞IO模型或操作系统级别的异步IO接口（如posix的aio系列函数）来减少线程数目和上下文切换的开销，同时能够处理大量并发连接。

◉ 三虎：

处理高并发场景，还是需要具体区分高并发下，对主机哪些资源消耗过高，再进行有针对性的调优：

1、高并发造成网络IO压力，如果每个TCP连接本身消耗服务端的内存过高，则大量并发场景下，可能会导致内存资源过度消耗，而无法处理新的请求，则需要扩容内存，这里推荐《信创操作系统层面tcp短时高并发短连接应当如何调优？》帖子中的回复；（https://www.talkwithtrend.com/Question/466725）

2、高并发带来的CPU资源不足，如果每个请求所需要的计算资源较多，推荐《信创操作系统层面提供的CPU性能应当如何优化？》帖子中的回复内容；（https://www.talkwithtrend.com/Question/466727）

3、高并发带来的磁盘IO负载过高，如瞬时的批量写入读出等，这种连续的大IO操作，建议调大磁盘预读块大小，在操作系统层没有太多太好的手段，可以考虑在存储侧增加不同层级的缓存大小，如增加控制器缓存或增加SSD缓存空间等来提高整体IO性能；

4、如果高并发对后端数据库造成压力，需要从数据库读写SQL上做文章，确认是否有全表扫描等情况发生，业务处理逻辑是否有优化空间；

◉ 陈成：

CPU：

kernel.sched_min_granularity_ns

内存：

vm.vfs_cache_pressure

vm.dirty_ratio

vm.dirty_background_ratio

vm.swappiness

网络：

设置calico网络mtu

ip link set dev eth0 mtu 9000;ip link set dev eth0 mtu 9000

net.core.somaxconn

net.ipv4.tcp_keepalive_time

net.bridge.bridge-nf-call-iptables

net.bridge.bridge-nf-call-ip6tables

net.ipv4.ip_forward=1

文件系统：

vm.dirty_writeback_centisecs

◉ Ciao：

◉ 三虎：

针对前、中、后端的业务请求数、数据处理类型、长短链接等方面，是有较大差异的，在网络参数上至少是可以形成不同的参数规范。

针对云底座、容器底座、裸金属、虚机等四个不同应用场景，在使用上存在较大差异，如云底座更关注云平台、硬件之间适配兼容，容器底座涉及防火墙配置也要求更加轻量化等，虚机相比物理机可使用的资源更少，故在部署上、参数模型方面应都有不同的规范。

针对计算密集型和大IO等类型，参数规范差异也很大，操作系统本身的调优场景（tuned）就支持性能吞吐模式（throughput-performance）和网络吞吐模式（network-throughput），可用的策略如下，供参考：

Available profiles:

• atomic-guest - Optimize virtual guests based on the Atomic variant

• atomic-host - Optimize bare metal systems running the Atomic variant

• balanced - General non-specialized tuned profile

• cpu-partitioning - Optimize for CPU partitioning

• default - Legacy default tuned profile

• desktop - Optimize for the desktop use-case

• desktop-powersave - Optmize for the desktop use-case with power saving

• enterprise-storage - Legacy profile for RHEL6, for RHEL7, please use throughput-performance profile

• laptop-ac-powersave - Optimize for laptop with power savings

• laptop-battery-powersave - Optimize laptop profile with more aggressive power saving

• latency-performance - Optimize for deterministic performance at the cost of increased power consumption

• mssql - Optimize for MS SQL Server

• network-latency - Optimize for deterministic performance at the cost of increased power consumption, focused on low latency network performance

• network-throughput - Optimize for streaming network throughput, generally only necessary on older CPUs or 40G+ networks

• oracle - Optimize for Oracle RDBMS

• powersave - Optimize for low power consumption

• sap-hana - Optimize for SAP HANA

• sap-hana-vmware - Optimize for SAP HANA running inside a VMware guest

• sap-netweaver - Optimize for SAP NetWeaver

• server-powersave - Optimize for server power savings

• spindown-disk - Optimize for power saving by spinning-down rotational disks

• throughput-performance - Broadly applicable tuning that provides excellent performance across a variety of common server workloads

• virtual-guest - Optimize for running inside a virtual guest

• virtual-host - Optimize for running KVM guests

◉ 陈成：

同样遇到过这种场景，在我们的一些老旧机器中，内核驱动曾经做过升级，在进行原地迁移替换后，出现了异常，导致无法在信创os上使用，后通过进行kernel module形式进行处理，给我们也提了个醒，后续迁移前务必确认内核module的版本变化情况，在操作系统变更管理中持续记录内核模块变更情况，以避免未知情况发生，确保系统稳定性和可靠性。

同时，即使是内核模块升级变化，也做好测试验证工作，其实是与原问题解决情况对比，并避免引入新的问题的过程。

◉ Ciao：

内核升级时建议做适配性测试，在满足兼容性要求的情况下进行升级。Linux内核升级可以带来许多好处，如提高对新设备的兼容性、修补原有系统内核的漏洞、提高系统的稳定性等。但也具有一定的风险，系统管理员需要谨慎考虑，并确保了解升级的目的和可能带来的风险。

一般内核升级会向下兼容设备驱动，但也不排除有特殊情况。有些驱动对内核版本是有要求的，断然升级内核可能会导致不兼容的情况。升级之后，系统中的驱动程序是否能够正确地识别并控制这些硬件设备，如果驱动程序与新的内核版本或硬件设备不兼容，那么这些硬件设备可能无法正常工作。建议升级之前做好兼容性测试，确保无误后再进行内核升级

◉ 三虎：