Fix too many FIN_WAIT_2 connections under freebsd

最新推荐文章于 2022-03-10 16:45:16 发布
转载 最新推荐文章于 2022-03-10 16:45:16 发布 · 1.7k 阅读 · 0
文章标签：

#freebsd #lighttpd #apache #服务器 #防火墙 #tags

本文介绍了如何通过调整Lighttpd和Apache服务器配置来减少FreeBSD系统中FIN_WAIT_2状态的连接数量，以缓解网络拥堵问题。文章提供了具体操作步骤，包括修改服务器配置文件及启用ipfw2防火墙时的额外设置。
部署运行你感兴趣的模型镜像
原贴：http://www.sofee.cn/blog/2006/08/26/33/

Fix too many FIN_WAIT_2 connections under freebsd

No Tags

August 26, 2006 at 14:54:57 · Filed under Lighttpd, Apache, FreeBSD

查看FIN_WAIT_2连接数：

bsd#netstat -an | grep FIN_WAIT_2 | wc -l
2523

修改Lighttpd配置文件，加入下面这条语句：

server.max-keep-alive-requests = 0
bsd#netstat -an | grep FIN_WAIT_2 | wc -l
91

如果服务器开启了ipfw2防火墙的话，还需要执行：

sysctl -w net.inet.ip.fw.dyn_keepalive=0

p.s. 若为APACHE服务器，同理。

 

您可能感兴趣的与本文相关的镜像

Stable-Diffusion-3.5

Stable-Diffusion-3.5

图片生成
Stable-Diffusion

Stable Diffusion 3.5 (SD 3.5) 是由 Stability AI 推出的新一代文本到图像生成模型，相比 3.0 版本，它提升了图像质量、运行速度和硬件效率

