☰

Apache 2.4 Event MPM + php-fpm + php-opcache gera erros de "Conexão redefinida por peer"

tag-icon • tag-icon apache-2.4 php-fpm centos7 zend-optimizer opcode
Apache 2.4 Event MPM + php-fpm + php-opcache gera erros de "Conexão redefinida por peer"

Eu tenho um servidor CentOS 7 rodando Apache 2.4.6 com Event MPM e php-fpm versão 5.6.10 (do repositório REMI). Aqui está a configuração relevante do Apache para enviar solicitações ao php-fpm dentro do vhost (é o único site neste servidor):

<FilesMatch \.php$>
    SetHandler "proxy:unix:/var/run/php-fpm/www.sock|fcgi://localhost"
</FilesMatch>

Aqui está a configuração relevante do pool php-fpm:

listen = /var/run/php-fpm/www.sock
listen.owner = apache
listen.group = apache
pm = static
pm.max_children = 50
pm.max_requests = 0

Aqui está a configuração do php-opcache (a configuração de instalação padrão):

zend_extension=opcache.so
opcache.enable=1
opcache.memory_consumption=128
opcache.max_accelerated_files=4000
opcache.blacklist_filename=/etc/php.d/opcache*.blacklist

Meu problema:Sempre que instalo e habilito o php-opcache, os seguintes erros começam a aparecer no meu log de erros:

[Thu Jun 18 08:10:58.499871 2015] [mpm_event:debug] [pid 16546:tid 139798115227392] event.c(986): (104)Connection reset by peer: [client 157.55.39.233:15962] AH00470: network write failure in core output filter
[Thu Jun 18 08:10:58.527424 2015] [mpm_event:debug] [pid 16546:tid 139797922195200] event.c(986): (103)Software caused connection abort: [client 157.55.39.233:15990] AH00470: network write failure in core output filter

Se eu remover o php-opcache, os erros cessarão. Os usuários estão relatando um erro 502 Serviço indisponível no frontend sempre que isso ocorre.

Passei literalmente pelo menos 6 horas tentando pesquisar no Google e encontrar soluções. Alguém disse que a fastshutdownopção do opcache era um problema, mas está desabilitada na configuração padrão. Mudei o método de gerenciamento de processos php-fpm para estático sem reciclagem (max_requests=0), mas isso também não mudou nada. Também tentei usar o método proxy TCP com Apache (em vez de soquetes), e isso também não teve efeito.

Não tenho certeza se isso é relevante ou não, mas independentemente de o php-opcache estar instalado ou não, recebo os seguintes erros relatados no log de erros (mas em uma frequência muito menor, <0,5% de todo o tráfego, o que pode ser uma questão separada):

[Thu Jun 18 08:32:37.223430 2015] [proxy_fcgi:error] [pid 19187:tid 140598765840128] [client 37.46.115.238:55624] AH01068: Got bogus version 10, referer: ...
[Thu Jun 18 08:32:37.223462 2015] [proxy_fcgi:error] [pid 19187:tid 140598765840128] (22)Invalid argument: [client 37.46.115.238:55624] AH01075: Error dispatching request to :, referer: ...

Esta questão é muito semelhante aEste, embora essa pessoa esteja usando ProxyPassMatch com método TCP, o que eu não estou (porque ignora .htaccess).

Alguém tem alguma idéia que eu ainda não mencionei?

Responder1

Quando vi problemas semelhantes em nossos ambientes, parece que foi por causa da maneira como o OpCache (por padrão) compartilha um único cache entre todos os usuários em um ambiente de hospedagem compartilhada. Abug foi enviado(e você pode, e deve, votar para que os mantenedores saibam o quão importante isso pode ser para o seu caso de uso), embora nenhum compromisso tenha sido assumido na entrega de uma correção.

