☰

El evento Apache 2.4 MPM + php-fpm + php-opcache produce errores de "Restablecimiento de conexión por parte del par"

tag-icon • tag-icon apache-2.4 php-fpm centos7 zend-optimizer opcode
El evento Apache 2.4 MPM + php-fpm + php-opcache produce errores de "Restablecimiento de conexión por parte del par"

Tengo un servidor CentOS 7 que ejecuta Apache 2.4.6 con Event MPM y php-fpm versión 5.6.10 (del repositorio REMI). Aquí está la configuración de Apache relevante para enviar solicitudes a php-fpm dentro del vhost (es el único sitio en este servidor):

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

Aquí está la configuración del grupo php-fpm relevante:

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

Aquí está la configuración de php-opcache (la configuración de instalación predeterminada):

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

Mi problema:Cada vez que instalo y habilito php-opcache, los siguientes errores comienzan a aparecer en mi registro de errores:

[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

Si elimino php-opcache, los errores cesan. Los usuarios informan un error 502 Servicio no disponible en la interfaz cada vez que esto ocurre.

Literalmente pasé al menos 6 horas intentando buscar en Google y encontrar soluciones. Alguien dijo que fastshutdownla opción de opcache era un problema, pero está deshabilitada en la configuración predeterminada. Cambié el método de gestión de procesos php-fpm a estático sin reciclaje (max_requests=0), pero eso tampoco cambió nada. También intenté usar el método de proxy TCP con Apache (en lugar de sockets), y eso tampoco tuvo ningún efecto.

No estoy seguro de si esto es relevante o no, pero independientemente de si php-opcache está instalado o no, recibo los siguientes errores en el registro de errores (pero con una frecuencia mucho menor, <0,5 % de todo el tráfico, lo que puede ser un tema aparte):

[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: ...

Este problema es muy similar alÉste, aunque esa persona está usando ProxyPassMatch con el método TCP, lo cual yo no (porque omite .htaccess).

¿Alguien tiene alguna idea que no haya mencionado ya?

Respuesta1

Cuando he visto problemas similares en nuestros entornos, parece deberse a la forma en que OpCache (de forma predeterminada) comparte un único caché entre todos los usuarios en un entorno de alojamiento compartido. Aerror ha sido enviado(y puede, y debe, ir y votar para que los encargados de mantenimiento sepan lo importante que esto podría ser para su caso de uso), aunque no se ha asumido ningún compromiso sobre la entrega de una solución.

TL;DR: De forma predeterminada, cuando OpCache está habilitado, el caché que se utiliza para almacenar el código de bytes compilado se comparte entre todos los usuarios. En un entorno donde el alojamiento se comparte entre varios sitios/usuarios,Esto puede dar como resultado que un sitio obtenga la salida en caché de los scripts php de otro sitio o, si se habilitan configuraciones de seguridad específicas, incluso genere errores..

Si planea usar PHP-FPM con el opcache integrado de PHP 5.5+, lea la publicación del blog a continuación antes de hacerlo. Resulta que cualquier usuario del servidor puede leer el caché del código de operación. Esto significa que si hay, digamos, 10 usuarios separados, con sus propios vhosts y directorios, y usted configura un grupo PHP-FPM por usuario, cada usuario aún puede ver qué scripts están almacenados en caché y sus ubicaciones. Como tienen acceso de lectura al caché, podrían ver todos estos datos.

Obviamente, esto es un gran problema de seguridad, e incluso si nadie lo aprovecha, todavía existe la posibilidad de que el usuario equivocado lea los scripts al generar una página, por lo que los sitios web podrían mostrar datos/información incorrectos si hay varios índices. Scripts .php en el caché.

Aunque no se ha publicado oficialmente ninguna solución, si estás usando cPanel,Este wiki tiene una forma documentada de configurar los grupos de php-fpm que se crearán y protegerán por usuario.y si sigue las instrucciones a continuación, así como lasNOTAS IMPORTANTESal final de esta respuesta debería poder obtener la funcionalidad que desea sin ningún error

Esa publicación también documenta cómo puede configurar esto manualmente por sitio/por usuario (aunque apuesto a que eso podría resultar tedioso si aloja muchos sitios). Si no está utilizando cPanel, es posible que deba modificar los scripts para especificar sus rutas y nombres de usuario individuales en lugar de las variables que utiliza el motor de configuración de cPanel.

NOTAS IMPORTANTES

Durante las pruebas y la investigación adicional me encontréeste artículo que proporciona algunas aclaracionesque pueden ser relevantes para su situación específica:

  1. Debe asegurarse de que el opcache.use_cwdparámetro esté configurado en truepara la configuración de OpCache de su aplicación; está configurado falsede manera predeterminada y dejarlo configurado de manera predeterminada probablemente causará colisiones si aloja más de una aplicación PHP en su sistema:

En primer lugar, probablemente en cada proyecto típico deberá asegurarse de que la opción opcache.use_cwd esté configurada en verdadero. Habilitar esta configuración significa que el motor OpCache buscará las rutas completas de los archivos para distinguir entre archivos con los mismos nombres. Establecerlo en falso provocará colisiones entre archivos con el mismo nombre base.

  1. Si está ejecutando una aplicación impulsada por Zend Framework u otro marco similar que utilice anotaciones, TAMBIÉN debe asegurarse de que las directivas opcache.load_commentsy opcache.save_commentsestén configuradas en true. Debe verificar esta sugerencia con la documentación de su aplicación/marco, ya que la mayoría ha actualizado sus documentos con instrucciones específicas sobre cómo habilitar el uso de OpCache correctamente para sus sistemas:

También hay una configuración que es importante en las herramientas y marcos que utilizan anotaciones. Si usa Doctrine, Zend Framework 2 o PHP Unit, recuerde configurar las configuraciones opcache.load_comments y opcache.save_comments en verdadero. Como resultado, los comentarios de la documentación de sus archivos también se incluirán en el código precompilado generado por OpCache. Esta configuración le permitirá trabajar con anotaciones sin interrupciones.

Si su proyecto se basa en un marco específico o una aplicación web, siempre es una buena idea consultar la documentación para obtener pautas sobre la configuración de OpCache.

NOTAS IMPORTANTES

Esperamos que esto te haya ayudado, y si estás usando cPanel, deja un comentario para contarnos cómo abordaste esa parte de la configuración. Vea también esta pregunta y los comentarios asociados..

información relacionada