Archery项目中SQL检测接口504超时问题的排查与解决

问题背景

在Archery数据库管理平台的使用过程中，用户反馈了一个关于SQL检测功能的异常现象：当上传7.6MB大小的PostgreSQL SQL文件并点击"SQL检测"按钮时，系统会在60秒后返回504 Gateway Timeout错误。该问题发生在Kubernetes环境中，请求链路经过Ingress Nginx Controller和Archery-Docker容器（使用nginx+gunicorn架构）。

环境配置分析

系统各层配置了以下超时参数：

1. Ingress Nginx Controller:

   • 连接超时: 600s
   • 读写超时: 600s

2. Archery容器内部:

   • Nginx配置: 300s超时
   • Gunicorn配置: 600s超时
   • Django系统配置: MAX_EXECUTION_TIME=300

3. 前端配置:

   • Ajax请求超时: 100s

尽管各层都配置了较长的超时时间，但问题仍然出现，表明可能存在配置不生效或更深层次的问题。

排查过程

初步分析

首先排除数据库检查本身的问题，因为：

1. PostgreSQL的SQL检查是Archery自身实现的，不依赖第三方工具如goinception
2. 后端日志显示完整的SQL检查过程耗时约89秒，说明后端处理能力正常

关键发现

通过深入调试发现：

1. 前端设置的100秒超时未生效，请求仍在60秒时中断
2. 后端处理完整完成，说明问题不在应用层
3. 检查Nginx日志未发现相关错误记录

配置验证

重点检查了Ingress Nginx Controller的配置，发现超时参数"600s"的写法存在问题。在Kubernetes Ingress的annotation中，超时值应该使用无单位的数字表示（如"600"），而不是带单位的"600s"。

解决方案

将Ingress Nginx Controller的超时参数修改为无单位数字：

nginx.ingress.kubernetes.io/proxy-connect-timeout: "600"
nginx.ingress.kubernetes.io/proxy-read-timeout: "600"
nginx.ingress.kubernetes.io/proxy-send-timeout: "600"

这一修改使得超时配置正确生效，解决了504 Gateway Timeout问题。

经验总结

1. Kubernetes Ingress的annotation配置有特定格式要求，需要仔细查阅官方文档
2. 在排查超时问题时，需要逐层验证各组件配置的实际生效情况
3. 对于大文件处理场景，适当增加各层超时时间是必要的
4. 完整的日志记录和调试信息对于问题定位至关重要

这个问题展示了在复杂系统中，一个简单的配置格式错误可能导致难以察觉的问题。开发者和运维人员应当重视配置细节，确保各组件参数的正确性和一致性。