Apache 2.4（httpd）内存泄漏求助：内存持续增长无法回落

这是典型的内存泄漏表现，结合你使用的httpd-2.4.6-67.el7_4.6.x86_64和RHEL 7.4环境，咱们从根源分析、排查步骤到解决方案一步步来：

可能的泄漏根源 #

• 模块层面问题：2.4.6版本的Apache存在不少已知的内存泄漏bug，尤其是内置模块（比如mod_proxy、mod_ssl）或第三方模块（比如mod_php、mod_security）在高并发请求下，会持续累积未释放的内存。
• 进程/线程模式缺陷：如果用的是prefork模式，子进程处理大量请求后内存无法回收；worker/event模式下的线程也可能存在泄漏，导致整体内存持续上升。
• 系统内存管理延迟：虽然RHEL 7.4的glibc malloc机制有时会缓存已释放的内存，但这种情况通常在负载停止后会逐步回退到系统，你描述的完全不回落更倾向于真泄漏而非缓存。

分步排查操作 #

1. 定位泄漏主体
   • 用top或htop观察：是单个httpd进程的RES（常驻内存）持续增长，还是进程数量不断增加导致总内存上升？前者是单进程泄漏，后者可能是进程创建逻辑或配置问题。
   • 执行pmap -x <httpd-pid>查看指定进程的内存分布，重点看哪些内存段（比如堆内存）在持续扩大，能帮你缩小排查范围。
2. 利用Apache自带工具
   • 启用mod_status模块：在httpd.conf里设置ExtendedStatus On，然后访问http://your-server/server-status（需配置允许访问的IP），可以看到每个子进程的内存使用、请求处理数等细节，判断是否有进程内存异常增长。
   • 列出已加载模块：运行apachectl -M，逐一禁用非必要的第三方模块，重启httpd后重新跑性能测试，看内存是否还持续增长，以此排查模块是否是泄漏源。
3. 深入内存调试
   • 测试环境下用valgrind检测：执行valgrind --leak-check=full /usr/sbin/httpd -X（单进程模式），模拟请求后查看泄漏报告，能直接定位到泄漏的代码位置（注意：valgrind会大幅降低性能，仅在测试环境使用）。
   • 用strace跟踪内存操作：strace -e malloc,free -p <httpd-pid>，观察内存分配和释放的对应关系，看是否存在只分配不释放的情况。

可行的解决方案 #

• 优先升级Apache版本：httpd 2.4.6是2017年的老版本，后续的2.4.x分支修复了大量内存泄漏问题，建议升级到RHEL 7官方支持的最新稳定版本（比如httpd-2.4.6-97.el7_9.x86_64及以上），这是最直接有效的办法。
• 调整进程/线程配置：
  • 如果用prefork，设置MaxConnectionsPerChild 10000（让子进程处理1万次请求后重启，避免内存累积），同时调整MaxRequestWorkers到合理值，减少并发进程数。
  • 尝试切换到worker或event模式，这些模式的内存利用率更高，且后续版本对它们的泄漏修复更完善。
• 排查并更新第三方模块：如果使用了自定义模块或第三方插件，检查其版本是否有已知泄漏bug，升级到对应模块的稳定版本，甚至替换为更可靠的替代方案。
• 更新系统补丁：确保RHEL 7.4的系统补丁和glibc版本是最新的，修复系统层面的内存分配潜在问题。

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