1

We have a Windows 2008 64-bit server running IIS 7 and serving about 40 different websites. Over the last few days we've seen a few php-cgi.exe processes consistently utilizing high CPU usage. The server is running PHP version 5.6.0 along with Windows Cache Extension for PHP 5.6. Both were installed with the Web Platform Installer.

Is there anyway for me to determine which website is the culprit so we can troubleshoot further?

Shawn Berg
  • 11
  • 3

1 Answers1

0

If you can get to the server console while this is happening, you'll often be able to tell from Task Manager.

True story! But there's one tweak: turn on the view of the Command Line. This shows the arguments passed to the target process, from which you could typically infer the site/page/consumer.

  • Run Task Manager
  • Go to the tab where you can see process details (Processes from memory for 2008)
  • Right-click a column heading and choose Select Columns
  • Enable the Command Line column

Grabbing a process dump (or series of process dumps) from any errant high-CPU process(es) should also include the command line parameters passed to it (visible to the debugger).

If you need a snapshot of processes and related parameters in flight from the command line,

wmic process

looks like it gets it, as long as WMIC was in 2008.

TristanK
  • 9,073
  • 2
  • 28
  • 39
  • Enabling the Command Line column in Task Manager only shows the path to php-cgi.exe. There aren't any parameters shown for any of the php-cgi.exe processes that are running. I ran "wmic process" but I don't see where that shows anything useful about which website or script may be running either – Shawn Berg May 02 '15 at 14:57
  • In that case, I think you'll need to (optionally dump and) debug a process to look at its PEB (specifically, its environment variables). – TristanK May 03 '15 at 01:34
  • How do I go about doing that? – Shawn Berg May 04 '15 at 13:15
  • Use ProcDump or Task Manager to create a dump of the process when it's in runaway mode. Then, use WinDBG to open the dump file. Then, !peb and/or ~*kb should show you WinDBG's rough idea of what's going on. – TristanK May 07 '15 at 02:35