杨翊 SionYang

Client change for service ....... 这个日志就是某个服务的某个实例发生了变化， 比如健康检查状态变了，或者有新注册，或者更新。 http check started before last one finished 这个日志应该就是你上面提的问题，因为连接超时，或者线程池不足，导致任务积压了，下一次的检查任务已经启动，但是之前的还没有结束。 如果目前已经出现这个问题，建议扩容nacos节点，把健康检查的压力分散到多个节点上。

1. 如果是进程crash的话可能可以， 但是如果是系统层面的宕机，可能需要从系统日志里去分析了。 2. 这个报错通常是网络问题，请求尝试发送的时候，链接已经断开了。

> 1、已经查明是内存溢出导致节点直接宕机 2、在重新复现模拟过程中，该问题能直接复现，在循环报错的过程中，telnet 所有端口，服务器之间通信是没问题的，有没有其他人或者你们自己test的时候遇到想同的情况么？为什么重启之后，会存在将近十分钟左右的网络异常啊？如果是短时间的抖动还能理解。 我自己部署的环境，故障演练从没有出现过这个问题，有这个报错都是出现了底层网络故障或节点LOAD很高的情况。 因为这个报错完全是由Grpc爆出的，nacos没有对grpc做改动，因此只有网络问题导致连接断开，或者两端中其中一端存在资源问题（CPU、内存）不足导致。

Great suggest, and I think can do more configuration about grpc with `GrpcClientConfig`

udp push is an enhancement way to push data to client 1.X. Actual 1.X client use polling way to get data as core way, and the data with the lastTime...

所以udp推送只能算是优化， 在没有乱序没有网络故障和网络防火墙的时候，能比轮询查询更快的感知到列表变化， 但是当有乱序、故障、或udp防火墙的时候，udp不可达或达的数据有问题，会通过核心的轮询查询或者最新的正确数据。

超时无非3种可能： 1. 服务端负载高，请求无法及时响应， 自查是否服务端处于高CPU，线程池使用满，FullGC等问题 2. 网络问题，请求丢包或服务端回包丢失 3. 客户端负载高，请求已返回，但是客户端没有资源处理，导致积压在tcp队列中，或任务队列中，自查是否应用端处于高CPU，线程池使用满，FullGC等问题

如果你确认客户端服务端都没有负载，没有积压，那就是网络问题呗，丢包了

升级一下python-sdk版本试一下呢？ 我也没法复现。

信息过少，无法判断问题，可以尝试多安装一些必要的VC++运行库后重试。