Apache服务器频繁重启及double free报错排查求助

这个问题我之前帮朋友排查过类似的，磁盘耗尽后的残留问题+内存管理错误的组合确实挺棘手，咱们一步步来定位解决：

1. 先抓全错误日志，精准定位崩溃点 #

首先得拿到崩溃时的详细上下文，光看"double free"报错不够：

• 实时监控Apache错误日志，默认路径是/var/log/httpd/error_log（CentOS/RHEL）或者/var/log/apache2/error.log（Debian/Ubuntu）：

  tail -f /var/log/httpd/error_log
  

  或者用grep提取崩溃前后的10行内容：

  grep -A 10 -B 10 "double free" /var/log/httpd/error_log
  

• 如果日志里没有调用栈信息，必须开启**核心转储（core dump）**才能找到根源：
  1. 临时设置系统允许生成core文件：

     ulimit -c unlimited
     

     要永久生效的话，编辑/etc/security/limits.conf，添加：

     * soft core unlimited
     

  2. 修改httpd.conf，指定core文件存储目录（确保目录可写）：

     CoreDumpDirectory /tmp
     

  3. 重启Apache：

     systemctl restart httpd
     

  等服务器再次崩溃后，用gdb分析core文件：

  gdb httpd /tmp/core.*
  

  输入bt命令查看调用栈，这能直接告诉你是Apache本身的模块，还是你的Python文件服务包出了问题。

2. 排查Python文件服务模块的内存问题 #

既然技术栈是Apache+Python文件服务包，大概率是这个模块的内存管理出了问题：

• 脱离Apache单独测试：写个简单的脚本，循环调用模块的文件服务接口，模拟高负载，监控内存变化：

  # 运行脚本后，另开终端监控内存
  ps aux --sort=-%mem | grep your_python_script.py
  

  如果内存持续增长不回落，那肯定是模块有内存泄漏。
• 用Python工具分析内存细节：用tracemalloc或者objgraph跟踪内存分配，找到泄漏点：
  示例代码：

  import tracemalloc
  tracemalloc.start()
  
  # 导入你的文件服务模块
  from your_file_service_pkg import serve_file
  
  # 模拟多次请求
  for i in range(1000):
      serve_file("/path/to/large/test_file")
      # 每100次请求打一次内存快照
      if i % 100 == 0:
          snapshot = tracemalloc.take_snapshot()
          top_stats = snapshot.statistics('lineno')
          print(f"=== Iteration {i} ===")
          for stat in top_stats[:10]:
              print(stat)
  

  重点看哪些代码行的内存占用持续增长，检查是否有未关闭的文件句柄、未释放的大型缓冲区，或者循环引用导致垃圾回收失效。

3. 调整Apache配置，临时缓解+辅助排查 #

在找到根源前，先调整Apache的进程管理配置，减少崩溃频率，同时帮我们验证问题：

• 修改MaxConnectionsPerChild：把这个值设小（比如1000），让子进程处理一定数量的请求后自动重启，避免内存泄漏累积到崩溃：

  MaxConnectionsPerChild 1000
  

• 开启mod_status监控子进程内存：
  在httpd.conf里添加：

  <Location /server-status>
      SetHandler server-status
      Require ip 127.0.0.1
  </Location>
  

  重启后访问http://localhost/server-status，看每个子进程的Size列，如果某个子进程的内存持续增长直到崩溃，就坐实了内存泄漏的问题。

4. 针对性修复问题 #

根据前面的排查结果，对应处理：

• 如果是Apache模块问题：比如用的是mod_wsgi，检查版本是否过时，升级到最新稳定版，或者换用uwsgi+mod_proxy的组合替代，看是否解决。
• 如果是Python模块问题：修复代码里的资源泄漏，比如用with语句管理文件句柄（with open(file_path) as f:），避免手动打开后忘记关闭；如果是第三方pip包，检查是否有已修复的bug，升级到最新版，或者提交issue给开发者。
• 磁盘耗尽残留问题：清理Apache的临时文件目录，比如/tmp下的httpd相关文件：

  rm -rf /tmp/httpd*
  

  同时检查Apache的运行目录（比如/var/run/httpd）是否有损坏的pid文件，清理后重启服务。

5. 验证修复效果 #

修复后，做这两件事确认问题解决：

1. 持续监控错误日志，确保不再出现"double free"报错；
2. 用压力测试工具模拟高并发请求，比如ab：

   ab -n 1000 -c 10 http://your-server/your-file-endpoint
   

   看服务器是否稳定，内存是否不再持续增长。

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