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

字数 12787阅读 3415评论 3赞 2

内容摘要：

文章介绍了信创操作系统内核优化的重要性和策略，包括版本选择、稳定性、安全性、成本问题、硬件优化、网络优化等方面，提供了内核参数优化清单和专家共识。需要注意硬件驱动版本兼容性和前期准备，避免问题循环往复。

当前摘要为AI生成

## 一、 **导语**
信创即信息技术应用创新产业，是数据安全和网络安全的组成部分，更是国家新基建的重要组成部分。信创改革的总体目标是要在2027年底实现各行各业百分百的信创替代。迄今为止，信创改革的已逐步形成“2+8+N”的落地模式，信创改革于各行各业正如火如荼地开展。

信创主要涵盖基础硬件、基础软件、应用软件以及信息安全四个部分。其中在软件领域，主要分为基础软件及云计算，前者如操作系统、数据库、中间件等，后者如云服务等。当中操作系统又是信创体系的重要产业链环节，因此它的性能优化方面尤为需要重点把控。信创操作系统的性能优化对于实现全面替换办公自动化、门户、邮箱、纪检、党建、战略决策、ERP、风控等系统起着内驱作用，是信创改革基础中的根基，因此我们不遗余力地探索操作系统性能的优化方式方法，尤其在内核优化这个维度，需重点把控。

本期"麒麟、统信操作系统共建知识库之内核调优”知识库建设，邀请了社区多位技术专家一同参与线上交流，重点对信创操作系统的内核优化进行深入探讨并最终作分类总结。
>  **主稿嘉宾：** 
张晓斌  某金融保险  信息技术部科技支持岗 
**互动嘉宾 ：**
三虎  中国邮政储蓄银行  系统运维工程师
Ciao  某大型证券  系统架构师
陈成  中国联通软件研究院  研发工程师

##**二、议题研讨内容**
### 问题1：针对操作系统主流版本是否有推荐的小版本？
**嘉宾 actor168 研发工程师 中国联通软件研究院 ：**
一般建议使用发布的新版本kernel，修复bug、安全及性能问题。可以以集群级别作为升级的单位，针对单个集群/单个业务系统进行升级，做比对测试。如果有差异，则择优选择。
以我司为例，在使用过程中出现的问题，我们会对比差异，如有必要升级，则后续新装版本直接升级，旧有系统则暂时保持不变，只处理有问题机器，再在经运维、基础设施、os团队评估后合适时间统一做升级。
对于因硬件兼容性导致的问题，一般不做内核升级，而是痛过kernel module做更新管理，这样就避免版本的变化，但带来弊端是需要对模块升级做记录，并持续追踪，增加了管理成本。

**嘉宾 Ciao 架构师 某证券公司：**
目前信创操作系统的更新也较多，但是对于生产系统来说，主要追求稳定性，对于内核及打本更更新一般会伴随系统测试，耗时耗力。对于系统版本的更新建议考虑基本方面: 
1、 重大安全漏洞需要全量更新。 
2、 系统bug需要分析bug触发原因，如果生产系统无触发风险，建议不更新，反之则要更新。
3、 建议生产上系统版本维持在2-3个，否则会提高维护的复杂性。
4、 操作系统以稳定为主，系统稳定以后，无安全风险的补丁尽量不要打。

**嘉宾 三虎 系统运维工程师 中国邮政储蓄银行 ：**
麒麟、统信操作系统主发行版定版后，后续的更新版本一般会根据漏洞严重程度来决定是否修复，并发布相应的内核补丁包。用户可定期联系对应品牌的厂商，了解补丁的发布情况，并根据生产环境决定是否要调整升级内核小版本。

### 问题2：麒麟和统信操作系统的版本如何选择？ 
**嘉宾 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、成本问题：这没什么好说的，采购时总要在技术和财务之间做平衡；

6、商务纠纷：最后确认下供货方，是否存在纠纷，防止产品许可授权出现多头，
产生不必要的纠纷或后期断保断服的风险。

### 问题3：信创操作系统层面tcp短时高并发短连接应当如何调优？
 **嘉宾 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等，将大大提高效率。

8、观测系统资源瓶颈，简单说就是见招拆招，看出现什么问题做对应的性能优化，如半连接队列长度为256，但当前TCP连接中SYN_RECV状态的连接数已经到了256，则说明半连接队列已经溢出了，需要扩大半连接队列长度，那么需要一并考虑backlog、somaxconn和tcp_max_syn_backlog参数。

