net.ipv4.tcp_max_syn_backlog 不起作用？？？

druggo

呵呵，看来是和内核无关，
另外当然是不需要重启系统，是我们忘记重启webserver了……

jidi_78

Post by druggo;2100184
呵呵，看来是和内核无关，
另外当然是不需要重启系统，是我们忘记重启webserver了……

我以前的观点"sysctl -p不起总用，需要从起系统”，这个观点就像druggo兄所说的是错误的，只要从起一下webserver就可以了。现在的问题是，我本身更改的是内核的参数，为什么还需要从新启动webserver?我上面更改的配置中哪一项起的作用？

druggo兄所说的和内核无关,是指和内核版本无关？还是指半连接数的大小和内核没有关系，而是webserver造成的？

另外如果我想继续扩大系统能够支持的SYN_RECV数量，应该改什么参数？

druggo

为什么要重启webserver，原因是listen这个函数，只有启动的时候才会读取内核里somaxconn的值以确定backlog的大小，如果你用的是nginx的话，它默认的backlog是511，所以你的结果没能超过512啦，还有如果内核版本更老也许是小于2.6.20吧，内核有给listen固定的大小（TCP_SYNQ_HSIZE=512）。

所以backlog大概由三方面共同决定，listen函数的backlog参数，somaxconn，tcp_max_syn_backlog。

不过这些只是半连接大小，并不能决定webserver能承载的连接数的大小。

jidi_78

谢druggo兄，关于系统半连接的问题解决。正像你上面说的，虽然系统能够支持半连接数多了，但不等于系统能够承载的连接数就上去了。现在有一台8core,16Gmem的Nginx的机器，我应该如何正确的设置系统支持的连接数？有没有什么具体的数值，比如一个连接数会占用多少内存？

druggo

做压力测试，比如ab、webbench之类的