高校高并发场景下Wagtail CMS返回504错误的排查思路问询

504错误本质是Nginx等待上游（应用服务器）响应超时，结合你提到的服务器资源利用率低的特征，可按以下方向逐层排查：

1. Nginx代理层排查 #

• 检查核心超时配置：确认proxy_connect_timeout、proxy_send_timeout、proxy_read_timeout的取值，默认60s在峰值场景下很容易触发超时，可结合业务接口的最长合理响应时间调整
• 检查高并发适配配置：确认worker_processes设置为auto（或匹配16核的数值），worker_connections是否大于默认的1024，峰值场景建议调整到10240以上，同时开启use epoll配置提升并发处理能力
• 检查连接队列溢出情况：执行ss -lnt查看Nginx监听端口的Send-Q数值，如果持续大于0说明内核连接队列已打满，需要调整net.core.somaxconn内核参数，同时在Nginx的listen指令后增加backlog=10240配置
• 检查upstream规则：确认是否配置了不必要的重试规则，错误的重试逻辑会放大峰值请求压力，加剧排队问题

2. 应用服务器层排查 #

• 检查WSGI服务的进程/线程配置：如果使用Gunicorn/UWSGI等WSGI服务，32核机器建议worker进程数设置为2*CPU核数+1，每个worker的线程数根据业务IO密集度调整到10-50区间，worker数量不足时，哪怕CPU空闲，新请求也会排队导致超时
• 排查慢接口：统计峰值时段的应用访问日志，筛选出响应时间超过1s的接口，少量慢接口占满所有worker线程后，会导致所有后续请求排队
• 检查Wagtail缓存配置：确认是否开启了页面缓存、片段缓存，活动类集中访问的页面如果每次都动态渲染，即使CPU没跑满，IO等待也会拉长响应时间
• 检查TCP参数优化：确认net.ipv4.tcp_tw_reuse、net.ipv4.tcp_fin_timeout参数是否调整，避免TIME_WAIT连接过多占用端口，导致Nginx无法和应用服务器建立新连接

3. 数据库层排查 #

• 检查慢查询日志：统计峰值时段的慢查询，哪怕数据库CPU利用率低，锁等待、大表全表扫描都会导致查询耗时过长，拖慢应用响应
• 检查连接数配置：确认数据库max_connections参数，以及应用端数据库连接池的大小是否匹配，连接数占满后新的数据库请求会排队等待，同样会导致应用响应超时
• 检查磁盘IO压力：执行iostat查看峰值时段的磁盘%util，如果持续大于80%说明磁盘IO成为瓶颈，内存占用低不代表IO无压力

4. 应急&长期优化建议 #

• 峰值前提前预热活动相关页面的缓存，静态资源全部放到Nginx层做缓存，减少请求打到应用层的比例
• 峰值时段可临时开启Nginx限流配置，对访问频率过高的IP做限流，避免恶意刷请求拖垮服务
• 长期可引入Redis作为应用层缓存，存储高频访问的页面内容，进一步降低应用和数据库的压力

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