Apache子进程内存占用过高（单进程达400MB）排查方法咨询

Hey, let's dig into why your httpd child processes are hogging 400MB+ of RES memory when you'd typically expect them to stay around 50MB. From your top output, I notice the VIRT column is huge (32.7g) but the actual physical memory (RES) is the 400MB we need to focus on. Here are actionable steps to diagnose the issue:

• First, audit enabled httpd modules
  Run httpd -M (or apachectl -M depending on your distro) to list all loaded modules. Unused modules can add bloat, but more likely, a problematic module (like PHP handlers, mod_wsgi, or custom modules) is causing leaks or excessive memory allocation. Disable any modules you don't rely on and test if memory usage drops.

• Inspect your dynamic application code
  If you're running PHP, Python, or other dynamic content with httpd, poorly optimized scripts are a common culprit. For PHP specifically:

  • Check php.ini for the memory_limit directive and scan error logs for memory exhaustion warnings.
  • Add memory_get_usage(true) at key points in your scripts to track memory growth during execution.
  • Enable PHP's slow log (slowlog directive) to catch long-running scripts that might be accumulating memory over time.
    For other languages, use their native memory profiling tools to spot leaks or inefficient allocations.

• Tweak httpd process lifecycle settings
  Look at the MaxRequestPerChild (or MaxConnectionsPerChild in newer versions) directive in your httpd config. If it's set to a very high value or 0 (unlimited), child processes can accumulate memory as they handle more requests. Try setting it to a reasonable number (like 1000) to force child processes to restart periodically and free up memory.

• Break down individual process memory usage
  Use pmap -x <PID> (replace <PID> with one of your httpd child PIDs from top) to get a detailed view of how the process is using memory. Look for large anonymous memory regions or unexpectedly big loaded libraries—this can point to a specific module or application component causing the bloat.
  You can also run strace -p <PID> to track system calls related to memory allocation (mmap, malloc) and spot unusual patterns of large allocations.

• Check httpd error logs for clues
  Dig into your httpd error log (usually at /var/log/httpd/error_log or /var/log/apache2/error.log) for warnings or errors related to memory, module failures, or script issues. Misconfigured modules or repeated script errors can often cause memory to leak or not release properly.

• Use advanced profiling tools for deep dives
  If basic steps don't uncover the issue, try more targeted tools:

  • Attach gdb to a running httpd child process (if compiled with debug symbols) and use commands like info malloc to inspect active memory allocations.
  • Tools like valgrind can trace memory leaks, though note that running httpd under valgrind will slow it down significantly—best done in a staging environment.

• Rule out system-level edge cases
  While less likely given consistent high usage across httpd children, check for memory fragmentation (use free -m to see if cached memory is high but available memory is low) or other processes competing for resources. But your top output suggests the issue is isolated to httpd and its associated applications.

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