Apache环境下Flask应用日志重复及数据库连接堆积问题求助

我有一个基于Python Flask + SQLAlchemy/Flask-SQLAlchemy的应用，环境配置如下：

• 开发环境：Flask内置服务器 + 本地PostgreSQL 14
• 预发布（staging）环境：Apache+mod_wsgi部署 + PostgreSQL 12，Apache站点配置如下：

<VirtualHost 192.168.1.100:80>
        ServerName staging.mysite.com
        ServerAdmin admin@my-application.org
        DocumentRoot /var/www/mysite-staging

        WSGIDaemonProcess mysite-staging user=auser group=auser threads=2 display-name=mysite-staging python-path=/var/www/mysite-staging/ python-home=/usr/local/venvs/mysite

        WSGIScriptAlias / /var/www/mysite-staging/mysite.wsgi
        <Directory /var/www/mysite-staging>
                WSGIProcessGroup mysite-staging
                WSGIApplicationGroup %{GLOBAL}

                AllowOverride none
                Require all granted
        </Directory>
</VirtualHost>

遇到的问题：

• 本地开发环境启动日志仅输出一次，后续请求无重复；但Apache环境中每次请求都会重复输出启动类日志，且重复次数随请求递增4条
• 预发布环境PostgreSQL的idle连接持续堆积，直至达到连接上限报错
• 不确定日志重复与数据库连接问题是否关联，需要排查方向、测试方法或原因分析

一、日志重复与应用重复初始化的关联排查 #

日志重复递增大概率是每次请求都触发了应用的重复初始化（比如Flask app实例、SQLAlchemy db实例被重复创建），结合mod_wsgi的配置，重点检查：

• WSGI脚本文件（mysite.wsgi）的写法
  确保Flask app的创建、初始化代码（包括db初始化、日志配置）不在请求处理的代码块内，而是放在脚本的顶级作用域。错误示例：把create_app()放在application函数内部，导致每次请求都重新创建app和初始化组件。
  正确写法示例：

  # mysite.wsgi
  import sys
  sys.path.insert(0, '/var/www/mysite-staging')
  
  from myapp import create_app
  application = create_app()  # 顶级作用域初始化，仅执行一次
  

• mod_wsgi的进程/线程配置验证
  用ps aux | grep mysite-staging查看实际运行的进程数，确认是否和配置中threads=2的预期一致。同时检查Apache的MPM模式（比如prefork），如果MPM进程数设置过高，会导致多个WSGI daemon进程启动，每个进程都会初始化一次应用，叠加后日志重复次数增多。

二、数据库连接堆积的原因排查 #

idle连接堆积通常是连接未被正确回收，结合日志重复的现象，大概率和应用重复初始化导致连接池被重复创建有关：

• SQLAlchemy连接池配置检查
  确认Flask-SQLAlchemy的SQLALCHEMY_POOL_RECYCLE、SQLALCHEMY_POOL_SIZE、SQLALCHEMY_MAX_OVERFLOW参数是否合理。比如SQLALCHEMY_POOL_RECYCLE建议设置为小于PostgreSQL的idle_in_transaction_session_timeout（默认10分钟），避免连接被PostgreSQL回收后应用端还认为有效。如果应用被重复初始化，每个实例都会创建独立的连接池，导致连接数=N个应用实例 × (POOL_SIZE + MAX_OVERFLOW)，快速耗尽数据库连接上限。
• 连接是否在请求结束后正确释放
  检查是否在请求结束时调用了db.session.remove()（Flask-SQLAlchemy默认会在请求上下文结束时自动执行，但如果应用初始化异常，这个钩子可能失效）。可以手动在视图函数或after_request钩子中显式添加db.session.remove()测试，看是否能减少idle连接。
• 数据库端连接状态分析
  执行PostgreSQL查询查看连接详情：

  SELECT pid, usename, application_name, client_addr, state, query_start FROM pg_stat_activity WHERE state = 'idle';
  

  观察这些idle连接的application_name是否对应你的应用，以及连接的创建时间，判断是否是每次请求都新建连接且未回收。

三、日志重复与连接堆积的关联性验证 #

• 临时调整日志输出，标记进程/线程ID
  在启动日志中添加进程ID（os.getpid()）和线程ID（threading.get_ident()），比如：

  import os
  import threading
  app.logger.info(f"应用初始化 - 进程ID: {os.getpid()}, 线程ID: {threading.get_ident()}")
  

  观察日志中的进程ID是否每次请求都变化，或者多个进程的日志叠加，就能确认是否是多进程/重复初始化导致的日志重复，同时对应数据库连接的创建时间点进行关联分析。
• 单进程单线程测试
  修改mod_wsgi配置，设置processes=1 threads=1，重启Apache后测试：

  WSGIDaemonProcess mysite-staging user=auser group=auser processes=1 threads=1 ...
  

  如果日志不再重复递增，且连接不再堆积，说明问题根源是多进程下应用重复初始化导致的资源泄漏。

四、其他可能的排查点 #

• Apache的WSGIApplicationGroup配置
  你的配置中用了WSGIApplicationGroup %{GLOBAL}，这会让所有WSGI脚本运行在同一个Python解释器进程组，可能导致多个应用实例共享资源时出现异常。尝试注释掉这一行，重启Apache测试。
• 虚拟环境的正确性
  确认mod_wsgi配置中的python-home=/usr/local/venvs/mysite指向的虚拟环境是正确的，避免使用系统Python导致依赖冲突，引发初始化异常。
• 应用的初始化代码是否有副作用
  检查是否在create_app()或模块顶级作用域中有创建数据库连接的代码（比如提前执行了db.engine.connect()），这会导致每次初始化都新建连接，且未放入连接池管理。

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