Tcp （FreeBSD）当3000或4000人在同一时间突然开始登录时，该端口在同一秒内没有响应。

我通过FreeBSD11.0-64位管理游戏服务器

我对此有意见。当3000或4000人在同一时刻突然开始登录时，该端口在同一秒内没有响应。但根本就没有所谓的结束。没有错误。他只是一直慢慢地

我有ipfw.rules，但我将限制SCR保持在最高值

我该怎么办呢？

我建议大家看看。有几个可调参数可用于影响网络

我认为这是你最好的选择：

这一个可能不是您的，因为它会影响每个连接的性能，但为了安全起见，我仍然会尝试随值上下波动：

我会试着关掉这个：

当然，通常的调整规则也适用：

• 除非您了解调优设置的作用，否则不要使用它
• 每次更改一个设置，测量效果

---

祝你好运。

我需要做一个与内核相关的设置吗？你应该庆祝有这么多用户。是时候研究分布式计算和负载平衡了。@EJP我的问题：sonewconn:pcb 0xfffff8000dfc3740:侦听队列溢出：193已在队列中等待接受（28次）您的游戏服务器代码接受连接的速度不够快。描述它并找出原因。（例如，可能不只是每个循环调用一次

accept

，而是一直调用它，直到它返回

ewoodblock

）

 The kern.ipc.somaxconn sysctl limits the size of the listen queue for
 accepting new TCP connections.  The default value of 128 is typically too
 low for robust handling of   new connections in a heavily loaded web server
 environment.  For such environments, we recommend increasing this value
 to   1024 or higher.

 The net.inet.tcp.sendspace   and net.inet.tcp.recvspace sysctls are of par-
 ticular interest if you are running network intensive applications.…

 The net.inet.tcp.always_keepalive sysctl determines whether or not   the
 TCP implementation   should attempt to detect dead TCP connections by
 intermittently delivering ``keepalives'' on the connection.  By default,
 this is enabled for all applications; by setting this sysctl to 0,   only
 applications that specifically request keepalives will use   them.