FastAPI生产环境每1-2小时崩溃，本地正常，日志报Signal15

首先看日志里的signal:15，这是SIGTERM信号，属于主动终止信号，不是程序崩溃（崩溃一般是signal9/SIGKILL或其他错误信号），说明你的FastAPI worker进程是被外部发送终止指令导致退出的，结合每1-2小时出现的规律，从以下几个方向排查：

1. 部署进程管理器的自动重启策略 #

如果你的应用是用Gunicorn、Uvicorn（多worker模式）这类进程管理器部署的，大概率是配置了自动重启规则：

• 比如Gunicorn的--max-requests参数，设置worker处理一定数量请求后自动重启；
• 或者--timeout参数，如果请求处理超时（比如数据库查询卡住），管理器会发送SIGTERM终止worker并重启新进程。

排查动作：

• 查看应用启动命令，比如Gunicorn启动时的参数，是否包含--max-requests、--timeout、--graceful-timeout这类配置；
• 查看进程管理器的完整日志（比如Gunicorn的error log），里面通常会记录终止worker的具体原因（比如"Worker timed out"）。

2. 数据库连接池配置缺失 #

你的database.py里create_engine没有配置连接池参数，生产环境中MySQL默认有wait_timeout（部分服务器会设置较短时长），如果连接长时间不使用会被数据库端断开，而SQLAlchemy的连接池如果没配置pool_recycle，会持有失效的连接，导致后续请求卡住，触发进程管理器的超时终止。

修复方案：
给create_engine添加连接池相关参数，避免连接失效：

engine = create_engine(
    SQLALCHEMY_DATABASE_URL,
    pool_size=10,  # 保持的空闲连接数
    max_overflow=20,  # 允许临时创建的额外连接数
    pool_recycle=3600,  # 每3600秒（1小时）回收一次连接，避免被MySQL断开
    pool_pre_ping=True  # 获取连接前先ping数据库，确保连接有效
)

3. 服务器定时任务或监控工具的干预 #

检查服务器上是否有cron定时脚本、监控工具（比如运维自动化工具、监控告警脚本）会定期终止你的进程。可以通过crontab -l查看当前用户的定时任务，或者询问运维团队是否有相关自动化规则。

4. 资源占用异常（可能性较低） #

虽然signal15不是OOM（内存溢出会触发signal9），但如果进程存在内存泄漏，内存占用缓慢增长到触发某些监控阈值，运维工具可能会发送SIGTERM尝试优雅终止进程。可以用top、ps aux监控进程的内存变化，或者用memory_profiler工具排查代码中的内存泄漏点。

内容的提问来源于stack exchange，提问作者jabodom934