服务注册疑似心跳维持不住

[cdmaji]

注册规模：400个service*100个instance,一共4W个instance；（400线程并发）
Nacos-server：3个Node，分别8G + 1 *4Cores
现象 ：大部分Service，通过getAllInstances获取到的instance在上线过程中持续波动，不停的升降(如一共100个：90...80...73...82....)，现象看到就像心跳维持不住。

在服务端对于心跳处理的逻辑中，心跳上报是交逻辑cpu/2的线程池在处理，实际处理的逻辑是将上报的ip+port和服务端维持的service下的instance列表做遍历，匹配成功后更新心跳，这个遍历效率明显不高，如果http请求过大&cpu load过高可能导致心跳处理不及时，导致client端日志并没有打印心跳上报异常，但是效果是健康instance数一直不稳定，始终上不成功。

理论上如果并发较大，服务器资源配置不高的情况下可以通过横扩增加可负载数，但是这块的遍历逻辑感觉可以优化下；另外对比官网性能测试报告(1+w的tps)我们实测的情况差距较大。

另外：我的测试环境中，350个service*100个instance,一共3.5W个instance没有问题。

[horizonzy]

我来跟这个。

[KomachiSion]

100个实例应该处理的很快啊。即使只有7个线程问题应该也不大。
3台node 理论上每个node大概只处理1w多请求。
每秒处理2k+ 不应该会处理不过来。

[KomachiSion]

如果是4C8G * 3，以1.0的架构抗4w个实例可能是有点压力了。如果把线程数改多可能可以处理过来，但是不清楚是否有其他的风险问题。

另外您有注册了3.5w个实例时候的CPU数据吗？

[cdmaji]

上面描述有点错误，Nacos-server：3个Node，分别8G + 4C(已修改)
通过arthas方法监控，看到一个node上每秒处理才100+。

[KomachiSion]

上面描述有点错误，Nacos-server：3个Node，分别8G + 4C(已修改)
通过arthas方法监控，看到一个node上每秒处理才100+。

trace一下check的方法，看下耗时。
这里可能是需要优化了，改成和核心数一样可能比较好。

[cdmaji]

上面描述有点错误，Nacos-server：3个Node，分别8G + 4C(已修改)
通过arthas方法监控，看到一个node上每秒处理才100+。

trace一下check的方法，看下耗时。
这里可能是需要优化了，改成和核心数一样可能比较好。

嗯，好的，我们计划先调整线程池大小试试

[horizonzy]

应该是线程池的处理线程太少了，导致task处理不过来。关于健康检查的线程我觉得优化成可配置的，如果用户没有配置，使用和核心数一样的线程数来进行处理。