记录一次机器CPU高负荷占用导致服务不可用

最新推荐文章于 2024-08-30 18:33:43 发布

Lucas在干嘛

最新推荐文章于 2024-08-30 18:33:43 发布

阅读量473

点赞数

分类专栏：基础技术 linux操作

本文链接：https://blog.csdn.net/Lucas66666/article/details/119654238

版权

4 篇文章 0 订阅

订阅专栏

2 篇文章 0 订阅

订阅专栏

接到上游调用方反馈到服务一直504，根本没办法使用，同时机器cpu 监控一直报警
在这里插入图片描述

思路一：接口本身处理比较耗时，加上上游并发请求比较大，所以才会一直报警
思路一解决方案：确实也是如此，如果你的服务处理非常快且不是特别消耗资源那么确实不会在目前的并发下出现密集的504问题。
那么先优化目前的接口。接口是提供图像ocr功能，会加载深度学习模型的模型文件，代码中每一次请求都会重新实例化一个对象，这样做就会存在两个问题：
1，每次请求都去load 一次模型文件，这部分IO操作其实还是比较耗时的，而且是没有必要；
2 每个请求都实例化一个对象，那么在高并发下，系统的内存会很吃紧。
所以针对这个问题，定义了一个全局的对象，让该进程的所有请求都用同一个对象去处理。
思路一存在问题：该方案确实减少了每次请求的耗时，同时也减少了内存的占用。更新服务后并没有解决，而且ocr请求耗时取决于你传入图片的大小，如果图像太大，元素太多，耗时问题同样无解

思路二： 504问题的就是超时问题，是不是我的nginx超时时间的问题。
思路二解决方案：确实也是如此，nginx初始超时时间是在一些较小图像下得到的一个值，但是现在上游调用传入的图像比较大，那么在并发比较大的情况下，肯定都超过了这个时间，所以才会一直返回504

ok，将超时时间设置大一点

504问题：修改了nginx超时时间，所以大部分请求能够正常返回了
cpu超负荷问题：
虽然服务本身比较吃CPU，但是在目前的请求并发下不应该完全打满。因为在nginx超时时间是1s时候，上游调用504后都会重新请求多次。这里需要注意下⚠️：虽然调用client和nginx的链接断开了，但是服务实例还是在继续处理该次请求，直到请求处理完成，这样直接导致了流量被扩充了N倍！！！(不断重试)
最终解决方案
1、接口本身优化，尽量提升处理速度，尽量减少系统占用资源
2、 nginx + 服务本身超时设置，如果断开的链接，就没有必要继续去执行，浪费系统资源
3、预估服务的能力，设定访问限制(每秒请求多少)，将超过限制的流量挡住