Open Billyzou0741326 opened 4 years ago
id | roomid | type | name | created_at (时差) |
---|---|---|---|---|
1808040 | 14201872 | guard | 舰长 | 2019-12-28 09:51:38 |
1808041 | 2603963 | guard | 舰长 | 2019-12-28 09:52:56 |
1808042 | 21154366 | guard | 舰长 | 2019-12-28 09:53:08 |
1808043 | 21539718 | guard | 舰长 | 2019-12-28 09:53:16 |
1808044 | 21448055 | storm | 节奏风暴 | 2019-12-28 09:53:22 |
1808045 | 10556121 | guard | 舰长 | 2019-12-28 09:53:31 |
1808046 | 128135 | storm | 节奏风暴 | 2019-12-28 09:54:19 |
1808047 | 10556121 | guard | 舰长 | 2019-12-28 09:56:16 |
1808048 | 1448688 | guard | 舰长 | 2019-12-28 09:56:26 |
1808049 | 2259890 | guard | 舰长 | 2019-12-28 09:56:36 |
1808050 | 10556121 | guard | 舰长 | 2019-12-28 09:57:36 |
1808051 | 21570283 | storm | 节奏风暴 | 2019-12-28 09:57:42 |
1808052 | 302816 | guard | 舰长 | 2019-12-28 09:57:46 |
1808053 | 21539718 | guard | 舰长 | 2019-12-28 09:58:01 |
1808054 | 7654470 | guard | 舰长 | 2019-12-28 09:58:01 |
1808055 | 10642428 | guard | 舰长 | 2019-12-28 09:58:13 |
1808056 | 21539718 | guard | 舰长 | 2019-12-28 09:58:31 |
1808057 | 4348162 | guard | 舰长 | 2019-12-28 09:59:48 |
1808058 | 2259890 | guard | 舰长 | 2019-12-28 10:00:21 |
1808060 | 2613601 | guard | 提督 | 2019-12-28 10:01:01 |
1808061 | 824494 | storm | 节奏风暴 | 2019-12-28 10:01:30 |
1808062 | 4641942 | storm | 节奏风暴 | 2019-12-28 10:01:57 |
1808063 | 45972 | guard | 舰长 | 2019-12-28 10:03:01 |
1808064 | 21580043 | guard | 舰长 | 2019-12-28 10:03:11 |
1808065 | 21539718 | guard | 舰长 | 2019-12-28 10:03:56 |
1808066 | 12594500 | guard | 提督 | 2019-12-28 10:04:46 |
1808067 | 43668 | guard | 舰长 | 2019-12-28 10:05:16 |
1808068 | 757349 | storm | 节奏风暴 | 2019-12-28 10:05:29 |
1808069 | 3268068 | storm | 节奏风暴 | 2019-12-28 10:05:48 |
1808070 | 21448055 | storm | 节奏风暴 | 2019-12-28 10:06:04 |
1808071 | 21539718 | guard | 舰长 | 2019-12-28 10:06:21 |
1808072 | 21517049 | guard | 舰长 | 2019-12-28 10:06:58 |
1808073 | 3702265 | storm | 节奏风暴 | 2019-12-28 10:09:29 |
1808074 | 2603963 | guard | 舰长 | 2019-12-28 10:09:51 |
1808075 | 43668 | guard | 舰长 | 2019-12-28 10:10:21 |
1808076 | 3448829 | storm | 节奏风暴 | 2019-12-28 10:11:34 |
1808077 | 2625423 | guard | 舰长 | 2019-12-28 10:13:03 |
1808078 | 21517654 | guard | 舰长 | 2019-12-28 10:13:08 |
1808079 | 281727 | guard | 舰长 | 2019-12-28 10:15:11 |
1808080 | 11619634 | storm | 节奏风暴 | 2019-12-28 10:15:24 |
1808081 | 1011 | guard | 舰长 | 2019-12-28 10:15:43 |
1808082 | 21386005 | guard | 舰长 | 2019-12-28 10:17:31 |
1808084 | 21611039 | guard | 舰长 | 2019-12-28 10:18:46 |
1808085 | 12594500 | guard | 提督 | 2019-12-28 10:20:21 |
1808086 | 47557 | guard | 舰长 | 2019-12-28 10:22:18 |
1808087 | 21685737 | guard | 舰长 | 2019-12-28 10:22:43 |
1808088 | 21386005 | guard | 舰长 | 2019-12-28 10:23:51 |
1808089 | 21331425 | guard | 舰长 | 2019-12-28 10:24:11 |
1808090 | 21331425 | guard | 舰长 | 2019-12-28 10:24:41 |
1808091 | 3647211 | guard | 舰长 | 2019-12-28 10:26:11 |
1808092 | 3647211 | guard | 舰长 | 2019-12-28 10:26:21 |
1808093 | 21539718 | guard | 舰长 | 2019-12-28 10:26:41 |
1808094 | 21580043 | guard | 舰长 | 2019-12-28 10:27:46 |
1808095 | 21511979 | storm | 节奏风暴 | 2019-12-28 10:29:24 |
1808096 | 21525988 | guard | 舰长 | 2019-12-28 10:30:31 |
1808097 | 8128451 | storm | 节奏风暴 | 2019-12-28 10:31:34 |
1808098 | 392661 | guard | 舰长 | 2019-12-28 10:33:18 |
1808100 | 10556121 | guard | 舰长 | 2019-12-28 10:35:11 |
1808101 | 65482 | guard | 舰长 | 2019-12-28 10:36:13 |
1808102 | 12834857 | guard | 舰长 | 2019-12-28 10:39:56 |
1808103 | 21620337 | guard | 舰长 | 2019-12-28 10:39:56 |
1808104 | 989573 | guard | 舰长 | 2019-12-28 10:40:18 |
1808106 | 11619634 | guard | 舰长 | 2019-12-28 10:41:48 |
1808108 | 27760 | storm | 节奏风暴 | 2019-12-28 10:43:48 |
1808109 | 788361 | guard | 舰长 | 2019-12-28 10:46:58 |
1808110 | 21709053 | guard | 舰长 | 2019-12-28 10:51:18 |
1808111 | 3647211 | guard | 舰长 | 2019-12-28 10:51:41 |
1808112 | 424902 | storm | 节奏风暴 | 2019-12-28 10:51:47 |
1808113 | 306236 | guard | 舰长 | 2019-12-28 10:54:03 |
1808114 | 10556121 | guard | 舰长 | 2019-12-28 10:54:06 |
1808115 | 10556121 | guard | 舰长 | 2019-12-28 10:55:31 |
1808116 | 3297956 | guard | 舰长 | 2019-12-28 10:56:21 |
1808117 | 3580061 | guard | 舰长 | 2019-12-28 10:59:16 |
1808118 | 6065099 | guard | 舰长 | 2019-12-28 11:03:08 |
1808119 | 289079 | storm | 节奏风暴 | 2019-12-28 11:07:40 |
1808120 | 1362072 | guard | 舰长 | 2019-12-28 11:09:29 |
1808121 | 21456469 | storm | 节奏风暴 | 2019-12-28 11:09:57 |
1808122 | 7603080 | guard | 舰长 | 2019-12-28 11:10:16 |
1808123 | 544793 | guard | 舰长 | 2019-12-28 11:10:46 |
1808124 | 3641727 | storm | 节奏风暴 | 2019-12-28 11:13:25 |
1808125 | 14085407 | guard | 舰长 | 2019-12-28 11:14:36 |
1808126 | 21611039 | guard | 舰长 | 2019-12-28 11:14:41 |
1808127 | 3269965 | guard | 舰长 | 2019-12-28 11:15:29 |
1808128 | 81711 | guard | 舰长 | 2019-12-28 11:16:56 |
1808129 | 38781 | guard | 舰长 | 2019-12-28 11:17:26 |
1808130 | 12096201 | guard | 舰长 | 2019-12-28 11:18:44 |
1808131 | 12096201 | guard | 舰长 | 2019-12-28 11:19:14 |
1808132 | 6140913 | guard | 舰长 | 2019-12-28 11:19:21 |
1808133 | 11067408 | guard | 舰长 | 2019-12-28 11:22:01 |
1808134 | 544793 | guard | 舰长 | 2019-12-28 11:23:01 |
1808135 | 2777322 | guard | 舰长 | 2019-12-28 11:24:24 |
1808136 | 21058142 | guard | 舰长 | 2019-12-28 11:25:16 |
1808137 | 5503854 | guard | 舰长 | 2019-12-28 11:27:46 |
1808138 | 991520 | storm | 节奏风暴 | 2019-12-28 11:30:53 |
1808139 | 1267921 | guard | 舰长 | 2019-12-28 11:33:11 |
1808140 | 1135146 | guard | 舰长 | 2019-12-28 11:33:59 |
1808141 | 3113410 | guard | 舰长 | 2019-12-28 11:36:16 |
1808142 | 288400 | guard | 舰长 | 2019-12-28 11:36:26 |
1808143 | 1378879 | guard | 舰长 | 2019-12-28 11:36:31 |
1808144 | 14805603 | guard | 舰长 | 2019-12-28 11:39:09 |
1808145 | 3465508 | guard | 舰长 | 2019-12-28 11:40:51 |
1808146 | 5335284 | guard | 舰长 | 2019-12-28 11:44:14 |
1808147 | 8128451 | guard | 舰长 | 2019-12-28 11:46:34 |
1808148 | 10556121 | guard | 舰长 | 2019-12-28 11:48:31 |
1808149 | 11546841 | storm | 节奏风暴 | 2019-12-28 11:49:13 |
到这个地步了的话... 就该整理代码了
白天覆盖率稳了,有统计晚高峰的吗?我看了下这两天的还是和之前一样,白天几乎没漏的,一到晚高峰就不如非解限版,会漏大概1/3,CPU负载也不是太高,流量26 27个GB,非解限版流量16GB左右。
白天覆盖率稳了,有统计晚高峰的吗?我看了下这两天的还是和之前一样,白天几乎没漏的,一到晚高峰就不如非解限版,会漏大概1/3,CPU负载也不是太高,流量26 27个GB,非解限版流量16GB左右。
1/3会是风暴吗?风暴id的前半截是跟舰长一起的23333
刚算了下 (768) / (1808005 - 1807198)
差不多95%吧
不是风暴,我是和非解限版对比。可能还是网络问题,连接数多对网络质量要求高,用国内机器应该好些,可惜国内我只有1M带宽的,不知道能不能跑起来。
不是风暴,我是和非解限版对比。可能还是网络问题,连接数多对网络质量要求高,用国内机器应该好些,可惜国内我只有1M带宽的,不知道能不能跑起来。
嗯... 有什么建议吗 任何策略都行,我看下实现的可行性
你那里正常的话,我觉得可能是linux系统优化的关系,tcp连接数超过某个阈值就出问题了,用的都是全新安装的debian10默认的参数,我先优化了一下参数跑两天试试。
你那里正常的话,我觉得可能是linux系统优化的关系,tcp连接数超过某个阈值就出问题了,用的都是全新安装的debian10默认的参数,我先优化了一下参数跑两天试试。
用的是Linux分支的版本吗 Linux分支的调整了nofile上限
有root权限的话可以系统层面上提升弄nofile上限(限制tcp句柄数量的好像是)
用的是Linux分支的版本吗 Linux分支的调整了nofile上限
是的,ulimit和file-max一开始就改过了,tcp超时和回收啥的参数没弄过。
毫无头绪2333 tcp连接策略是非正常断线则立刻重连 有时候断得多容易刷屏我就屏蔽掉了tcp连接的状态 按理说漏过舰长大概率是房间掉线了吧 或者network I/O出问题了
我直接在一台vps上同时开17号的版本和最新版,这下全都一样了。 还是同样的结果。。未解限版200个舰长,最新版162个舰长,看日志也看不出来啥头绪。 运行了一段时间再统计的,排除了其他干扰。
162/200漏的太多了啊.... 我专门写个限制版给你吧~
162/200漏的太多了啊.... 我专门写个限制版给你吧~
大佬就按自己思路弄就好了,不用专门写啊。而且你那边测试正常,其实高峰期解限版也就1W多连接数,和五六千连接数的限制版不应该出现这种差别才对。我觉得可能不是连接数的关系,我再找找原因。
嗯 我期待好消息
下午到晚上8点半之前,限制版会漏几个,解限版几乎没漏,8点半之后解限版就开始漏了。 初步判断是晚上国际出口拥堵,VPS到B站服务器走的电信线路,ping非常稳定,但是一到8点半后会被强制丢包QOS。
原来是这样... 那我可以安心肝覆盖率了hhh
不过我还是挺好奇为啥限制版受到网络影响就比较小,是掉线重连的逻辑不一样吗
断线重连的策略没变 但是网络读写的数量变得比较恐怖了 毕竟高峰期的弹幕凶残度也是很强了 大量事件堵塞的话会出问题吧
刚挂着看了一会儿,最左边是你的服务器,中间是香港的3M小水管cn2 gia,右边是到弹幕服务器丢包1%以下的美国服务器
我服务器刚刚被412风控了23333
嗯… 刚刚跑的是测试版 error掉了好几次
8点开始的一个多小时 我看你的服务器是走的普通电信163线路,竟然比我走CN2线路的网络还稳定。
忽然想到broadcastlv.chat.bilibili.com有4个IP,两个北京两个上海,服务器到4个IP的网络质量都不一样。现在这个时间高的连接数有5000,低的2800,应该是DNS解析随机获得的IP,可能网络差的连接数高,也可能网络好的连接数高。不知道自己主动控制有没有效果,TCP连接断开后就轮换另一个IP连接,请求域名的话DNS可能会解析到重复IP,按顺序轮换到最后应该是网络好的IP连接数多吧。 旧版的4个IP连接数都在1000多点,没什么网络压力
果然是大佬23333
ip获取这些我不太会呢~
看来要手动getaddr吗... 然后采用均衡负载吧
我先发布一下 expireAt
的修复和静态的新策略
netstat -plan|grep :2243|awk {'print $5'}|cut -d: -f 1|sort|uniq -c|sort -nk 1 netstat -an | grep 120.92.144.250 |wc -l && netstat -an | grep 120.92.78.57 |wc -l && netstat -an | grep 120.92.158.137 |wc -l && netstat -an | grep 120.92.112.150 |wc -l 1185 1248 1380 1381 漏其实没有漏多少 tcp应该不是关键问题 关键问题在于未监听到的房间 其实能够接受
借一下你们的command23333
对了 Clone新的版本的时候别忘了把旧的 src/db/record.json
提出来放进新的里
8点开始的一个多小时 我看你的服务器是走的普通电信163线路,竟然比我走CN2线路的网络还稳定。
忽然想到broadcastlv.chat.bilibili.com有4个IP,两个北京两个上海,服务器到4个IP的网络质量都不一样。现在这个时间高的连接数有5000,低的2800,应该是DNS解析随机获得的IP,可能网络差的连接数高,也可能网络好的连接数高。不知道自己主动控制有没有效果,TCP连接断开后就轮换另一个IP连接,请求域名的话DNS可能会解析到重复IP,按顺序轮换到最后应该是网络好的IP连接数多吧。 旧版的4个IP连接数都在1000多点,没什么网络压力
程序是跑得越久覆盖率越高的应该
猜测DNS解析是由b站反向代理均衡分配的 直接用url让b站分配就好…
程序是跑得越久覆盖率越高的应该
程序是从中午开始跑的,8点开始是指网页刷新了一下重新统计。
下面说的很麻烦,只针对高峰期网络差的,乱七八糟的还可能是错的,而且用处不大,只是想到了说一下,聊胜于无,万一哪天有用呢。。
先总结一下,监控程序除了更新以外,基本是一直跑着(VPS闲置着,不跑点流量不舒服。。),统计的话是打开那个前端模板网页,同时连几个服务器即时显示结果,或者同一个服务器同时开旧版和新版,连不同的端口。这几天无一例外都是8点半后高峰期开始漏得多,最终猜测是晚高峰网络丢包问题,不停有连接掉线。
根据一般的负载均衡方案推测B站的,DNS负载均衡 -->4个反代IP -->中间各种处理 -->后端。而DNS一般是根据所有用户的解析请求来负载均衡的,监控程序这点请求基本不会影响什么,也就是说它默认用户到4个IP的网络情况都是好的,不会管某个用户到某个IP的网络情况如何。这4个IP应该能承载很高的负载,1万连接数或者1000连接数对它们来说差别不大。 纯理论上,tcp1请求域名得到ip1,tcp2请求域名得到ip2...按照1234这样循环。白天网络状况好,一切正常无影响。晚上高峰出现一些状况,4个IP中有两个IP可以直接ping,有两个IP禁ping了只能tcpping,统一通过tcpping测试,发现服务器到ip1丢包0%,到ip2丢包10%,到IP3丢包20%,到IP4丢包30%,连接数都是4000。推测连接IP4的就会经常掉线导致漏掉舰长,掉线之后重连请求域名,DNS服务器返回IP(因为还有其他用户的请求影响DNS负载均衡,所以可能大概率返回同一个IP,比如上面的截图57结尾IP有5000多连接数,之后甚至到了6000,高一大截,实测服务器到57结尾IP丢包23%,到150结尾IP丢包0%)。 想要的结果是经过不停断线重连(连接ip1的也会断)后,网络最好的IP1连接数最多,然后依次是ip234。如果程序初始化时请求域名得到DNS返回的A记录4个IP,存为数组,用方法返回wsUri.host。每个TCP连接记录连接的是哪个IP,第一次记录是空的,就数组循环平均返回ip。之后TCP连接掉线重连,读取之前记录的IP找到在数组中对应的位置key,返回key+1的IP,key+1等于4就返回第一个IP。按上面假设的网络质量,一段时间后,应该就是IP1的连接数最多。
说了一堆废话,其实换个网络好点的服务器或者用国内服务器就完美解决了。。
太强了 我可以另写个测试 记录tcp连接的掉线率和ip之间的关联
顺便提下... 我关闭TCP异常断线的显示之前,有过被断线提示刷屏的情况,甚至连接数很少的时候断线频率也相当高
我先commit一下提取动态房间策略的更新,然后找时间着重测TCP Packet Loss的状况
学校的服务器还是相当稳的看来
netstat -an | grep 120.92.112.150 | wc -l && netstat -an | grep 120.92.78.57 | wc -l && netstat -an | grep 120.92.144.250 | wc -l && netstat -an | grep 120.92.158.137 | wc -l 1794 1792 1793 1794 按上面那个想法改了一下,今晚试试有没有效果,现在网络好,还是平均的。
看了一下服务器目前的连接 还算挺稳 不知道漏没漏 没看日志
netstat -an | grep 120.92.112.150 | wc -l && netstat -an | grep 120.92.78.57 | wc -l && netstat -an | grep 120.92.144.250 | wc -l && netstat -an | grep 120.92.158.137 | wc -l 1794 1792 1793 1794 按上面那个想法改了一下,今晚试试有没有效果,现在网络好,还是平均的。
虽然最后连接数是按照预期在变动,网络好的连接数多,网络差的连接数少。 2737 2352 3637 3033 但是实际上没作用,上面的推测基本是错的,高峰期来的时候,绝大多数漏掉的房间没有掉过线。可能是连接上了网络差的,由于拥堵没接收到数据也没掉线,所以掉线重连换网络好的IP无效。 还是老老实实换线路靠谱的服务器才是正解。
那关键就在静态房间了... 现在的收集策略感觉也应该不慢了
那关键就在静态房间了... 现在的收集策略感觉也应该不慢了
虽然这个办法不靠谱,不过顺便测试了下到底是不是网络问题。我直接把掉线率最高的两个IP删了,最后一切正常了,和你学校服务器推送的舰长个数竟然一样了。应该证实了网络问题确实会影响覆盖率,会有不掉线但是接收不到数据的连接。其实折腾半天和推测的差不多。。 现在覆盖率感觉很高了,快到极限了吧。
hhh提升空间永远有的 静态主要是想覆盖黑屏上舰 毕竟去掉了下播判定
还是关于网络问题,拯救辣鸡美国VPS(毕竟便宜) 不知道我理解得对不对,healthCheck45秒运行一次,假设某个连接00:00:50的时候刚好healthCheck正常,该连接房间00:01:01上了个舰,00:01:02连接堵塞无法继续接收到数据但是没掉线,00:01:03、00:01:04、00:01:05该房间又连续上了三个舰,00:01:35healthCheck在34秒前有消息认为连接正常,00:02:20再次healthCheck发现连接异常,开始重连,这个时候离后面三个上舰时间已经超过70秒了。监控程序似乎是超过30秒的舰长就不会推送了。
想不到什么太好的检测策略 毕竟定期检查绝对不能低于30秒 最好不低于35秒
为了拯救辣鸡网络,又改了下,持续统计掉线,根据最近的掉线率直接重连掉线率最低的IP,连接数和当前网络质量比较匹配。 3967 8506 4521 2553 高峰期800个只比学校服务器少了7个,反正是比之前200个少38个好多了。
检测策略我等会儿试试放到onData那里,收到消息就开始计时,好像有个学名叫啥函数防抖还是什么来着 clearTimeout(timer); timer = setTimeout(function(){//关闭,重连},35*1000); 用setInterval检测时间浮动太大了。
想不到什么太好的检测策略 毕竟定期检查绝对不能低于30秒 最好不低于35秒
我试了那个setInterval的时间可以低于30秒的,我现在设的10秒,没事,主要是+new Date() - this.lastRead不能低于30秒,后面这个低了会无限重连。
嗯嗯 明白了hhh
应该算是勉强拯救到了 我挺想PR让你们也测试下,IP数组是通过向DNS请求域名获取的,但是说出来你可能不信,我不知道怎么PR,从没用过这功能。。
你可以fork一个,我从你的fork那边clone就好了
检测掉线换到onData那里还没试过靠不靠谱,那个推送的时间限制是在哪里改呢?我想改大点试试
搞搞搞!
onData
检测掉线的问题是... 掉了就不再触发onData了
推送的时间限制是指?