### 问题4：麒麟操作系统在处理高并发场景下的性能优化有哪些策略？
**嘉宾 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 "信创操作系统层面tcp短时高并发短连接应当如何调优？")》帖子中的回复；

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

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

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

5、另外高并发可以考虑做业务限流，如设定排队或熔断机制，保证已接入的请求能正常处置。

### 问题5：细分通用场景下的内核参数优化清单？
**嘉宾 actor168 研发工程师 中国联通软件研究院 ：** 
**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 架构师 某证券公司：**

|   |   |   |
| ------------ | ------------ | ------------ |
| 编号 | 设置值 | 说明 |
| 1 | net.ipv4.conf.all.arp_ignore = 0net.ipv4.conf.default.arp_ignore = 0 | 不允许ignore arp（只有LVS时才需要此选项）默认 |
| 2 | net.ipv4.conf.all.arp_filter = 0net.ipv4.conf.default.arp_filter = 0 | 不允许ignore arp filter（只有LVS时才需要此选项）默认 |
| 3 | net.ipv4.conf.all.rp_filter = 0 | 不开启rp_filter（防止ip欺骗）默认1 |
| 4 | net.ipv4.conf.all.log_martians =0net.ipv4.conf.default.log_martians = 0 | 不记录探测包，源路由包，重定向包 默认 |
| 5 | net.ipv4.conf.all.promote_secondaries = 1 | 禁止删除primary ip，当secondary ip地址与primary ip地址属于同一个网段时，删除primary ip地址时也会删除secondary ip地址 默认 |
| 6 | net.ipv4.ip_no_pmtu_disc = 1 | 禁用ip path mtu discover 默认1 |
| 7 | net.ipv4.icmp_echo_ignore_broadcasts = 1 | 禁止响应目的地为广播地址类型为echo的icmp包。默认 |
| 8 | net.ipv4.conf.all.accept_source_route = 0net.ipv4.conf.default.accept_source_route = 0 | 禁用源地址路由 默认对于redis和mongodb环境，需启用源地址路由：net.ipv4.conf.all.accept_source_route = 1 |
| 10 | net.ipv4.conf.all.accept_redirects = 0net.ipv4.conf.default.accept_redirects = 0 | 拒绝路由重定向包 默认 |
| 11 | net.ipv4.conf.all.secure_redirects = 0 | 也不允许网关发送的路由重定向包 默认 |
| 12 | net.ipv4.tcp_timestamps = 1 | 开启tcp时间戳选项 默认 |
| 13 | net.ipv4.icmp_ignore_bogus_error_responses = 1 | 某些路由器忽略RFC1122规定的包，发送假的错误消息给源主机，导致源主机记录大量错误信息到日志中 默认 |
| 14 | net.ipv4.conf.all.proxy_arp = 0net.ipv4.conf.default.proxy_arp = 0 | 关闭arp代理 默认 |
| 15 | net.core.somaxconn = 65535net.ipv4.tcp_max_syn_backlog = 838860 | 最大的syn包队列设置，加大tcp会话等待数对于需要支撑高并发的业务服务器，可以根据压力测试情况，将该值增大。 |
| 16 | net.ipv4.tcp_syncookies = 1 | 防止客户端使用syn包打开半链接进行拒绝攻击，默认 |
| 17 | net.ipv4.tcp_fin_timeout = 60 | 本端关闭的链接从FIN_WAIT_2到TIME_WAIT状态设置为60 默认 |
| 18 | net.ipv4.conf.all.send_redirects = 0 | 禁止发送重定向报文 默认 |
| 19 | net.ipv4.tcp_keepalive_time = 150net.ipv4.tcp_keepalive_probes = 5net.ipv4.tcp_keepalive_intvl = 6 | TCP keepalive设置 |
| 20 | net.ipv4.conf.all.forwarding = 0net.ipv4.conf.default.forwarding = 0net.ipv4.ip_forward = 0 | 禁用ip转发 默认openshift容器集群环境，需开启IP转发功能：net.ipv4.conf.all.forwarding = 1net.ipv4.conf.default.forwarding = 1net.ipv4.ip_forward = 1 |

**嘉宾 三虎 系统运维工程师 中国邮政储蓄银行 ：** 
针对前、中、后端的业务请求数、数据处理类型、长短链接等方面，是有较大差异的，在网络参数上至少是可以形成不同的参数规范。

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

