关于覆盖率

[Billyzou0741326]

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

[Billyzou0741326]

到这个地步了的话... 就该整理代码了

[Pearlulu]

白天覆盖率稳了，有统计晚高峰的吗？我看了下这两天的还是和之前一样，白天几乎没漏的，一到晚高峰就不如非解限版，会漏大概1/3，CPU负载也不是太高，流量26 27个GB，非解限版流量16GB左右。

[Billyzou0741326]

白天覆盖率稳了，有统计晚高峰的吗？我看了下这两天的还是和之前一样，白天几乎没漏的，一到晚高峰就不如非解限版，会漏大概1/3，CPU负载也不是太高，流量26 27个GB，非解限版流量16GB左右。

1/3会是风暴吗？风暴id的前半截是跟舰长一起的23333

[Billyzou0741326]

刚算了下 (768) / (1808005 - 1807198) 差不多95%吧

[Pearlulu]

不是风暴，我是和非解限版对比。可能还是网络问题，连接数多对网络质量要求高，用国内机器应该好些，可惜国内我只有1M带宽的，不知道能不能跑起来。

[Billyzou0741326]

不是风暴，我是和非解限版对比。可能还是网络问题，连接数多对网络质量要求高，用国内机器应该好些，可惜国内我只有1M带宽的，不知道能不能跑起来。

嗯... 有什么建议吗 任何策略都行，我看下实现的可行性

[Pearlulu]

你那里正常的话，我觉得可能是linux系统优化的关系，tcp连接数超过某个阈值就出问题了，用的都是全新安装的debian10默认的参数，我先优化了一下参数跑两天试试。

[Billyzou0741326]

你那里正常的话，我觉得可能是linux系统优化的关系，tcp连接数超过某个阈值就出问题了，用的都是全新安装的debian10默认的参数，我先优化了一下参数跑两天试试。

用的是Linux分支的版本吗 Linux分支的调整了nofile上限

[Billyzou0741326]

有root权限的话可以系统层面上提升弄nofile上限（限制tcp句柄数量的好像是）

[Pearlulu]

用的是Linux分支的版本吗 Linux分支的调整了nofile上限

是的，ulimit和file-max一开始就改过了，tcp超时和回收啥的参数没弄过。

[Billyzou0741326]

毫无头绪2333 tcp连接策略是非正常断线则立刻重连 有时候断得多容易刷屏我就屏蔽掉了tcp连接的状态 按理说漏过舰长大概率是房间掉线了吧 或者network I/O出问题了

[Pearlulu]

我直接在一台vps上同时开17号的版本和最新版，这下全都一样了。 还是同样的结果。。未解限版200个舰长，最新版162个舰长，看日志也看不出来啥头绪。 运行了一段时间再统计的，排除了其他干扰。

[Billyzou0741326]

162/200漏的太多了啊.... 我专门写个限制版给你吧~

[Pearlulu]

162/200漏的太多了啊.... 我专门写个限制版给你吧~

大佬就按自己思路弄就好了，不用专门写啊。而且你那边测试正常，其实高峰期解限版也就1W多连接数，和五六千连接数的限制版不应该出现这种差别才对。我觉得可能不是连接数的关系，我再找找原因。

[Billyzou0741326]

嗯 我期待好消息

[Pearlulu]

下午到晚上8点半之前，限制版会漏几个，解限版几乎没漏，8点半之后解限版就开始漏了。 初步判断是晚上国际出口拥堵，VPS到B站服务器走的电信线路，ping非常稳定，但是一到8点半后会被强制丢包QOS。

[Billyzou0741326]

原来是这样... 那我可以安心肝覆盖率了hhh

[Pearlulu]

不过我还是挺好奇为啥限制版受到网络影响就比较小，是掉线重连的逻辑不一样吗

[Billyzou0741326]

断线重连的策略没变 但是网络读写的数量变得比较恐怖了 毕竟高峰期的弹幕凶残度也是很强了 大量事件堵塞的话会出问题吧

[Pearlulu]

刚挂着看了一会儿，最左边是你的服务器，中间是香港的3M小水管cn2 gia，右边是到弹幕服务器丢包1%以下的美国服务器

[Billyzou0741326]

我服务器刚刚被412风控了23333

[Billyzou0741326]

嗯… 刚刚跑的是测试版 error掉了好几次

[Pearlulu]

8点开始的一个多小时 我看你的服务器是走的普通电信163线路，竟然比我走CN2线路的网络还稳定。

忽然想到broadcastlv.chat.bilibili.com有4个IP，两个北京两个上海，服务器到4个IP的网络质量都不一样。现在这个时间高的连接数有5000，低的2800，应该是DNS解析随机获得的IP，可能网络差的连接数高，也可能网络好的连接数高。不知道自己主动控制有没有效果，TCP连接断开后就轮换另一个IP连接，请求域名的话DNS可能会解析到重复IP，按顺序轮换到最后应该是网络好的IP连接数多吧。 旧版的4个IP连接数都在1000多点，没什么网络压力

