关于processTimeout和processTimeoutHandler的设置问题

我想查看这个，是因为我们现在的业务是共享设备，投放在外面的设备与服务器通过TCP长连接，用是GatewayWorker。目前大约有7000台设备，Linux内核优化和event扩展都做了，前面6月底的时候出现过TCP连接突然大量掉线，只剩3000左右维持着，查看日志没有任何东西。原本以为业务堵塞，日志里没记录下超时。所以想问要不要开启declare(ticks=1)。

TOP图截了2张，请大神帮忙看一下，非常感谢。

1.declare(ticks=1)一直没开，gateway进程数现在是24，按照手册文档是有点高，但是当时低的时候TCP连接数达到一定高度后会自动下降然后再回升，以为是连接性能不够，所以才增加了gateway进程数。

2.安装了event扩展优化linux内核，都是很久以前做的工作了，期间gatewayWorker没有用restart指令，都是stop，然后再start -d启动的，不知道这样跟直接restart相同吗？

3.内核优化倒确实是没有严格按照workerman手册来，当时也参考了其他的文档，现在在sysctl.conf文件中新增的是这样：
net.ipv4.tcp_max_tw_buckets = 8000
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_synack_retries = 2
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 30000
fs.file-max = 6815744
net.ipv4.tcp_keepalive_time = 1200
net.ipv4.ip_local_port_range = 20000 65000
防火墙跟踪表的大小没找到在哪里查看，# cat /proc/sys/net/netfilter/nf_conntrack_max，说是no such file or directory

4.打开文件数，在/etc/security/limits.conf这个文件里是这样的，比你的建议值小：
root soft nofile 65535
root hard nofile 65535

• soft nofile 65535
• hard nofile 65535
  我想请问用手册里的方法2：在/etc/profile文件末尾添加一行ulimit -HSn 102400，这样每次登录终端时，都会自动执行/etc/profile。
  在文件末尾添加这一样后，需要执行什么操作吗？需要重启服务器吗？

5.优化linux内核后，都是执行了/sbin/sysctl -p，按照大神的说法，都是要重启gatewayWorker，那执行了/sbin/sysctl -p服务器要重启吗？

@1:我们的服务器用的是阿里云的，运行了service iptables status后，看到是loaded:not-found; Active:inactive那应该是没开吧。也咨询了阿里云的客户，说公共镜像系统的服务器，系统内默认是没有开防火墙的。那么我就是没开防火墙。但是你说的开了防火墙，net.netfilter.nf_conntrack_max这个值设置的比较低的后果跟我遇到的情况有点像。那我现在需要打开防火墙，再设置这个参数吗？

我目前设置的是net.ipv4.tcp_tw_recycle=1和net.ipv4.tcp_timestamps=1，搜了一下资料，大神说的不对吧，应该是这2个同时为1，会对nat网络的客户端造成影响吧？我现在投放在外面的设备大部分是通过GPRS手机卡连接到服务器的，也有部分是通过路由器。所以是通过路由器的部分设备因是nat网络会连接异常断开？那我要把net.ipv4.tcp_tw_recycle改成0吗？

stop再start和restart一个效果
没开防火墙就不需要net.netfilter.nf_conntrack_max这个配置，但是如果开了防火墙net.netfilter.nf_conntrack_max一定要按照手册设置，如果这个值设置的比较低，则会导致连接超时或者连接异常断开，尤其是服务重启大量客户端断线并瞬间重连时，nf_conntrack表很容易满，导致有大量客户端连接失败或者断线，而当nf_conntrack表慢慢有空余位置时，客户端的连接慢慢会恢复。然而如果net.netfilter.nf_conntrack_max值过低，有些客户端可能会一直无法连接上。

net.ipv4.tcp_tw_recycle和net.ipv4.tcp_timestamps不能同时为1，否则会导致处理nat网络的客户端连接超时或者连接异常断开

/sbin/sysctl -p 后不用重启服务器

之前手误，应该是net.ipv4.tcp_tw_recycle和net.ipv4.tcp_timestamps不能同时为1，否则会造成nat网络的客户端超时

net.netfilter.nf_conntrack_max设置着，如果开了防火墙会生效，没开防火墙也不影响

@1:把net.ipv4.tcp_tw_recycle关掉的话，处于 TIME_WAIT 状态的连接数就会涨上去。当时是为了解决TIME_WAIT 过多，所以设置了net.ipv4.tcp_syncookies = 1; net.ipv4.tcp_tw_reuse = 1 ;net.ipv4.tcp_tw_recycle = 1;net.ipv4.tcp_fin_timeout = 30。那我要把net.ipv4.tcp_tw_recycle改成0吗？