针对计算密集型和大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

### 问题6：内核升级时是否考虑了各类硬件驱动版本的升级问题？
**嘉宾 actor168 研发工程师 中国联通软件研究院 ：**
同样遇到过这种场景，在我们的一些老旧机器中，内核驱动曾经做过升级，在进行原地迁移替换后，出现了异常，导致无法在信创os上使用，后通过进行kernel module形式进行处理，给我们也提了个醒，后续迁移前务必确认内核module的版本变化情况，在操作系统变更管理中持续记录内核模块变更情况，以避免未知情况发生，确保系统稳定性和可靠性。

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

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

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

**嘉宾 三虎 系统运维工程师 中国邮政储蓄银行 ：** 
实际碰到的问题，内核补丁升级时，没有考虑清楚硬件配置环境，升级后导致了带入的阵列卡驱动版本低于升级前的版本（升级前已对阵列卡驱动单独进行过升级），直接带来的影响包括，驱动可能不识别本地盘了，导致引导失败，无法进入系统；或者在识别多个本地盘时盘序颠倒，导致数据盘的盘号大于系统盘。  所以针对此类问题，在升级前一定要检查系统相关的驱动版本信息，尤其是已升级过的驱动，确保内核升级时，该升级的驱动一并升级、生效，防止“意外”发生。

##三、议题共识综述
以上累计的几个问题，由三位专家围绕信创操作系统是否有推荐的小版本、其版本选择、高并发短连接时如何调优、高并发场景的性能优化策略、通用场景下的内核参数优化清单、内核升级是否考虑各类硬件驱动版本的升级等问题进行专业的研判与综合陈述，从而达到一些共识并综述如下：

**1、在关于操作系统版本选择、系统更新以及内核升级等方面：**
* 需要以稳定性及安全性两个方面作前提和基础。目前信创操作系统以稳定安全为主，因此安全方面漏洞尽量全量更新，其他无触发系统性的为避免风险尽量可不更新，同理无安全风险建议不打补丁。再者因机器硬件兼容性问题，一般不作内核升级，否则遇到风险时或将无法应对。又有如升级过程中数据迁移时的数据丢失，升级过程不断重启，运维过程是否可控等问题。

* 总而言之，信创操作系统升级或选择时需要权衡各方面的利弊，以更优的方式选择下一步的举措。至于操作系统版本的选择，最后细分几个层面去考虑。生态建设、桌面运维、源头社区、甚至服务器产品等，都需要遇到具体问题作具体分析，但最终兼容性同稳定性始终是根基。最后务必做好测试工作，确认无误以后方进行升级举措。

**2、其次在操作系统层面的高并发如何调优、高并发性能优化策略方面:**
* 由于信创操作系统依然主要以LINUX为开发基础，因此可以沿着其硬件、网络、存储等几个方面作为考虑依据。

* 首先TCP的短时高并发调优方式，一般从网络硬件（网卡）着手：调整网卡的环形缓存用以接收数据;使用NUMA绑定来减少跨路访问;利用TCP三次握手进行优化，加速端口回收，开启端口重用;观测系统资源瓶颈，具体问题具体分析，即出现什么问题作对应的性能调优。

* 而对于高并发的性能优化策略，与调优方式类似，以LINUX为主要基础，从系统参数、存储等几个方面入手。对于高并发下场景下带来的一些问题，如网络IO压力、CPU资源不足、磁盘IO负载过多、后端数据库的写入等，均有针对性的调优策略。另外高并发可考虑业务限流，如设定排队或熔断机制，保证已接入的请求能正常处置。

**3、细分通用场景下的内核参数优化清单:**
* 其主要由内存、网络、文件系统等命令组成。在CPU、内存、网络、文件系统等方面均可设置相应的命令进行优化。前中后端各有业务请求数、数据处理类型、长短链接等方面，存在较大差异，在网络参数上可以形成不同的参数规范。

* 举例如云底座、容器底座、虚机等几个不同应用场景，前者更关注云平台、硬件之间的适配兼容，而容器底座涉及防火墙配置则要求更加轻量化等，虚机相比物理机可使用的资源更少，故在部署上、参数模型方面应都有不同的规范。

综上，无论在版本选择、系统更新、内核升级、高并发调优或高并发性能优化、内核参数调优等层面，必须做好充分的前期准备，以并避免在此过程中又再次引出新的问题导致问题循环往复无法解决。

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

著作权归作者所有

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