Apache: processos fcgi php órfãos

3

Nós temos um servidor web com o apache 2.2.14, PHP 5.3.2.

O PHP é executado usando o mod_fcgid (veja abaixo). Tudo funciona bem, mas às vezes, e nós ainda tem que descobrir o que desencadeia isso, quando os processos de php são "rodados" permanecem ativo e órfão: o apache gera novos processos php e os antigos permanecem no sistema. Matá-los nem sempre os expulsa. Mais provavelmente, um "apache2ctl gracioso" libera sistema a partir desses processos obsoletos. Encontramos isso no log de erros:     [Ter Jun 18 20:49:54 2013] [avisar] mod_fcgid: processo 2009 gracioso matar falhar, enviando SIGKILL pelo que eu encontrei pesquisando isso é normal, mas isso é tudo que eu encontrei no apache registros durante um desses processos vazam.

Este evento, felizmente, raramente está acontecendo, geralmente apache e php operam normalmente e com sem problemas durante a renovação do fcgid childrens. Como podemos entender o que está errado nessas situações?

mod_fcgid config no site:

<IfModule mod_fcgid.c>
SuexecUserGroup domain domain
<Directory /var/www/fomain.it/htdocs/>
AddHandler fcgid-script .php
FCGIWrapper /var/www/fcgi/domain.it/fcgi-starter-php .php
Options +ExecCGI -Indexes
AllowOverride FileInfo Options
Order allow,deny
Allow from all
</Directory>
<Directory /var/www/fcgi/domain.it/>
AllowOverride None
Options +ExecCGI MultiViews -Indexes
Order allow,deny
Allow from all
</Directory>
</IfModule>

/var/www/fcgi/domain.it/fcgi-starter-php:

#!/bin/sh

PHPRC=/var/www/fcgi/domain.it/php/

export PHPRC
PHP_FCGI_CHILDREN=8
export PHP_FCGI_CHILDREN
PHP_FCGI_MAX_REQUESTS=5000
export PHP_FCGI_MAX_REQUESTS

exec /usr/lib/cgi-bin/php $1

Atualmente encontramos uma solução alternativa para evitar que o servidor seja preenchido com processos órfãos. Você pode se livrar dos processos obsoletos com:

apache2ctl graceful

e elimine esses processos com:

pkill -f -x /usr/lib/cgi-bin/php -P 1

script e agendamento desses dois comandos (com verificações adequadas) evitará que o servidor hospede muitos procedimentos inúteis, mas o problema ainda está presente.

    
por Maxxer 26.11.2013 / 16:57

3 respostas

0

Eu tive um problema semelhante que o fcgid ficou sem os slots de processo disponíveis após algum período de atividade.

A mensagem de log foi aproximadamente:

[fcgid:warn] mod_fcgid: can't apply process slot for /var/www/cgi-bin/xxx/php-cgi, referer: ...

Eu acompanhei o problema até aqui:

[fcgid:emerg] (35)Resource deadlock avoided: [client ....] mod_fcgid: can't get pipe mutex, referer: ...

que é causada pelo bloqueio incorreto. No meu caso, o Apache usou o bloqueio fcntl () por padrão no debian, então eu mudei para flock () em apache2.conf :

Mutex flock:${APACHE_LOCK_DIR} default

Referência que me levou à solução: link

Documentação sobre várias opções de bloqueio (o fcgid tem um aviso contra o uso de algo que envolva threads): link

    
por 11.03.2016 / 11:37
0

Não tenho uma resposta real, mas talvez mais informações possam ajudar a resolver o problema. Eu gosto de dizer, eu tenho o mesmo problema em um servidor windows com PHP 5.3.5.

Alguns processos cgi permanecem como uma espécie de tarefa zumbi, após a execução real. Eles até ignoram configurações como max_execution time.

Atualmente, tenho um script agendado que elimina esses processos antigos. O problema com esta solução é que, mesmo nos processos cgi "normais" onde foram mortos, talvez seja útil detectar o tempo de execução dos processos e matá-los apenas se eles tiverem expirado seu tempo max_execution.

    
por 01.04.2014 / 08:49
0

Mudar para "sem" como Thomas sugeriu no link funcionou para mim.

Por isso, recomendo que qualquer pessoa edite o apache2.conf, comente a linha Mutex e coloque:

# Mutex file:${APACHE_LOCK_DIR} default   # Original debian config
Mutex sem  # Solves orphaned PHP processes.
    
por 02.09.2016 / 09:05