DR: Por padrão, quando o OpCache está habilitado, o cache usado para armazenar o código de bytes compilado é compartilhado entre todos os usuários. Em um ambiente onde a hospedagem é compartilhada entre vários sites/usuários,isso pode resultar em um site capturando a saída em cache de scripts php de outro site ou, se configurações de segurança específicas estiverem habilitadas, até mesmo gerando erros.

Se você planeja usar PHP-FPM com o opcache integrado do PHP 5.5+, leia a postagem do blog abaixo antes de realmente fazer isso. Acontece que o cache do opcode pode ser lido por qualquer usuário no servidor. Isso significa que se houver, digamos, 10 usuários separados, com seus próprios vhosts e diretórios, e você configurar um pool PHP-FPM por usuário, cada usuário ainda poderá ver quais scripts estão armazenados em cache e suas localizações. Como eles têm acesso de leitura ao cache, eles poderiam visualizar todos esses dados.

Obviamente, isso é uma grande preocupação de segurança e, mesmo que ninguém explore isso, ainda há uma chance de os scripts serem lidos pelo usuário errado ao gerar uma página, portanto, os sites podem estar exibindo dados/informações errados se houver vários índices. Scripts .php no cache.

Embora nenhuma correção tenha sido lançada oficialmente se você estiver usando cPaneleste wiki tem uma maneira documentada de configurar os pools php-fpm a serem criados e protegidos por usuárioe se você seguir as instruções abaixo, bem como oANOTAÇÕES IMPORTANTESna parte inferior desta resposta, você poderá obter a funcionalidade desejada sem erros

Essa postagem também documenta como você pode configurar isso manualmente por site/por usuário (embora eu aposto que isso pode se tornar tedioso se você estiver hospedando muitos sites). Se você não estiver usando o cPanel, pode ser necessário modificar os scripts para especificar seus caminhos e nomes de usuário individuais, em vez das variáveis ​​usadas pelo mecanismo de configuração do cPanel.

ANOTAÇÕES IMPORTANTES

Durante testes e pesquisas adicionais, me depareieste artigo que fornece alguns esclarecimentosque pode ser relevante para sua situação específica:

  1. Você precisa ter certeza de que o opcache.use_cwdparâmetro está definido truepara a configuração do OpCache do seu aplicativo - ele está definido falsecomo padrão e deixá-lo definido como padrão provavelmente causará colisões se você estiver hospedando mais de um aplicativo PHP em seu sistema:

Primeiro de tudo, provavelmente em cada projeto típico você terá que garantir que a opção opcache.use_cwd esteja definida como verdadeira. Habilitar esta configuração significa que o mecanismo OpCache examinará os caminhos completos dos arquivos para distinguir entre arquivos com os mesmos nomes. Definir como falso causará colisões entre arquivos com o mesmo nome base.

  1. Se você estiver executando um aplicativo desenvolvido com Zend Framework ou outro framework semelhante que faça uso de anotações, TAMBÉM precisará garantir que as diretivas opcache.load_commentse estejam definidas como . Você deve verificar esta sugestão com a documentação do seu aplicativo/estrutura, pois a maioria já atualizou seus documentos com instruções específicas sobre como ativar o uso do OpCache corretamente em seus sistemas:opcache.save_commentstrue

Há também uma configuração que é importante em ferramentas e frameworks que fazem uso de anotações. Se você usa Doctrine, Zend Framework 2 ou PHP Unit, lembre-se de definir as configurações opcache.load_comments e opcache.save_comments como true. Como resultado, os comentários da documentação dos seus arquivos também serão incluídos no código pré-compilado gerado pelo OpCache. Esta configuração permitirá que você trabalhe com anotações sem interrupções.

Se o seu projeto é baseado em um framework específico ou em uma aplicação web, é sempre uma boa ideia verificar a documentação para obter orientações sobre a configuração do OpCache

ANOTAÇÕES IMPORTANTES

Esperamos que isso tenha ajudado - e se você estiver usando o cPanel, deixe um comentário para nos contar como você lidou com essa parte da configuração! Veja também esta pergunta e comentários associados.

informação relacionada