TIME_WAIT状态的连接数量受net.ipv4.tcp_max_tw_buckets来限制，一般来说TIME_WAIT状态的连接数量不超过2万都没事。
TIME_WAIT是一个很正常的网络状态，不用担心。

@1:刚才问了我们的硬件人员，出问题的这个系统里的设备，从一开始就是用的路由器连接网络，那我3月份的时候就已经把net.ipv4.tcp_tw_recycle设置为1了，一直正常运行到6月底，将近3个月，那不应该是nat网络的客户端超时吧？

如果从使用人数及频率上来说，每个月都是逐渐增加的，但是从单月来说，不会突变。比如6月份没太大变化，但前半个月还好的，后半月却出问题了。
所以这才是我们一直疑惑的地方，程序没怎么改动过，一直好好运行着，为什么突然就出问题了？目前找到的这些原因，不管是防火墙，还是内核优化，还是nat网络，都不能很好解释为什么前面好，现在不好？（特别是没做什么改动，设备没大量增加的情况下）

另外还找到2个可能的原因：1.没有用MySQL组件；2.心跳检测，没有心跳的设备触发OnClose，但是OnClose里没有用Gateway::closeClient($client_id)；（但这2个原因感觉跟上面的一样，没法解释为什么前面好，现在不好）

问题比较多，有劳大神了~

net.ipv4.tcp_tw_recycle和net.ipv4.tcp_timestamps都是1的情况下，仅1台设备通过nat网络连接服务端没有问题，如果设备数大于1则有可能会出现问题。

连接数增加1000后又恢复的问题这个不好定位，从统计图里无法判断是什么连接，多的连接也不一定是设备连接，也有可能根本不是php产生的连接，有人在上面运行了个什么脚本或者某个软件升级啥的都有可能产生连接，有人用扫描软件建立起1000个连接也不是没可能，网络波动啥的都有可能，情况太多，太难定位了。即使现在有现场，你也几乎没办法定位到哪些连接是新增的，因为之前可能并没有给连接做分类统计。

没用到MySQL组件不会直接导致有什么问题，业务上注意使用单例以及mysql断线重连即可。设备定时向服务端上报心跳可以保持连接，心跳间隔最好小于1分钟。onClose代表连接已经断开，不用调用Gateway::closeClient($client_id)

@1:
http://doc.workerman.net/appendices/kernel-optimization.html
1.大神你好，我把net.ipv4.tcp_tw_recycle改成0了，net.ipv4.tcp_max_tw_buckets 改成20000了，然后从TCP监控图能看出，非活跃连接数non-established马上就上升到20000了，然后基本维持在上面。期间因为改了打开文件数，重启了一下，也看到马上又上升到20000，并维持在上面。不知道这样好不好？以前就是看到非活跃连接数non-established一直比较高，所以才把net.ipv4.tcp_tw_recycle开启的。截图的话，请看下面第2个回复（评论里带不了图）
2.我看到Linux内核调优里面，打开文件数，前2种方法里面都是修改为102400，只有第3种方法里面是改成了1024000，差了10倍，到底应该是改成多少？

@1:
我的服务器上，tcp_tw_reuse也开启着，它是用于TIME_WAIT重用，看到有文档说 “时间戳重用TIME_WAIT连接机制的前提是IP地址唯一性，得出新请求发起自同一台机器，但是如果是NAT环境下就不能这样保证了，于是在NAT环境下，TIME_WAIT重用还是有风险的。”

所以这意思是如果设备通过路由器连接的话，像上面说到的tw_recycle一样，也要关闭吗？

要关闭

进程打开文件数10万就差不多了，如果你服务器要支持超过10万的连接数，那就再调到你想要达到的连接数的值。

@1:
那现在关掉tw_recycle及tw_reuse的话，TIME_WAIT的数量就一直维持在tw_buckets设定值上，这正常吗？

大神前面说过“TIME_WAIT状态的连接数量受net.ipv4.tcp_max_tw_buckets来限制，一般来说TIME_WAIT状态的连接数量不超过2万都没事。” 按照这个说法的话，由于有net.ipv4.tcp_max_tw_buckets压制着，TIME_WAIT状态的连接数量应该就是不超过2万的吧？那就是都没事的？

TIME_WAIT的数量就一直维持在tw_buckets设定值正常。net.ipv4.tcp_max_tw_buckets限制了不会超过2万

