麒麟、统信操作系统之实践案例难点及硬件优化（同业交流共识总结）

字数 10063阅读 4004评论 3赞 1

内容摘要：

国产操作系统需面对技术和运维挑战，建立自身知识体系和经验沉淀，提供有效技术支持，增强用户信任度。针对中间件和数据库，可通过内核调优等方式提升系统性能，针对CPU性能优化，可进行绑核中断、屏蔽硬中断、调整内核参数等，最终实现性能优化。

当前摘要为AI生成

##一、导语
以国产化为核心的信创操作系统现正加速全面普及。 金融行业以某保险单位为例，下发的信创设备及其系统应用对一般用户而言面临一定 程度的难题和痛点。如国产化数据库匹配的可靠性差异、中间件的可扩展性、软硬件的运行等等。因此从系统性能、可扩展性、安全性、可维护性等多个维度综合考虑，信创操作系统的架构必须不断优化，以贴合信创用户更多形式的使用需求。
 
 目前金融行业的信创部署正全速推进，信创操作系统的重要性不言而喻：首先基于国产化理由，它能真正 提升总体信息安全水平，再者它符合国家法律法规要求，助力企业合规经营；最后它将必促进与其产业相关企业的技术进步，提高企业在本领域的自主研发能力和国内竞争力。

本期"麒麟、统信操作系统共建知识库之内核调优” 知识库建设，邀请了多位社区技术专家一同参与线上的交流探讨，本期重点从操作系统优化的实践案例与难点及硬件优化方面交流进行总结。

> **主稿嘉宾：**  
张晓斌 某金融保险 信息技术部科技支持岗   
**互动嘉宾 ：**  
三虎 中国邮政储蓄银行 系统运维工程师   
Ciao 某大型证券 系统架构师   
陈成 中国联通软件研究院 研发工程师

##二、议题研讨内容
###问题1：咨询下麒麟操作系统内核优化有没有实践案例？
随着国产化服务器操作系统推广普及，越来越多的企业使用了麒麟操作系统，其上可能运行常用中间件（如东方通、nginx、tomcat等）、国产化数据库（如GaussDB、goldendb、TiDB、达梦等），有无相关的内核优化实践案例？

**嘉宾 Ciao 架构师 某证券公司：**
在GaussDB的部署过程中，针对性的对操作系统层面进行如下调优设置，提升系统性能。  
1、关闭SELinux，/etc/selinux/config文件中的“SELINUX”值为“disabled”。关闭SELinux可能会解决兼容性问题、简化配置和提高性能。 
2、关闭swap交换内存，避免数据库使用交换分区而引起的数据库性能下降。  
3、关闭RemoveIPC。当RemoveIPC参数设置为yes时，操作系统会在对应用户退出时删除IPC资源（共享内存和信号量），从而使得数据库服务器使用的IPC资源被清理，引发数据库宕机。 
4、升级audit版本，audit进程默认开启，默认版本长期运行后会自动占用大量内存，影响系统使用。  
5、系统内核参数调优。GaussDB安装过程中，针对系统内核参数做如下调优设置：

