关于processTimeout和processTimeoutHandler的设置问题
我在看GatewayWorker手册的时候，看到BusinessWorker类里有关processTimeout和processTimeoutHandler的说明，有几点疑问请教一下大神：
1.我没有在start_businessworker.php里面设置processTimeout，那么默认应该是30秒吧？
2.要实现单次执行时间超过30秒就会记录一条日志到workerman.log，我现在Events.php里面没在文件头部增加declare(ticks=1);语句，是不是要增加一下？
3.我在start_businessworker.php里面也没有设置processTimeoutHandler，那么是不是默认回调Workerman\Worker::log（即记录日志到GatewayWorker/workerman.log），且业务超时后默认执行进程重启操作，不需要我写程序返回假让进程重启吧？
请大神指教一下，多谢。
5694 10 1
10个回答
相似问题
年代过于久远，无法发表回答
1、对，30秒
2、declare(ticks=1);可以定位到在哪里耗时导致超时，declare(ticks=1);会对性能有点影响，默认不用开启declare(ticks=1);，当出现processTimeout时临时开启，然后reload生效排查问题
3、是的
我想查看这个，是因为我们现在的业务是共享设备，投放在外面的设备与服务器通过TCP长连接，用是GatewayWorker。目前大约有7000台设备，Linux内核优化和event扩展都做了，前面6月底的时候出现过TCP连接突然大量掉线，只剩3000左右维持着，查看日志没有任何东西。原本以为业务堵塞，日志里没记录下超时。所以想问要不要开启declare(ticks=1)。
当时做了修改Gateway和BusinessWorker进程数量，都没有效果。但到第三天再次修改了进程数量后，它逐渐恢复到原来的水平了，真是很崩溃。一直到现在都算稳定在运行。
然后今天出现了短时间TCP连接数增加了1000左右（以前是减少，这次是增多，一般这个时候外面投放的设备已经全部开启了，不应该是突然开启了1000台设备，从TCP连接图可以看出活跃连接数established稳定在7000多），但这也造成1000多台设备掉线，但是这次时间比较短，等客户告知我时，已经恢复了。所以查看php start.php status已经不是当时的情况了。现在贴上来2张图，一张是监控图表里的TCP变化图，一张是目前的status图。
想请教大神的是，有什么原因会造成此种情况？
[attach]1161[/attach]
[attach]1163[/attach]
从提供的信息和截图来看很难确定多出来的1000左右连接哪里来的，有可能是共享设备发起的连接，也有可能是服务端调用redis mysql等外部存储建立的连接，有可能网络出现暂时故障引起，也有可能是外部探测程序发起的连接。
不过从你的截图来看系统的负载有点高，top 看下哪些程序在消耗CPU。
TOP图截了2张，请大神帮忙看一下，非常感谢。
[attach]1168[/attach]
[attach]1167[/attach]
结合上面的php start.php status图，可以看出，CPU占用高的几个PID3389，3391等，它们的链接数（connections）一点也不多。
感觉是大量通讯导致的cpu使用偏高，status看到gateway17天处理了50亿左右请求，每天处理3亿请求，单服务器每天处理这么多请求算很多了。
sy的cpu占用达到38%，这个偏高，可能是gateway进程开的有点多，进程切换频繁导致，也可能是开了declare(ticks=1)影响。如果开了declare(ticks=1)可以尝试去掉后reload看sy是否有下降，如果是gateway进程数过多导致，可以尝试减少gateway进程数，更改进程数需要restart。
这个可能是因为安装了event扩展优化linux内核后没有restart重启gatewayWorker导致，安装扩展和优化内核reload是无效的，需要restart。 linux内核优化必须严格按照workerman手册 http://doc.workerman.net/appendices/kernel-optimization.html 来做，每一项都不能落下。之前有给其它项目定位无法建立大量连接问题时发现是linux内核优化有一项net.netfilter.nf_conntrack_max没有做导致无法建立大量连接。要想应对大并发，workerman手册中linux内核优化每一项都很重要，切记。
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
我想请问用手册里的方法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建立连接时通讯的请求的话，还是大很多啊。
在sysctl.conf文件中新增了：net.netfilter.nf_conntrack_max = 2621440
但是不管运行/sbin/sysctl -p，还是sysctl -p，都提示no such file or directory
这个后来查了资料，运行了lsmod |grep conntrack，以及modprobe ip_conntrack，然后再运行/sbin/sysctl -p就添加上了
[attach]1169[/attach]
把net.ipv4.tcp_tw_recycle改成0，net.ipv4.tcp_max_tw_buckets 改成20000后，TCP监控图
[attach]1170[/attach]
[attach]1172[/attach]
[attach]1191[/attach]