Apache运行PHP插件时高CPU使用率的调试排查请求

Got it, let's break down how to track down this mysterious 100% CPU issue—since you already have mod_status with ExtendedStatus enabled, we can leverage that as our first line of defense.

Step 1: Pinpoint the Misbehaving Process with mod_status #

• First, access your Apache status page at http://your-server-ip/server-status (you might need to adjust your Apache config to allow access from your IP if it's restricted).
• Look for processes marked with a "W" state (Sending Reply) that linger long after the page has loaded, or any process with a consistently high CPU percentage. Note down its PID.
• Use top -p <PID> in your server's terminal to monitor that specific process in real-time. Confirm it's the one hogging CPU even after the page is fully loaded.

Step 2: Trace the Process to Find the Root Cause #

Since you're running PHP 5.6 with Apache, here are two powerful tools to dig deeper:

• strace: Attach it to the problematic PID to see what system calls the process is repeating:

  strace -p <PID>
  

  Look for repeated patterns (like endless read()/write() calls, or loops around a single system call) which can point to stuck logic or resource contention.
• gdb (for mod_php setups): If you're using mod_php instead of PHP-FPM, attach gdb to the Apache child process and grab the call stack:

  gdb -p <PID>
  bt
  

  This will show you the exact PHP functions and code lines the process is stuck on—super useful for tracking down infinite loops in your plugin.

Step 3: Audit Your PHP Plugin Code #

Once you have a hint of where the issue might be, focus on these common culprits:

• Infinite loops: Check for while/for loops where the exit condition never gets triggered (e.g., a variable that never increments, or a condition that always evaluates to true).
• Shutdown hooks/async tasks: Does your plugin use register_shutdown_function() or any background processing that runs after the page loads? These can sometimes get stuck without you noticing.
• Hook callback loops: If your plugin uses event/hook systems (like WordPress-style actions/filters), make sure a callback isn't triggering itself recursively without a termination condition.
• Enable verbose PHP logging: Update your php.ini with these settings to catch hidden errors/warnings that might be looping:

  error_reporting = E_ALL
  log_errors = On
  error_log = /var/log/php_errors.log
  

  Check the log for repeated error messages—they often point to code that's failing over and over in a loop.

Step 4: Rule Out Environment-Level Issues #

• Apache MPM Configuration: Double-check your mpm_prefork.conf (or equivalent) settings. If MaxRequestWorkers is too low, processes might get overloaded, but this is less likely if only one page load causes the spike.
• Disk/Network IO: Use iostat or netstat to confirm the CPU spike isn't tied to waiting on slow disk reads or stuck network connections (though these usually cause low CPU usage, not 100%).

Start with the mod_status step—it's the fastest way to narrow down which process is causing the problem, then work your way down to the code level. You'll likely find that it's a hidden infinite loop or stuck background task in your plugin.

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