麒麟软件产品专区：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太小会导致这种现象。
- 使用单线程处理所有连接请求，无法高效处理高并发连接。
- 应用程序的资源（如线程、进程、文件描述符）有限，无法快速处理新连接。
- 高并发连接请求：
- 短时间内大量合法连接请求涌入，超出应用程序的处理能力。
- 恶意攻击： 如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太小会导致这种现象。