Home / server / Questions / 373024
Accepted
Derek Kurth
Asked: 2012-03-25 09:03:50 +0800 CST

PHP processes run one at a time, always taking 100% of one core

  • 772

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:

    <fastCgi>
        <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">
            <environmentVariables>
                <environmentVariable name="PHP_FCGI_MAX_REQUESTS" value="10000" />
                <environmentVariable name="PHPRC" value="C:\Program Files (x86)\PHP\v5.3" />
            </environmentVariables>
        </application>
    </fastCgi>

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?

windows-server-2008 php iis-7.5 cpu-usage

1 Answers

  1. Best Answer

    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)

    • 5