ubuntu中解决进程的TIME_WAIT和FIN_WAIT2链接状态
qq_40907977的博客
11-12 2453
环境 ：Ubuntu 16.04 LTS 解决进程的time_wait状态 查看进程连接状态 #netstat -an|awk ‘/tcp/ {print $6}’|sort|uniq -c 16 CLOSING 130 ESTABLISHED 298 FIN_WAIT1 13 FIN_WAIT2 9 LAST_ACK 7 LISTEN 103 SYN_RECV 5204 TIME_WAIT 状...
TCP状态迁移，CLOSE_WAIT & FIN_WAIT2 的问题解决
02-18
对于服务器挂起中的CLOSE_WAIT & FIN_WAIT2 解决方案。
SOCKET网络编程四：SELECT单进程并发服务器
mazi的博客
02-15 839
五种IO模型： 阻塞IO：recv接收缓冲区有数据后，就会解除阻塞。 非阻塞IO：忙等待fcntl(fd,F_SETFL,flag|O_NONBLOCK) IO复用（select和poll） 信号驱动IO 异步IO ...
FIN_WAIT_2状态下的连接与Apache
最实用的Linux博客
10-03 3177
原贴：http://doc.99net.net/doc/service/1076303865/1076481079.html FIN_WAIT_2状态下的连接与Apache
gerrit允许最大连接数修改
aaf02002的博客
11-14 2783
Received disconnect from 12.xx.xx.xx port 29418:12: Too many concurrent connections (64) - max. allowed: 64   此时需要修改gerrit上的配置文件 etc/gerrit.config     maxConnectionsPerUser = 0 无限制，默认是64 [sshd]  ...
gerrit调优
人的博客
03-10 2686
一、确定配置大小 根据gerrit使用的服务器集群的硬件配置来确定大小 二、调整 gerrit.config receive.timeout 处理传入更改和更新 refs 和 Gerrit 更改的超时。 sshd.threads 处理 ssh 请求的线程，限制可能的并行克隆/推送的数量 httpd.maxThreads 处理 http 克隆/推送请求和审查相关活动的线程数量 database.poolLimit Gerrit 的数据库连接数 database.poolMaxIdle 数据库释放前的最长时间
Gerrit “too many commits” 问题
xiezhongtian的专栏
11-13 4379
Gerrit “too many commits” 问题 gerrit的一个默认最大提交数的限制 ，看了下gerrit的光放说明，more是10000（如下：） **receive.maxBatchCommits** The maximum number of commits that Gerrit allows to be pushed in a batch directly to a bran...
gerrit疑难问题解决方法汇总
老兵Coding
07-06 4231
本文是自己工作中遇到的gerrit有关问题的解决办法汇总。 问题1：代码服务器崩溃后发现有的库无法同步 提示问题如下： user@ce-ubt02:~/temp$ ./repo sync msm8909-la-3-1-1_amss_standard_oem/platform/external/trappy Fetching project msm8909-la-3-1-1_amss_standar...
关于服务端的FIN_WAIT2
shellching的专栏
01-06 2020
服务端开启了TCP服务，客户端连接，正常的情况下当服务端closesocket后向客户端发送FIN，客户端回应ACK，此时服务端进入FIN_WAIT2状态，等待客户端发送FIN然后进入CLOSED。 这时，客户端还可以send一次数据，send完后，服务端收到后就会向客户端发送RST并进入CLOSED 若客户端始终不发送数据，并且也不Close，那么服务端的FIN_WAIT2会持续要一个默认超时（一般是60s），这个种残留链接太多的时候可能会消耗服务端资源，降低性能，甚至无法正常工作。 我们可以使用S
为什么kill进程后socket一直处于FIN_WAIT_1状态
阿里云云栖号
06-05 1640
本文介绍一个因为conntrack内核参数设置和iptables规则设置的原因导致TCP连接不能正常关闭(socket一直处于FIN_WAIT_1状态)的案例，并介绍conntrack相关代码在conntrack表项超时后对新报文的处理逻辑。 案例现象 问题的现象： ECS上有一个进程，建立了到另一个服务器的socket连接。 kill掉进程，发现tcpdump抓不到FIN包发出，导致服务...
解决TCP连接数过多的问题
热门推荐
Mr. David 专栏
07-14 2万+
1、建立连接协议（三次握手） （1）客户 端发送一个带SYN标志的TCP报文到服务器。这是三次握手过程中的报文1。 （2） 服务器端回应客户端的，这是三次握手中的第2个报文，这个报文同时带ACK标志和SYN标 志。因此它表示对刚才客户端SYN报文的回应；同时又标志SYN给客户端，询问客户端是否准备好进行数据通 讯。 （3） 客户必须再次回应服务段一个ACK报文，这是报文段3。 2、连接终止
gerrit 数据库查找change_id
01-16 3181
############################################################## remote: Resolving deltas: 100% (2/2) error: unpack failed: error Missing unknown 613fd2557fba30aff2dbd51c3807cc57561bab08 fatal: Unpack
Go连接MySql数据库too many connections错误解决
xuguokun1986的博客
02-14 2717
这几天用Go写了个简陋的服务器，连接Mysql数据库，提供api给其他程序调用来实现增删改产等服务。Go的版本是1.2，使用的驱动是go-sql-driver/mysql。但是在有一定量的查询结果以后，会出先too many connection的错误。         google了一下，很多文章都建议修改MySql的配置文件：my.ini。文章是这样解释的：MySql的默认连接数是1
TCP连接状态详解及TIME_WAIT过多的解决方法
taoy86的博客
05-04 324
TIME_WAIT状态原理----------------------------通信双方建立TCP连接后，主动关闭连接的一方就会进入TIME_WAIT状态。客户端主动关闭连接时，会发送最后一个ack后，然后会进入TIME_WAIT状态，再停留2个MSL时间(后有MSL的解释)，进入CLOSED状态。下图是以客户端主动关闭连接为例，说明这一过程的。 TIME_WAIT状态存在的理由TCP/IP协议...
mysql连接数太小，导致网站报错mysql:Too many connections
weixin_33975951的博客
09-14 223
2017.9.14一个网站上线前压力测试网页打开报错mysql:Too many connections一看就是mysql连接数设置过小导致的进mysql查看连接数设置show variables like '%max_connections%';只有151，怎么可以，果断决定提高到1000PS:服务器性能可以的，哈哈打开MySQL配置文件my.cnf添加 max_conne...
Received disconnect from **.**).***.*** port 22:2: Too many authentication failures 解决办法
weixin_30263073的博客
11-20 5430
登录云服务器（使用云服务器自己的命令行工具） 之后只需要修改这个地方就可以了 vim /etc/ssh/sshd_config 将这行注释去掉，并且修改他的值稍微大一点即可 MaxAuthTries 10 查看原文：http://qdblogs.com/?id=4 转载于:https://www.cnblogs.com/liuqd001/p/9987281.html...
LWIP FIN_WAIT_2
最新发布
07-24
<think>我们正在讨论LWIP中的FIN_WAIT_2状态。在TCP连接终止过程中，当一方（我们称为A）发送了FIN并收到另一方的ACK（但尚未收到对方的FIN）时，A进入FIN_WAIT_2状态。在LWIP中，这个状态的处理有一些特点，特别是关于超时和资源回收。 在标准TCP中，FIN_WAIT_2状态可以持续直到收到对方的FIN，但为了防止无限等待，通常有一个超时（在Linux中默认60秒）。在LWIP中，这个超时由TCP_FIN_WAIT_TIMEOUT控制。 另外，在LWIP中，当连接处于FIN_WAIT_2状态时，它会被放在一个叫做tcp_tw_pcbs的链表中（如果开启了LWIP_TCP_TIMESTAMPS，则使用另一种方式管理）。然后，在慢定时器（tcp_slowtmr）中会检查这些连接的超时。 下面将详细解读LWIP中FIN_WAIT_2状态的处理，包括状态转移、超时机制和资源回收。 注意：LWIP的版本不同实现可能略有不同，这里以较新的版本（如2.1.2）为例。</think>### LWIP中FIN_WAIT_2状态解析 在lwIP的TCP协议栈中，`FIN_WAIT_2`是TCP连接终止过程中的关键状态之一。它发生在主动关闭方发送FIN并收到ACK后，等待对方发送FIN的阶段。以下是深度解析： #### 状态转移机制 ```mermaid stateDiagram-v2 [*] --> ESTABLISHED ESTABLISHED --> FIN_WAIT_1: 主动关闭方发送FIN FIN_WAIT_1 --> FIN_WAIT_2: 收到ACK（未收到FIN） FIN_WAIT_2 --> TIME_WAIT: 收到对方FIN TIME_WAIT --> [*]: 2MSL超时 FIN_WAIT_2 --> CLOSED: 超时或异常终止 ``` #### 核心处理逻辑 在`tcp_slowtmr()`中实现状态管理（`src/core/tcp.c`）： ```c void tcp_slowtmr(void) { for (pcb = tcp_active_pcbs; pcb != NULL; pcb = pcb_next) { switch (pcb->state) { case FIN_WAIT_2: /* 检查FIN_WAIT_2超时 */ if (++pcb->tmr > tcp_fin_wait_2_timeout) { tcp_abort(pcb); // 强制终止连接 } break; } } } ``` #### 关键配置参数 在`lwipopts.h`中定义： ```c #define TCP_FIN_WAIT_TIMEOUT 60000 // FIN_WAIT_2超时时间(ms)，默认60秒 #define TCP_MAX_MSL 60000 // MSL时间(ms)，影响TIME_WAIT时长 ``` #### 状态特性与挑战 1. **资源占用问题** - 每个`FIN_WAIT_2`连接占用： - 约200字节内存（PCB结构体） - 1个TCP端口资源 - 高并发场景易导致资源耗尽 2. **超时管理机制** ```c // 默认超时计算（tcp.c） #define tcp_fin_wait_2_timeout (TCP_FIN_WAIT_TIMEOUT / TCP_SLOW_INTERVAL) ``` - 实际超时检测在慢定时器中间隔执行（默认500ms） 3. **异常处理场景** - **被动方崩溃**：依赖`TCP_FIN_WAIT_TIMEOUT`回收资源 - **网络丢包**：重传机制不适用于FIN_WAIT_2状态 - **资源耗尽**：触发`tcp_abort()`强制关闭 #### 优化策略 1. **调整超时参数** ```c // 减少FIN_WAIT_2持续时间 #define TCP_FIN_WAIT_TIMEOUT 30000 // 30秒 ``` 2. **启用端口复用** ```c #define SO_REUSE 1 // 允许TIME_WAIT端口重用 ``` 3. **主动关闭优化** ```c // 应用层设置SO_LINGER选项 struct linger lin = { .l_onoff = 1, .l_linger = 0 }; setsockopt(sock, SOL_SOCKET, SO_LINGER, &lin, sizeof(lin)); ``` #### 状态转移矩阵 | 事件 | 动作 | 新状态 | |------|------|--------| | 收到FIN | 发送ACK | TIME_WAIT | | 超时 | 释放PCB | CLOSED | | 收到数据 | 发送RST | CLOSED | | 应用关闭 | 无操作 | 保持状态 | #### 典型问题解决方案 **场景**：服务器出现大量FIN_WAIT_2连接<br> **诊断命令**： ```bash netstat -n | awk '/FIN_WAIT_2/{print $5}' | cut -d: -f1 | sort | uniq -c ``` **解决步骤**： 1. 检查被动关闭方是否正常发送FIN 2. 调整`TCP_FIN_WAIT_TIMEOUT` 3. 启用`SO_REUSEADDR` 4. 优化应用关闭逻辑
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值