2012-10-12 14 views
14

Internet tiene muchas discusiones que llamar a apc_cache_clear() en CLI no borra los cachés de opcode de los procesos PHP "web", ya sea que se ejecuten dentro de Apache o por FPM (consulte How to clear APC cache entries?). Como solución sugerida, es posible crear una página PHP simple que llame al apc_cache_clear() y llamarla desde CLI. Symfony's ApcBundle hace eso.¿El caché de código de operación de APC está compartido entre grupos/trabajadores de PHP-FPM?

Si el apc_cache_clear() de CLI no vacía el caché de Apache/FPM, ¿lo hace entre los trabajadores de FPM? Si llamo /clear_apc_cache.php a través de HTTP, solo se ejecuta mediante uno de los procesos de trabajo de FPM. Entonces, ¿el caché de código de operación de APC es realmente compartido entre pools y trabajadores? Y más específico: ¿se borra automáticamente de todos los trabajadores?

+1

Por lo que yo entiendo FPM y APC, me creen que son compartidos. Básicamente tienes una instancia de PHP ejecutándose. Por lo tanto, solo una instancia de APC. – tubaguy50035

+0

Gracias @ tubaguy50035 por un comentario. Creo que necesito investigar un poco más para estar seguro ... –

Respuesta

22

Todos los trabajadores de php-fpm comparten el mismo caché de código de operación que el proceso padre php-fpm; source. Si tiene un archivo /apc_clear_cache.php y lo llama por HTTP (usando algo como curl), borrará el caché del opcode para todos los trabajadores que usen el mismo proceso maestro de php-fpm.

Este blog article tiene una muy buena explicación de cómo funciona la APC y cómo borrarla efectivamente durante la liberación.

+0

Gracias por responder la pregunta con buenas fuentes. Esto aclaró mi problema. =) –

+1

Como está escrito [arriba] (http://stackoverflow.com/a/12981832/1447317) debe borrar el caché APC en el contexto de la solicitud HTTP, sin embargo, borrará el caché para ** todos ** los grupos, que son bifurcado desde el mismo proceso maestro (esto es típico para la mayoría de las distribuciones). – boda2004

+2

Creo que los procesos secundarios se bifurcan desde el mismo proceso maestro, incluso si están en grupos diferentes, por lo que solo hay una memoria caché compartida. Una forma de evitar el problema es iniciar diferentes procesos maestros de php-fpm. –

3

Acabo de descubrir que las diferentes agrupaciones también comparten la misma memoria caché de APC, al menos en PHP 5.4 con FPM y en lo que respecta al contenido de la memoria caché de código de operación.

Esta es la forma en que me di cuenta:

He creado varios grupos de PHP-FPM, donde cada grupo se chrooted bajo /srv/www/domain.com/ directorio.

La ubicación principal de los scripts PHP es /srv/www/domain.com/docroot/.

Ahora, si creo un archivo /srv/www/domain_1.com/docroot/test.php y lo carga, muestra lo que debería mostrar.

Sin embargo, cuando creo el archivo /srv/www/domain_2.com/docroot/test.php, los contenidos aparecen también en domain_1.com.

Creo que esto sucede porque APC utiliza la ubicación del archivo como la clave para su caché, y en ambos casos, la clave es /docroot/test.php.

La eliminación de la memoria caché del código de operación puede estar restringida solo a un grupo único. No he probado esto sin embargo.

EDIT La eliminación de la memoria caché de código de operación no se restringe a un grupo de aplicaciones único, la memoria caché de APC completa se borra cuando se llama a apc_cache_clear().

También traté de usar apc.mmap_file_mask para especificar una máscara diferente para cada conjunto. Esto no cambió nada, las actualizaciones en los archivos de un grupo de aplicaciones se vieron en otros grupos.

Se ha observado este comportamiento con la configuración apc.stat = 0. Todos los cambios en los archivos se supervisan con lsyncd, forzando una recompilación de la entrada en el caché de APC.

  • Tero
+1

Kiitos Tero: por lo que he entendido la [respuesta anterior] (http://stackoverflow.com/a/12981832/769144), parece que el caché del código de operación es propiedad del proceso principal, por lo que este comportamiento es algo esperado ... excepto que definitivamente toda la ruta del archivo fuente debería ser la clave. Tengo que probar esto en mi propia configuración también. –

11

Puede borrar la caché de código de operación a través de la CLI sin tener que implementar los archivos a su sitio web si se ejecuta la secuencia de comandos a través de la interfaz FastCGI directamente.

He creado this gist que puede utilizar en sus servidores para borrar la memoria caché php5-fpm.

Si está utilizando sockets UNIX:

php clear-apc.php --sock /var/run/php5-fpm.sock

lo contrario:

php clear-apc.php --port=[port]

u omitir por defecto 127.0.0.1:9000

+0

Gracias! Esta es una idea muy útil en general y podría usarse fácilmente también para el calentamiento de caché y otras operaciones similares en el servidor de aplicaciones. –

+0

Gran idea: incluso puede incorporar esa habilidad :) –

+0

Gist ya no existe :-( – richsage

Cuestiones relacionadas