描述:对接方请求我方接口,阶段性 报 timeout  conntion  链接异常

我方:阿里云 k8s 容器化部署

排查:

第一次因为istio节点数据不够,2021-11

1、查看nginx日志,发现 upstream timeout ,问 运维 nginx 转发到了 某一个 istio 上
2、随后 在 nginx 所在服务器 telnet  istio 所在ip,发现 没有反应

3、看 istio 监控,发现流量较高,但不能确定 是 istio 的压力大造成的

4、nginx 转发 配置了 2个 istio ,但是 总共有 11个 istio,整个集群有11个node
5、增加 nginx 转发 的 istio 个数,增加到 4个,发现我方接口趋于正常,观察一夜再说

6、第二天,对方反应 仍然有 2个 timeout,整体少了许多

7、扩展 服务规格 ,由 4c16g 升到 8g32g,待观察 是否还有问题

8、准备安装 istio 一套完整的监控,可以查看istio 的整体情况,到时候知道 istio 的峰值

9、扩充完 istio-ingressgateway ,我方接口响应时间恢复正常

第二次 我方接口夜间高峰时段响应超过30s, 系统告警

1、查看pod cpu 内存 正常,查看数据量近2个月增加了30%

2、增加  istio-ingressgateway 数量,增加一倍,观察一夜再说

3、情况没有改善,证明瓶颈不在 istio

4、增加pod tomcat 线程数,之前是默认值,250吧应该是,改成500,观察一夜

5、第二天无告警,笑的就像吃了蜜蜂屎,整个集群每秒并发最高 1万 ,525个pod

6、又过了几天,告警出现,悲催,看到jvm监控运行线程15,由此想到,数据源线程默认是15吧

7、增加最大线程数   Hikari-pool  50

8、
观察监控,静待佳音,优化之路,任重而道远,永无止境

待后续继续完善该文。。。

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