@1:
多谢大神几天来的解答。
现在把tw_recycle关掉了几天了，从监控图来看，TIME_WAIT状态的连接数（即非活跃连接数non-established）一直维持在20000左右。即使是晚上低谷时段，活跃连接数established减少了三四千，TIME_WAIT状态的连接数还是维持在20000左右，没有减少。TIME_WAIT的数量好像不受实际连接数变化的影响？？
截图请看最后一个回复，多谢大神指教。

gatewayWorker内部有一些接口调用走的socket调用，会不断产生TIME_WAIT的连接

@1:总觉得不是很稳定，前几天还维持在活跃连接数established接近7千，今天到中午了还只有5千5左右，差了1千多。前面也看了GatewayWorker的分布式部署，想再拿一台服务器来做分布式部署。只是觉得我现在只有7千台设备的长连接，现在就用2台服务器来分布式部署，会不会早了点啊？
大神，分布式部署会不会对TCP长连接的效果会好一些？

@1:查看今天的销售记录的话，发现有四家店一笔订单都没有，这四家店的设备加起来差不多1千台。这4家点昨天还是有订单的，至少说明设备是有连接的。这样的话，感觉就是这4家店断了，但是奇怪的是，不是这4家店每家断了部分设备，而是这4家店里的设备都断了。真是奇怪。

通讯量不大的业务，服务器稍微好点的支持10万连接基本没有问题，但是不代表任何业务都可以支持这么大的量，能否支持这么大的量更多的是取决于业务本身。

是否增加服务器不是单单看连接数，要根据具体情况分析，主要看哪里是瓶颈，带宽？内存？cpu？达到瓶颈并且没办法再扩展则可以考虑加服务器。比如从之前截图看单台服务器有7000设备连接，单台设备每天处理的请求数达到3亿，每秒平均处理3000-4000请求，峰值应该会超过1万。整个系统负载是3到4左右，cpu使用率超过60%，cpu及负载已经算很高了。如果再来点突发请求可能cpu就跑满了，就会导致数据延迟、连接断开的各种问题。那么可以考虑增加服务器增加gatewayWorker的计算能力。

带宽是否跟得上也要注意下，看下监控带宽是否达到限定值，如果带宽不够也是可能造成连接断开的情况

还有就是业务优化：
正常情况下7000设备，假设每台设备10秒传输1次数据(已经算很频繁)，那么每秒也才700个请求，是目前请求量的1/5，如果每秒700请求系统cpu使用率和负载将大大降低，能承受的设备数会更多一些。所以看下客户端为什么会发送这么大量的请求，是否可以优化。

还有就是业务bug、客户端bug以及网络环境差导致断开。

我不清楚你们是什么业务，周末大部分公司都放假了，没订单很正常吧。有些公司还会周末断电断网，设备自然下线了。

@1:大神说到的截图17天50亿请求，是Gateway的请求数和BusinessWorker请求数的总和吗？
我想请教一下这个请求数有哪些部分组成啊？
因为确实觉得这个请求数特别高，于是我们就在我们的测试服务器上在OnMessage里把服务器收到的指令全部存到一个文件里。2台设备1个小时，服务器总共收到126条指令，对应的，服务器应回应126次，那么收发至少252次。但查看php start.php status(图见最后一个回复），Gateway的请求数就有851条，BusinessWorker的请求数也有260左右。远高于指令的数量。

另外还有一个，大神说过心跳间隔最好小于1分钟，是指$gateway->pingInterval这个的值吧？

恳请大神指教。

17天50亿是看的Gateway请求，这些请求包括硬件设备发往gateway的请求(包含心跳请求)，另外还有极小部分请求是服务启动时gateway与Worker建立连接时通讯的请求。

心跳最好是客户端发起，发起间隔小于1分钟，用于保活。

服务端可以用以下配置，服务端不发心跳，如果120秒没收到客户端心跳就断开连接
$gateway->pingInterval = 120;
$gateway->pingNotResponseLimit = 1;
$gateway->pingData = '';

@1:大神你好
1.我们服务器不主动发心跳包，但是设备发心跳包过来的话会回应，然后在服务器的start_gateway.php里面是这么设置的：
$gateway->pingInterval = 50;
$gateway->pingNotResponseLimit = 2;
$gateway->pingData = '';

2.如果是看Gateway请求的话，就像我前面说的，我们记录到文件里的数据显示，2台设备发过来的指令（包含心跳）总共就126条，服务器回应的没记录，但理论上是来几条回几条，那么总共就是126*2=252次请求，而php start.php status里统计的Gateway的请求数就有850多条，剔除极小部分请求是服务启动时gateway与Worker建立连接时通讯的请求的话，还是大很多啊。