|   |   |   |
| ------------ | ------------ | ------------ |
| 参数名称 | 参数说明 | 推荐取值 |
| net.ipv4.tcp_max_tw_buckets | 表示同时保持TIME_WAIT状态的TCP/IP连接最大数量。 | 10000 |
| net.ipv4.tcp_tw_reuse | 允许将TIME-WAIT状态的sockets重新用于新的TCP连接。 | 1 |
| net.ipv4.tcp_tw_recycle | 表示开启TCP连接中TIME-WAIT状态sockets的快速回收。 | 1 |
| net.ipv4.tcp_keepalive_time | 表示当keepalive启用的时候，TCP发送keepalive消息的频度。 | 30 |
| net.ipv4.tcp_keepalive_probes | 在认定连接失效之前，发送TCP的keepalive探测包数量。 | 9 |
| net.ipv4.tcp_keepalive_intvl | 当探测没有确认时，重新发送探测的频度。 | 30 |
| net.ipv4.tcp_retries1 | 在连接建立过程中TCP协议最大重试次数。 | 5 |
| net.ipv4.tcp_syn_retries | TCP协议SYN报文最大重试次数。 | 5 |
| net.ipv4.tcp_synack_retries | TCP协议SYN应答报文最大重试次数。 | 5 |
| net.ipv4.tcp_retries2 | 控制内核向已经建立连接的远程主机重新发送数据的次数。 | 12 |
| vm.overcommit_memory | 控制在做内存分配的时候，内核的检查方式。 | 0 |
| net.ipv4.tcp_rmem | TCP协议接收端缓冲区的可用内存大小。 | 8192 250000 16777216 |
| net.ipv4.tcp_wmem | TCP协议发送端缓冲区的可用内存大小。 | 8192 250000 16777216 |
| net.core.wmem_max | socket发送端缓冲区大小的最大值。 | 21299200 |
| net.core.rmem_max | socket接收端缓冲区大小的最大值。 | 21299200 |
| net.core.wmem_default | socket发送端缓冲区大小的默认值。 | 21299200 |
| net.core.rmem_default | socket接收端缓冲区大小的默认值。 | 21299200 |
| net.ipv4.ip_local_port_range | 物理机可用临时端口范围。 | 26000-65535 |
| kernel.sem | 内核信号量参数设置大小。 | 250 6400000 1000 25600 |
| vm.min_free_kbytes | 保证物理内存有足够空闲空间，防止突发性换页。 | 系统总内存的5% |
| net.core.somaxconn | 定义了系统中每一个端口最大的监听队列的长度。 | 65535 |
| net.ipv4.tcp_syncookies | 启用cookies来处理，可防范少量SYN攻击。 | 1 |
| net.core.netdev_max_backlog | 在每个网络接口接收队列的数据包的最大数目。 | 65535 |
| net.ipv4.tcp_max_syn_backlog | 记录的那些尚未收到客户端确认信息的连接请求的最大值。 | 65535 |
| net.ipv4.tcp_fin_timeout | 系统默认的超时时间。 | 60 |
| kernel.shmall | 内核可用的共享内存总量。 | 1152921504606840000 |
| kernel.shmmax | 内核参数定义单个共享内存段的最大值。 | 18446744073709500000 |
| net.ipv4.tcp_sack | 启用有选择的应答。 | 1 |
| net.ipv4.tcp_timestamps | TCP时间戳。 | 1 |
| vm.extfrag_threshold | 系统在内存碎片的处理倾向。 | 500 |
| MTU | 节点网卡最大传输单元。调整为8192可以提升数据收发的性能。 | 8192 |

**嘉宾 三虎 系统运维工程师 中国邮政储蓄银行：**
其实一些大厂，针对各个操作系统，会在使用中，不断总结并形成自己的配置规范（又有称基线、母袋），主要解决：  
1）统一的部署规范，确保同一版本下配置一致，便于后续的管理、维护；  
2）解决生产安全问题，规范涵盖安全要求，如密码强度、漏洞修复等方面的需求；  
3）厂内要求的个性化配置，如配合监控等做一些特定的调整等；

提问中提到的常用中间件或国产化数据库，其实在其官网都会有软件部署环境的要求，其中就包括了操作系统参数调优。

目前了解到，GaussDB在调优时，推荐使用4K页块大小（PAGESIZE），在OLTP场景下，读写性能更优，所以如果默认是64K需重新编译4K'内核后，再对内核升级，同时调整页大小会导致swap失效，需重新格式化后挂载。

###问题2：麒麟和统信操作系统性能优化遇到了哪些挑战？
**嘉宾 Ciao 架构师 某证券公司：**
1、 技术层面。由于基于新内核，且信创操作系统一般会运行在arm等非x86架构的cpu之上，会产生一些新问题。例如，使用arm的cpu，通常numa架构下会有很多numa节点，相较于x86来说，arm numa本地内存就少很多，对于需要大内存，高性能访问内存的场景就会产生性能问题。

2、 运维层面。多数系统性能优化手段都可以借鉴以往例如红帽等操作系统的运维经验，但是由于是新内核，稳定性不如现有商业发行版，而且目前麒麟的技术支持弱于传统厂商，在日常运维偶尔会发现内核崩溃，基础服务bug等问题，这些目前只能在一定周期的积累下，修复产品问题，等待一个稳定版本。

**嘉宾 actor168 研发工程师 中国联通软件研究院：** 
1.技能挑战：xc商业服务器操作系统缺少完善的开放知识体系和历史经验沉淀，导致遇到问题时，难以靠历史经验去发现和解决问题，厂家往往难以提供有效技术支持，导致问题难以快速解决。

解决方案：目前主要依托自建知识库，centos下运维经验联合分析定位，或直接与centos下同场景做对比测试，再进行细节定位；

2.信任度挑战：xc操作系统毕竟是现在推广期，一旦有些问题，总是会让用户不信任不满意，很难推行，通过各种理由拒绝调试，甚至拒绝再使用，导致没有机会进行调优。

解决方案：完善操作系统运维工具，尽量早发现问题，细粒度定位问题，通过专业工具，给出问题根因，协助排障。

