共计 2366 个字符,预计需要花费 6 分钟才能阅读完成。
导读 | 最近遇到一个非常有趣的问题。其中有一组 HAProxy,频繁出现问题。登录上服务器,cpu、内存、网络、io 一顿猛查。最终发现,机器上处于 TIME_WAIT 状态的连接,多达 6 万多个。 |
最近遇到一个非常有趣的问题。其中有一组 HAProxy,频繁出现问题。登录上服务器,cpu、内存、网络、io 一顿猛查。最终发现,机器上处于 TIME_WAIT 状态的连接,多达 6 万多个。
TIME_WAIT 状态,一般都会出现在 HAProxy、Nginx 这种代理机器上,主要是由于频繁的主动关闭所造成的。通过修改 reuse 和回收参数,可以比较快速的解决问题。
网络状态的统计数量,可以使用下面的命令进行统计。
netstat -ant|awk '/^tcp/ {++S[$NF]} END {for(a in S) print (a,S[a])}'
ESTABLISHED 70
FIN_WAIT2 30
CLOSING 33
TIME_WAIT 65520
这本来没什么神奇的,但 65535 这个数字,实在是太过于敏感。应该是触发了某种上限。
使我们更加感到疑惑的是:为什么 TIME_WAIT 状态的连接,仅仅达到了 65535,服务就不可用了?
到处号称的单机百万连接,是在吹牛皮么? 怎么这么经不起折腾?
65535,表示等于 2 的 16 次方减一,是一个神奇的数字。先把这小数字扔在一边,我们来看一下 Linux 到底能支持多少个连接。
答案是无数个。可是端口只有 65535 个啊。
为什么端口只有 65535 个?
这是一个历史原因,因为在 TCP、UDP 协议的开头,会分别有 16 位来存储源端口号和目标端口号。很遗憾的是,这个值是 short 类型的,大小也是 2^16-1。
因为历史原因造成的不可改变的标准,就是那么根深蒂固。
那 Linux 到底能支持多少个连接呢? 答案是无数个。
拿 nginx 来说,我们把它监听在 80 端口上。这时候 A 机器去连接 Nginx,可以发起多达 6w 多条长连接。如果 B 机器去连接 Nginx,同样也可以发起 6w 多条连接。这是由于确定一条连接,是由 src 和 dst 来共同决定的。
认为 Linux 只能接受 65535 条连接的想法,只能说是犯了非常浅显的想当然主义。
65535 个端口,作为压测机可能对你来说太小了一些。但对于服务器来说,已经绰绰有余了。
从上面可以看到,连接数,是没有限制的。但 Linux 还有一层防护,那就是文件句柄数。通过 lsof 命令查看到的那些东西,就是所谓的文件句柄。
先来看一下几个命令的展示。
ulmit,展示了每个进程所能占用的文件句柄数量。
ulimit -n
65535
file-max,展示了操作系统能够占用的文件句柄数量总和,针对的是所有的进程。
cat /proc/sys/fs/file-max
766722
file-nr,展示了当前已经使用的句柄数量和总的句柄数量。可以拿来做监控。
cat /proc/sys/fs/file-nr
1824 0 766722
要支持百万连接,既要放开操作系统级别的句柄,也要放开进程级别的句柄。也就是说,ulimit 和 file-max 的显示,都要大于百万才成。
设置进程的句柄个数,常用的方式就有 ulimit,但是非常非常不推荐。原因无他,只有在同一个 shell 中启动的进程,ulimit 的设置才会生效。你打开另外一个 shell,或者重启机器,ulimit 的改动都会丢失。就是下面这种方式:
ulimit -n 1000000
正确的方式,是修改 /etc/security/limits.conf 文件。比如下面的内容。
root soft nofile 1000000
root hard nofile 1000000
* soft nofile 1000000
* hard nofile 1000000
可以看到,我们可以针对于特定的用户,修改其句柄数量。这在安装 es 等应用时,经常碰到。
es - nofile 65535
但即使是这种方式,也要求你需要打开一个新的 shell 进行操作。在当前修改的 shell 里或者修改之前的 shell 里,同样不生效。xjjdog 就曾遇到过多起这样明明放开了限制,但还是发生问题的案例。
要看到这些改变是否已经对进程生效,可以查看进程的内存映射文件。比如 cat /proc/180323/limits,其中会有详细的展示。
这个数值,也并不是想要设多大就多大的。它的大小上限,是由 nr_open 决定的。想要更大,就要修改 /ect/sysct.conf 中 fs.nr_open 的值。
cat /proc/sys/fs/nr_open
1048576
那 file-max 又该如何修改呢? 建议修改 /etc/sysctl.conf 文件,加入下面内容。足足有 6 百多万!
fs.file-max = 6553560
当文件数量超出的时候,就会报 kernel: VFS: file-max limit 65535 reached 的错误。
总结一下。
Linux 即使放开一个端口,能够接受的连接也是海量的。这些连接的上限,受到单进程文件句柄数量和操作系统文件句柄数量的限制,也就是 ulimit 和 file-max。
为了能够将参数修改持久化,我们倾向于将改动写入到文件里。进程的文件句柄限制,可以放在 /etc/security/limits.conf 中,它的上限受到 fs.nr_open 的制约; 操作系统的文件句柄限制,可以放到 /etc/sysctl.conf 文件中。最后,别忘了在 /proc/$id/limits 文件中,确认修改是否对进程生效了。
如此,百万连接才名不虚传。我比较奇怪的是,为什么 Linux 不默认放开这些配置呢? 做成 65535 也认啊,为什么搞个 1024?
![post-qrcode](https://www.xgss.net/wp-content/uploads/2023/07/二维码-微信公众号256x256.jpg)