Heroku Dynos隔日出H12请求超时故障求助

• 检查dyno连接池泄漏：Heroku的2X dyno有隐性连接数上限，即便你配置了8个worker，若长期运行后数据库、外部API的连接未正确释放，会导致新请求无法获取连接触发超时。可以通过heroku ps:exec进入dyno，用netstat -an或ss -tulpn查看连接状态，确认是否存在大量TIME_WAIT或未释放的ESTABLISHED连接。
• 排查dyno内存泄漏：2X dyno内存配额为1GB，若应用存在内存泄漏，会随运行时间缓慢耗尽内存，触发Heroku的资源节流或OOM kill，导致请求超时。通过heroku metrics查看内存使用趋势，确认故障前是否有持续上升的情况；也可在代码中接入memory_profiler，定位内存泄漏的模块。
• 核查Heroku平台组件状态：故障时段可查看Heroku状态页面，确认对应区域是否有路由层、dyno管理器的临时故障。同时用heroku logs --tail --ps web查看故障时的日志，是否存在平台级别的错误提示（比如dyno调度异常）。
• 验证worker进程稳定性：gunicorn等worker进程可能因处理特定请求出现死锁或假死，导致可用worker耗尽。可在gunicorn配置中添加--timeout 30参数，强制杀死超时的worker；同时开启访问日志，记录每个请求的处理时长，排查是否有特定请求导致进程挂起。另外，故障时用heroku ps查看worker进程状态，确认是否有进程未响应。
• 检查流量分发与路由异常：Heroku路由层偶尔会出现流量倾斜，某个dyno被分配过多请求导致过载。用heroku router:info查看流量分发情况，确认是否存在不均衡；尝试切换dyno运行区域，看是否能缓解周期性问题。
• 排查定时任务资源占用：若应用有定时任务（如Celery beat、Django Q），需确认任务执行时间是否与故障时间点匹配。某些周期性任务可能在执行时耗尽CPU或内存，导致Web请求无法处理。可调整任务执行时间，或限制任务的资源占用。

内容的提问来源于stack exchange，提问作者Human Cyborg Relations