Os processos PHP são executados um de cada vez, sempre levando 100% de um núcleo

Question

Temos sete sites escritos em PHP em execução em um servidor Windows 2008 com o IIS 7.5. Eles estão todos muito lentos agora.

Quando olho no Gerenciador de Tarefas, vejo cerca de 10 processos do php-cgi.exe, e todos eles estão tirando 0% da CPU, exceto um, que está recebendo 25%. É um servidor quad-core, por isso está levando 100% de um núcleo.

Se eu observar por alguns segundos, o processo que leva 25% irá para 0%, e um processo diferente do php-cgi.exe irá saltar para 25%. Assim, todos os processos do php-cgi.exe estão apenas alinhados, esperando em um único núcleo, e cada processo usa 100% do processador quando pode.

Cada um dos 7 sites está em seu próprio pool de aplicativos no IIS e estamos usando o FastCGI. A versão do PHP é 5.3.

Alguma ideia? Obrigado!

EDIT: Aqui estão as nossas configurações do FastCGI:

    <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: Nós parcialmente entendemos isso. O PHP nunca foi coletor de lixo devido a um problema de permissões, então havia milhões de arquivos de sessão.

Mas eu ainda gostaria de saber por que só usa um núcleo. Os sites estão muito mais rápidos agora, mas não resolvemos isso. Alguém sabe?

    

Answer 1

O problema foi que as permissões estavam erradas na pasta em que o PHP mantém os arquivos da sessão (sess_ ). A coleta de lixo nunca funcionou desde que implementamos esse servidor ou funcionou por algum tempo, mas alteramos a identidade do Pool de Aplicativos ou algo assim para que a nova identidade não tivesse acesso para excluir arquivos. De qualquer forma, tínhamos mais de 2 milhões dos arquivos sess_ nessa pasta temporária. Demorou algumas horas, mas eventualmente um comando "del / F / Qsess_ " foi concluído, reiniciamos o site e tudo voltou a ser excelente (de um tempo médio de carregamento de página de 60 segundos a muito menos de 1 segundo ). Eu não sei se isso corrigiu o problema "todos os processos cgi-php.exe combinados nunca usam mais de um núcleo combinado" problema ou não, mas faria sentido para mim que o mecanismo dentro da implementação do PHP do Windows que cria os arquivos sess_ pode ser projetado de tal forma a ter causado esse fenômeno também (se for single-apartment threaded, por exemplo).

De qualquer forma, a moral da história é se você estiver vendo um aumento muito lento e constante no consumo de CPU (que talvez se estabilize em 100% de um único núcleo) e o tempo de resposta http também aumente lentamente, verifique a pasta onde você armazena seus arquivos de sessão do php (sess_ *) e vê se o Windows Explorer falha quando você abre a pasta! :)

(A propósito, é W2k8 (não R2), então acho que é o IIS 7 não 7.5)