这是一个创建于 3050 天前的主题，其中的信息可能已经有所发展或是发生改变。
兄弟们在日常的运维中是如何理解这个参数的来？
参数默认是 1024 ，代表 可以同时满足 1024 个并发连接，超过就丢掉了。 我这么说，都有点不确定。
一般在线上的 WEB 服务会增加这个，然后 nginx 里面通过 listen backlog 进行修改达到修改 nginx backlog 的目的。
那么问题来了？
- 这个参数增加会对系统带来啥优点？
- 带来啥缺点？
- 是否可以通过减少来保护系统？
 |
1
fcicq 2016-06-30 22:52:02 +08:00  1
这个值应该是收到请求但是没有完成 accept() 的连接总数上限吧. 除非有大量短连接的话 1024 肯定也够了
|
 |
2
pubby 2016-06-30 22:52:18 +08:00 1
TCP 连接后，上层应用需要 accept 这个连接才行，如果来不及 accept 那么等待被 accept 的连接数就会增大，大于>1024 的时候新连接就被丢弃了。
只有在很繁忙的服务器，或者程序某种设计问题迟迟不处理 accept 才会需要调这个。 |
 |
3
xionghengheng 2020-02-15 17:37:42 +08:00
我刚刚好遇到一个问题，下游存储超时，逻辑服务 accept 数量瞬间暴涨
原因在于：链接 accept 之后，从存储取数据时延过大，导致上游服务超时，然后发起重连，进而导致 accept 数量瞬间暴涨，但是连接数和请求量其实是没有变化的 |
Select Language