请教各位佬们一个奇怪的后端相关的技术问题

你的程序本身是不是有问题，运行时间一长造成资源泄露，甚至日志一直打把卷的空间都堆到头了，自然就无法处理请求了。
云环境本身的网络问题可能性不太大。

@SGL 但是运行时间一般半天左右就会出现问题 而且也没有多大访问量 基本也就是各位数的点击

python 服务没有设置网关吧？是 fast 这种异步后端还是啥同步后端？同步的可能会因为频繁请求丢失响应乃至彻底死掉，比如查询会触发 sqlite 查询，这玩意频繁触发有超时，超过头了就怎么查询都没有响应了，你可能需要设置一个 nginx 之类的网关

很像 MySQL 2006 问题。
默认 MySQL 的 wait_time=28800 ，就是 8 小时。如果没有处理好连接问题，会有服务静置 8 小时之后就出错的现象。你给的信息太少了，没什么好的建议，还是看看日志吧。

没遇到这种问题，需要记录日志进行排查，容器是否挂了，访问 http 请求，数据库的处理有没有问题，提供一个简单的不涉及任何交互的接口访问看看

思路：先看是 tcp 建连慢还是 rtt 慢还是传输慢，
建连慢排查网络全链路，rtt 慢看应用内部处理或者前端 nginx 转发等，传输看带宽等。
如果是应用层面问题，又是云平台，可以直接集成公有云 arms 探针，比自己打印日志一点点分析方便

信息量太少了，技术栈 python 等于没说，起码也得说下框架和数据库，内存和 CPU 占用情况。
我瞎猜个数据库/文件连接没关闭。

可能是资源泄露、句柄没关闭之类的原因，建议在收到请求、发送回复的地方增加一些日志打印

或者尝试一下
如果增加访问量，从开始运行到无响应，时间间隔是否缩短
如果完全没有访问量，一段时间后尝试访问，是否出现未响应的问题
如果不用容器，直接运行，是否也会在一段时间后没响应

未响应可能是没收到请求、收到请求后没处理、处理请求后没回复、发送回复失败，在各种关键点增加日志吧

没多大访问量就把日志打开跑两天吧，好歹搞清楚是哪里慢才能分析，定位问题总不能黑盒盲猜吧。

写个脚本 10s 一次轮询请求，刷一段时间看看能不能复现，如果不能复现可以往某些三方服务或者数据库链接实例超时销毁的方向排查，如果还是会无响应可能是代码本身问题

试试 ENV PYTHOnUNBUFFERED=1

wc 大佬你这个思路有点道理 我偶尔就会出现类似的日志报错问题 我去排查一下

@Vegetable wc 大佬你这个思路有点道理 我偶尔就会出现类似的日志报错问题 我去排查一下

@jackOff 确实没有设置网关 用的是 fastapi 但是频繁请求确实算不上 毕竟访问量不大 频繁出发 sqlite 查询这个这么能判断是不是这个问题

@EndlessSummer 异步请求 sqlite 的话要设置 sqlite 异步查询，但是即使是开启异步查询，查询量太多 sqlite 最终还是会宕机，你可以整一个定时器任务用于定时器执行一个简单的数据库数据查询，看看响应，如果没有响应就是 sqlite 已经宕机了，只能重启了

如果有频繁查询的数据，最好还是加一层缓存来分担数据库查询的压力，缓存查不到再去查数据库和更新缓存，简单暴力的方式就是整个 redis ，然后定时把 redis 数据写入 sqlite,sqlite 就基本完全隔离外部直接查询了