**嘉宾 三虎 系统运维工程师 中国邮政储蓄银行：** 
个人拙见，目前麒麟、统信操作系统在性能优化方面的挑战，是软硬件之间独立开发，完成后再进行适配，没有根据彼此特性进行调优。操作系统没有针对当前信创主流的芯片的特性展开内核级的优化。特别是国产芯片有一些功能做了阉割，那操作系统就应该对这部分做简化；有一些特性功能，那操作系统就应该去适配修改，发挥其特性。 大多数操作系统厂商，基于现有的开源社区，做了一些封装，与绝大部分硬件可适配兼容，但如上所述，没有深入适配，故在性能上的提升也是有限的。 目前操作系统层优化，还是在原x86的经验上提出的，也没有形成如ARM架构的，或者国产芯片等特有的调优方案。 就以往经验来看，从基础资源的角度，即CPU、内存、磁盘IO、网络IO，来讨论性能的优化：

1.CPU性能优化可参见： [信创操作系统层面提供的CPU性能应当如何优化](https://www.talkwithtrend.com/Question/466727 "信创操作系统层面提供的CPU性能应当如何优化")

2.内存方面的优化，在CPU性能优化中也有提及，即NUMA绑核可以提高CPU访问内存效率，有效降低延迟；另外优化内核参数，提高内存释放、脏块的回收、减少swap的使用，数据库场景下开启大页，另外应用程序本身，在编写时遵循代码规范，根据业务场景优化内存的申请、访问、释放效率。

3.磁盘IO方面，根据业务决定是打开或关闭CPU预取功能，大IO场景下，提高磁盘预读块大小；

4.网络IO方面，主要调优和tcp连接相关的内核参数和网卡配置参数等，如会话保持的时间，中间态（CLOSE_WAIT，FIN1，FIN2）的超时时间，连接是否重用，网卡缓存大小，网卡队列深度；云平台层还有流表的大小或出入安全规则的信息是否记录，是否使用防火墙等内容。

上述提到的主要还是传统的调优方式，也如题所述，国产化道路上的优化什么时候能走出自己的路，还需要一定时间的沉淀和积累。 
###问题3：这两个操作系统如何针对不同的硬件架构进行性能优化？
**嘉宾 Ciao 架构师 某证券公司：** 
目前主要的优化思路主要是根据系统上部署的软件进行调优以及BIOS调优。   
BIOS调优：关闭SR-IOV（Single Root I/O Virtualization），关闭虚拟化，Power Regulator：Static High Performance，No C-states模式等等。

还有一点需要注意的是，arm cpu由于numa节点众多，单节点本地内存数量有限，对于大内存访问如数据库等，会存在跨节点内存访问，或者本地内存耗尽导致使用swap的情况，对于大内存访问的应用建议将arm的numa特性关闭。

**嘉宾 waring_id 技术经理 某公司**
X86 的比较通用，资料也比较多 ，arm 架构的比较少
1、基础部分聚焦在操作系统的兼容（特别是硬件驱动，例如网络、硬盘、各种接口等），同时注意不同版本的基础软件优化（例如数据库、中间件等）
2、进阶的部分包括内核优化（内核驱动精简等）、编译环境（例如libc++等中间库）和对应的优化版本等，动态链接文件等
3、对应的应用层面的优化。包括编译环境、动态库引用、中间件依赖、底层硬件驱动等体系化考虑

**嘉宾 三虎 系统运维工程师 中国邮政储蓄银行：**
我理解这里的硬件架构，是指CPU架构，那就包括了x86、arm、c86、MIPS等区别。  不同芯片厂家会根据自身产品特性，不定期发布补丁，各操作系统厂商应及时将补丁融合到内核版本中，以修复产品缺陷。

另外各芯片推荐的操作系统配置，可根据实际在生产中应用。

具体来说，针对飞腾芯片，可以进行如下优化：  
一、关闭SMMU  
如果使用SMMU的地址转换功能，在硬盘达到一定峰值时，可能会出现掉盘问题，需在操作系统层面关闭SMMU。  
对于个别品牌服务器，开启SMMU可能会导致RAID卡故障，建议在BIOS中关闭SMMU。  
关闭SMMU具体操作方法如下：  
操作系统层面关闭SMMU：  
在 /etc/default/grub里配置iommu.passthrough=1  
cat /etc/default/grub | grep iommu  
GRUB_CMDLINE_LINUX="crashkernel=512M rd.lvm.lv=vg00/lv_root rd.lvm.lv=vg00/lv_swap **iommu.passthrough=1** transparent_hugepage=never console=ttyS0,115200n8 console=tty0"

二、升级内核  
1） SMMU内核补丁：解决设备分组问题，在操作系统下看PCIE设备默认在一个分组，虚拟化设备透传无法实现，打补丁解决PCIE设备在操作系统内分组问题，以支持虚拟化设备透传功能；  
2） 增加飞腾芯片支持：在飞腾S2500服务器上主要解决了对双路的支持问题；  
3） 飞腾中断堆积补丁：解决在中断数量很多的场景下中断堆积在一个CPU核心的问题，均分中断到其他CPU核心；  
4） 飞腾kdump功能开启：解决kdump功能在S2500服务器无法正常使用的问题；  
5） 飞腾kdump功能补丁：解决在一定场景下vmcore无法存储的问题，作用为保证kdump的内核在每个socket上都有核心启动；  
6） 飞腾S系列服务器中断控制器驱动更新：S系列服务器中断控制器逻辑优化。

三、网卡中断绑核优化  
默认情况下，Linux中断响应会被平均分配到所有CPU核心上，势必会发生写新的数据和指令缓存，并与CPU核心上原有进程产生冲突，造成中断响应延迟，影响进程处理时间。为了解决问题，可以将中断（或进程）绑定到指定CPU核心上，从而提高中断响应（或进程）的处理速度。  
相比使用内核的irqbalance（中断均衡）使网卡中断在所有核上进行调度，使用手动绑核将网卡中断绑定在固定的核，能有效改善网络情况。

四、JDK优化  
在ARM架构下，推荐使用华为毕昇JDK来代替OpenJDK。毕昇JDK在ARM架构上进行了性能优化和稳定性增强，在ARM架构上更稳定，在大数据等场景下可以获得更好的性能。2023版开源软件目录清单推荐使用BishengJDK8u292和BishengJDK11.0.11版本，具体使用版本参考最新开源软件目录清单。

###问题4：信创操作系统层面提供的CPU性能应当如何优化？
**嘉宾 Ciao 架构师 某证券公司：**
绑定核心   
中断是CPU Core收到的，可以让关键线程绑定在某个Core上，然后避免各种中断源（IRQ）向这个Core发送中断。   
绑定程序在一个核上运行，有两种方法：taskset和sched_setaffinity，其中sched_setaffinity是程序代码对绑核的实现，我们主要介绍通过taskset进行绑核。

CPU Affinity   
CPU亲和性，是指在SMP结构下，能够将一个或多个进程绑定到一个或多个处理器上运行。   
查看进程分配的CPU Core，可以使用taskset命令查看：   
taskset -c -p   
该CPU亲和力列表表明该进程可能会被安排在3-5中任意一个CPU Core上。   
更具体地查看某进程当前正运行在哪个CPU Core上，我们可以使用top命令查看：   
top -p   
taskset   
使用taskset命令将进程绑定到指定核，比如将31693绑定到1，2，3核上   
taskset -cp 1,2,3 31693   
该例会将PID为31693的进程绑定到1-3核上运行。

屏蔽硬中断（硬盘、网卡）   
中断源（IRQ）向CPU Core发送中断，CPU Core调用中断处理程序对中断进程处理。我们可以通过改写/proc/irq/*/smp_affinity文件，避免中断源（IRQ）向某些CPU Core发送中断。该方法对硬盘、网卡等设备引起的硬中断有效。

SMP_AFFINITY   
SMP，即symmetric multiprocessing（对称多处理器），通过多个处理器处理程序的方式。smp_affinity文件处理一个IRQ的中断亲和性。我们可用/proc/irq/{IRQ_NUMBER}/smp_affinity_list来制定所需要绑定的核，这里的IRQ_NUMBER就是前面中断输出中的IRQ号,比如我们想将ens160的所有中断绑定到CPU1和CPU2。

内核参数   
Watchdog   
Watchdog在进行监控的过程中会触发中断，会引起抖动，可通过以下命令进行关闭：
echo 0 > /proc/sys/kernel/watchdog
sched_latency_ns
指定在发生任务切换之前，任务可以在一个 CPU 核心上运行的最长时间（以纳秒为单位）
echo 24000000 > /proc/sys/kernel/sched_latency_ns
sched_min_granularity_ns
指定了最小的时间粒度（以纳秒为单位）不会被抢占的时间，在这个时间粒度内，一个任务可以在一个 CPU 核心上运行。
echo 10000000 > /proc/sys/kernel/sched_min_granularity_ns
sched_rt_runtime_us
用于控制系统中实时任务的运行时间片（以微秒为单位）,默认值为950000，总共为1000000。设置为-1则禁止这个限制。
echo -1 > /proc/sys/kernel/sched_rt_runtime_us
stat_interval
以秒为单位的更新虚拟内存统计信息的间隔。默认值是 1 秒，这导致每秒进行信息统计。将其更改为 1000 秒可以避免这些中断，至少延迟了 16 分钟。

调频策略
scaling_governor调配策略的作用是控制CPU如何管理和调整其运行频率以平衡性能和能耗，同以下命令，选择“performance”使CPU保持在最高频率，以提供最大的计算性能。
echo performance > /sys/devices/system/cpu/cpu57/cpufreq/scaling_governor

**嘉宾 三虎 系统运维工程师 中国邮政储蓄银行：**
对于CPU的性能调优，可以从两个角度着手：
一是找出不必要的工作，降低工作负载；
二是提高目前CPU的性能上限；
**对于第一种情况**，通过对CPU使用的观测分析，去优化相关应用程序。常用的分析方法可以是“工具法”，“USE方法”。

1）可以遍历操作系统现有的统计分析工具，如 top\\vmstat\\mpstat\\pidstat\\perf 等，排序CPU占用进程、栈跟踪等；

2）使用USE方法（Utilization Saturation and Errors Method），检查CPU的使用率、饱和度、错误。

3）基于1、2结果，通过cgroup资源控制，或nice等级设定，按照用户或进程粒度，来压降某些应用的CPU占用，从而控出更多CPU资源。

**第二种情况，有如下几种方式：**
1）固化CPU的频率，为了节能降耗，一些设备在出厂后将CPU模式置为均衡模式，在空闲情况下CPU主频较低，需要在持续的高密集运算后升高频率。在BIOS层面，调整CPU的电源策略调整为Performance（最大性能），此时无动态调频，可保持运行在标称频率。

2）第一步完成后，确认是动态调频器是否为性能模式：
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
确认值是否为performance，如果不是，则修改。

3）xc环境下，部分CPU产品的跨路访问延迟问题，相较于Intel，还是比较大的，多核 CPU 服务器，可开启 NUMA 绑核功能。在资源条件充裕的情况下，可考虑使用NUMA绑核有提高性能。通过 BIOS 选项开启绑核支持。在云环境下，需要在平台侧配置绑核；物理机层可通过numactl绑核。

4）减少进程间的CPU抢占，通过taskset与启动参数isolate隔离，将特定的core空闲出来，给指定进程使用；

##三、议题共识综述
综合几位专家的详细解答，以麒麟、统信为主的信创操作系统内核与性能、硬件及CPU层面如何优化是一项复杂的、综合性的系统工程，需要围绕国产化数据库、中间件、硬件架构、CPU内核等多方面因素考虑。通过对某些项目的不断调整，如国产化数据库的参数和优化设置，缩短其响应时间；结合新型与传统的调优方法，提高各个方面的I/O性能，通过命令行实现CPU的调优等，以最终实现信创操作系统的架构最优化。

以国产数据库GaussDB为例进行优化，在其部署过程中，可以有针对性的进行调优。提升系统性能：如关闭SELinux，关闭swap交换内存，关闭RemoveIPC或升级audit版本等，或使用GaussDB其本身推荐的4K页块大小，优化读写性能，然后调整页大小即以提升系统性能，完成对内核的升级。与此同时信创操作系统在技术和运维层面都将遇到不少的挑战，前者基于新内核，且操作系统一般运行在X86架构的CPU之上，即产生了新的问题，对应地，高性能访问内存的场景同样会产生性能问题。 后者在日常运维情况下偶有发生内核崩溃现象，目前只能在一个周期下等待产品的修复或一个稳定的版本。麒麟、统信仍没有针对当前的主流芯片特性展开内核级的优化。究其原因，可能国产芯片某些功能做了阉割，导致操作系统的对相应部分被进行了简化。因此可从基础资源如CPU、内存、磁盘I/O、网络I/O等四个维度探讨性能方面优化。

对于硬件架构和CPU性能，主要的优化思路还是根据操作系统上部署的软件进行调优或是BIOS调优。 硬件架构，泛指CPU架构，不同芯片厂家根据自身产品特性，不定期发布补丁，系统厂商应及时将补丁融合到内核版本以便修复缺陷。对于CPU性能优化而言，从两个方面着手，先是降低其工作负荷，即通过观测CPU的使用，优化相关应用程序；再是提高其性能上限，固化CPU的频率，调整CPU的电源策略为最大性能，减少进程间的CPU抢占等手段最终实现性能优化。

信创操作系统麒麟操作系统系统性能优化

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！