We have seven websites written in PHP running on a Windows 2008 server with IIS 7.5. They are all very slow right now.

When I look in Task Manager, I see around 10 php-cgi.exe processes, and they are all taking 0% of the CPU, except one, which is taking 25%. It's a quad-core server, so it's taking 100% of one core.

If I watch for a few seconds, the process taking 25% will go to 0%, and a different php-cgi.exe process will jump to 25%. So all the php-cgi.exe processes are just lined up, waiting on a single core, and each process uses 100% of the processor when it can.

Each of the 7 sites is in its own application pool in IIS, and we're using FastCGI. The PHP version is 5.3.

Any ideas? Thanks!

EDIT: Here are our FastCGI settings:

        <application fullPath="C:\Program Files (x86)\PHP\v5.3\php-cgi.exe" monitorChangesTo="C:\Program Files (x86)\PHP\v5.3\php.ini" activityTimeout="600" requestTimeout="600" instanceMaxRequests="10000">
                <environmentVariable name="PHP_FCGI_MAX_REQUESTS" value="10000" />
                <environmentVariable name="PHPRC" value="C:\Program Files (x86)\PHP\v5.3" />

EDIT #2: We partly figured it out. PHP was never garbage collecting sessions due to a permissions problem, so there were millions of session files.

But I'd still like to know why it only ever uses one core. The sites are much faster now, but we have not resolved that. Does anyone know?

  • Can you post your FastCGI settings for your php-cgi.exe? – Kev Mar 24 '12 at 17:54
  • Sure, where can I find those settings? I didn't set up FastCGI, so I'm not too familiar with it. – Derek Kurth Mar 24 '12 at 18:33
  • Open up: "C:\Windows\System32\inetsrv\config\applicationHost.config" and copy/paste /configuration/system.webServer/fastCgi. – Kev Mar 24 '12 at 18:37
  • @Kev Thanks, I updated the question to include those settings. – Derek Kurth Mar 24 '12 at 18:42
  • Silly question perhaps, but are you running the the Non-Threadsafe build? – Kev Mar 25 '12 at 14:21

The issue ended up being that permissions were wrong in the folder where PHP keeps session files (sess_). Either garbage collection has never worked since we deployed this server or it did for a while but we changed the identity of the App Pool or something so that the new identity didn't have access to delete files. Anyway, we had over 2 million of the sess_ files in that temp folder. It took a few hours but eventually a "del /F /Q sess_" command completed, we restarted the site, and all it great again (from an average page load time of 60 seconds, to much less than 1 second). I don't know if this fixed the "all combined cgi-php.exe processes never use more than one core combined" issue or not but it would make sense to me that the mechanism within the Windows implementation of PHP that creates those sess_ files might be designed in such a way to have caused that phenomena as well (if it's single-apartment threaded, for example).

Anyway, the moral of the story is if you are seeing a very slow and steady increase in CPU consumption (that perhaps levels out at 100% of a single core) and http response time increases slowly as well, check the folder where you store your php session files (sess_*) and see if Windows Explorer crashes when you open that folder! :)

(By the way, it's W2k8 (not R2) so I think it's IIS 7 not 7.5)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.