[Billyzou0741326]

果然是大佬23333

ip获取这些我不太会呢~

[Billyzou0741326]

看来要手动getaddr吗... 然后采用均衡负载吧 我先发布一下 expireAt的修复和静态的新策略

[lovezm]

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应该不是关键问题 关键问题在于未监听到的房间 其实能够接受

[Billyzou0741326]

借一下你们的command23333

[Billyzou0741326]

对了 Clone新的版本的时候别忘了把旧的 src/db/record.json 提出来放进新的里

[Billyzou0741326]

8点开始的一个多小时 我看你的服务器是走的普通电信163线路，竟然比我走CN2线路的网络还稳定。

忽然想到broadcastlv.chat.bilibili.com有4个IP，两个北京两个上海，服务器到4个IP的网络质量都不一样。现在这个时间高的连接数有5000，低的2800，应该是DNS解析随机获得的IP，可能网络差的连接数高，也可能网络好的连接数高。不知道自己主动控制有没有效果，TCP连接断开后就轮换另一个IP连接，请求域名的话DNS可能会解析到重复IP，按顺序轮换到最后应该是网络好的IP连接数多吧。 旧版的4个IP连接数都在1000多点，没什么网络压力

程序是跑得越久覆盖率越高的应该

[Billyzou0741326]

猜测DNS解析是由b站反向代理均衡分配的 直接用url让b站分配就好…

[Pearlulu]

程序是跑得越久覆盖率越高的应该

程序是从中午开始跑的，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的连接数最多。

说了一堆废话，其实换个网络好点的服务器或者用国内服务器就完美解决了。。

[Billyzou0741326]

太强了 我可以另写个测试 记录tcp连接的掉线率和ip之间的关联

[Billyzou0741326]

顺便提下... 我关闭TCP异常断线的显示之前，有过被断线提示刷屏的情况，甚至连接数很少的时候断线频率也相当高

我先commit一下提取动态房间策略的更新，然后找时间着重测TCP Packet Loss的状况

学校的服务器还是相当稳的看来

[Pearlulu]

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 按上面那个想法改了一下，今晚试试有没有效果，现在网络好，还是平均的。

[lovezm]

看了一下服务器目前的连接 还算挺稳 不知道漏没漏 没看日志

[Pearlulu]

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无效。 还是老老实实换线路靠谱的服务器才是正解。

[Billyzou0741326]

那关键就在静态房间了... 现在的收集策略感觉也应该不慢了

[Pearlulu]

那关键就在静态房间了... 现在的收集策略感觉也应该不慢了

虽然这个办法不靠谱，不过顺便测试了下到底是不是网络问题。我直接把掉线率最高的两个IP删了，最后一切正常了，和你学校服务器推送的舰长个数竟然一样了。应该证实了网络问题确实会影响覆盖率，会有不掉线但是接收不到数据的连接。其实折腾半天和推测的差不多。。 现在覆盖率感觉很高了，快到极限了吧。

[Billyzou0741326]

hhh提升空间永远有的 静态主要是想覆盖黑屏上舰 毕竟去掉了下播判定

[Pearlulu]

还是关于网络问题，拯救辣鸡美国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秒的舰长就不会推送了。

[Billyzou0741326]

想不到什么太好的检测策略 毕竟定期检查绝对不能低于30秒 最好不低于35秒

[Pearlulu]

为了拯救辣鸡网络，又改了下，持续统计掉线，根据最近的掉线率直接重连掉线率最低的IP，连接数和当前网络质量比较匹配。 3967 8506 4521 2553 高峰期800个只比学校服务器少了7个，反正是比之前200个少38个好多了。

检测策略我等会儿试试放到onData那里，收到消息就开始计时，好像有个学名叫啥函数防抖还是什么来着 clearTimeout(timer); timer = setTimeout(function(){//关闭，重连},35*1000); 用setInterval检测时间浮动太大了。

[Pearlulu]

想不到什么太好的检测策略 毕竟定期检查绝对不能低于30秒 最好不低于35秒

我试了那个setInterval的时间可以低于30秒的，我现在设的10秒，没事，主要是+new Date() - this.lastRead不能低于30秒，后面这个低了会无限重连。

[Billyzou0741326]

嗯嗯 明白了hhh

[Pearlulu]

应该算是勉强拯救到了 我挺想PR让你们也测试下，IP数组是通过向DNS请求域名获取的，但是说出来你可能不信，我不知道怎么PR，从没用过这功能。。

[Billyzou0741326]

你可以fork一个，我从你的fork那边clone就好了

[Pearlulu]

检测掉线换到onData那里还没试过靠不靠谱，那个推送的时间限制是在哪里改呢？我想改大点试试

[lovezm]

搞搞搞！

[Billyzou0741326]

onData 检测掉线的问题是... 掉了就不再触发onData了

[Billyzou0741326]

推送的时间限制是指？