了解更多银河麒麟操作系统全新产品，请点击访问

麒麟软件产品专区：https://product.kylinos.cn

开发者专区：https://developer.kylinos.cn

文档中心：https://document.kylinos.cn

---

服务器环境以及配置

系统环境	物理机/虚拟机/云/容器	虚拟机
网络环境	外网/私有网络/无网络	私有网络
硬件环境	处理器：	Kunpeng-920
	内存：	32 GiB
	机器型号	OpenStack Foundation
	整机类型/架构：	aarch64
	BIOS版本：	EFI Development Kit II / OVMF
	网卡：	x ring 2048/2048  drv virtio_net v1.0.0 / fw UNKNOWN
软件环境	具体操作系统版本	银河麒麟高级服务器操作系统  Kylin Linux Advanced Server release V10 (Sword)
	内核版本	4.19.90-25.21.v2101.ky10.aarch64

现象描述

系统发现tcp半链接溢出情况。业务量上来的时候   timewait会逐步升高  最高2.6万  再后面就tcb半链接池溢出  然后应用访问开始缓慢。

现象分析

分析netstat日志

Listen queue overflowed (监听队列溢出): 96,600：全连接队列（已完成连接队列）已满，无法接收更多已完成握手的连接。

SYNs to LISTEN sockets dropped: 96,600： 半连接队列（SYN队列）已满，无法接收更多新的SYN请求，因此新的SYN包被丢弃。

Listen queue overflowed和SYNs to LISTEN sockets dropped两个统计项数值相等，表明每次监听队列溢出时，都会有一个新的SYN包被丢弃。表明服务器在处理新连接方面存在瓶颈，尤其是在应用程序调用accept()函数时的延迟。

accept()函数处理不及时是导致这种现象的主要原因，具体原因包括：

应用程序性能不足：

• 应用程序在处理已建立连接时执行了阻塞操作，导致无法及时调用accept()。
• 全连接队列长度由 net.core.somaxconn和listen(fd, backlog) 的backlog两者最小值决定，如果listen函数传参backlog太小会导致这种现象。
• 使用单线程处理所有连接请求，无法高效处理高并发连接。
• 应用程序的资源（如线程、进程、文件描述符）有限，无法快速处理新连接。

1. 高并发连接请求：

• 短时间内大量合法连接请求涌入，超出应用程序的处理能力。
• 恶意攻击： 如SYN洪水攻击，导致大量半开连接占满队列。

系统参数配置不足：

• tcp_max_syn_backlog和 somaxconn设置过低，，无法应对高并发连接请求。

查看内核参数net.core.somaxconn和net.ipv4.tcp_max_syn_backlog的值，都很大，并不会是这两个内核参数太小导致。

net.core.somaxconn = 10240 net.ipv4.tcp_max_syn_backlog = 262144

服务器资源瓶颈：

• CPU或内存不足： 高并发连接导致CPU或内存资源耗尽，影响连接处理速度。
• I/O瓶颈： 网络接口或存储设备成为I/O瓶颈，限制了数据的快速处理。

 分析sa日志

sar -rh -f sa27，查看内存使用情况，问题发生期间，还存在空闲内存，且可用内存较多。

sar -B -f sa27，查看内存回收情况，问题发生期间，没有进行内存回收，可见内存资源是够的。

sar -u ALL -f sa27，查看问题发生期间CPU使用情况，CPU资源使用正常，内核态占比很低。

sar -P ALL -f sa27，查看问题发生期间，各个CPU的使用率，每个CPU使用率都很低。

sar -d -f sa27，查看问题发生时，磁盘使用情况，磁盘使用很低。

sar -n DEV -f sa27，查看问题发生期间，网络流量情况，网络流量并不高。

分析结果

Listen queue overflowed和SYNs to LISTEN sockets dropped两个统计项数值相等，都为96,600，说明全连接和半链接都发生了溢出，是全连接溢出导致了这个问题。表明服务器在处理新连接方面存在瓶颈，尤其是在应用程序调用accept()函数时的延迟。

accept()函数处理不及时是导致这种现象的主要原因有应用程序性能不足、高并发连接请求、系统参数配置不足和服务器资源瓶颈。根据sa日志和内核参数分析，系统参数配置配置正常，服务器资源正常。

在高并发压测下出现这种问题，推测是应用程序端问题，建议应用端排查，如全连接队列长度由 net.core.somaxconn和listen(fd, backlog) 的backlog两者最小值决定，如果listen函数传参backlog太小会导致这种现象。