¿Qué está causando" No se puede asignar memoria para pool " en PHP?

Usar un TTL de 0 significa que APC vaciará toda la caché cuando se quede sin memoria. El error ya no aparece, pero hace que APC sea mucho menos eficiente. Es una decisión sin riesgo, sin problemas, "No quiero hacer mi trabajo". APC no está destinado a ser utilizado de esa manera. Debe elegir un TTL lo suficientemente alto para que las páginas más visitadas no caduquen. Lo mejor es darle suficiente memoria para que APC no necesite vaciar la caché.

Simplemente lea el manual para entender cómo se usa ttl : http://www.php.net/manual/en/apc.configuration.php#ini.apc.ttl

La solución es aumentar la memoria asignada a APC. Haga esto aumentando el apc.shm_size.

Si APC se compila para usar Memoria de Segmento compartida, estará limitado por su sistema operativo. Escriba este comando para ver el límite del sistema para cada segmento :

sysctl -a | grep -E "shmall|shmmax"

Para asignar más memoria tendrás que aumentar el número de segmentos con el parámetro apc.shm_segmentos.

Si el APC es usando la memoria mmap entonces no tiene límite. La cantidad de memoria sigue siendo definida por la misma opción apc.shm_size.

Si no hay suficiente memoria en el servidor, use la opción filtros para evitar que los archivos php a los que se accede con menos frecuencia se almacenen en caché.

Pero nunca use un TTL de 0.

Como dijo c33s, use apc.php para comprobar su configuración. Copie el archivo desde el paquete apc a una carpeta web y apunte el navegador a ella. Verás lo que realmente se asigna y cómo se utiliza. El los gráficos deben permanecer estables después de horas, si están cambiando completamente en cada actualización, entonces significa que su configuración es incorrecta(APC está limpiando todo). Asigne un 20% más de ram de lo que APC realmente usa como margen de seguridad, y compruébelo regularmente.

El valor predeterminado de permitir solo 32MB es ridículamente bajo. PHP fue diseñado cuando los servidores eran 64MB y la mayoría de los scripts usaban un archivo php por página. Hoy en día soluciones como Magento requieren más de 10k archivos (~60Mb en APC). Usted debe permitir suficiente memoria para que la mayoría de los archivos php siempre se almacenen en caché. No es un desperdicio, es más eficiente mantener el opcode en ram en lugar de tener el php raw correspondiente en la caché de archivos. Hoy en día podemos encontrar servidores dedicados con 24 Gb de memoria por tan solo 8 80/mes, así que no dude en permitir varios GB a APC. Puse 2GB de 24GB en un servidor que aloja 5Magento tiendas y ~40 sitio web de wordpress, APC utiliza 1.2 GB. Cuenta 64MB para la instalación de Magento, 40MB para un Wordpress con algunos plugin.

También, si tiene sitios web de desarrollo en el mismo servidor. Excluirlos de la caché.

Solución para mí:

• apc.ttl = 0
• apc.shm_size = lo que quieras

Editar inicio

¡Atención!

@bokan me indicó que debería agregar una advertencia aquí.

Si tiene un ttl de 0, esto significa que todos los elementos almacenados en caché se pueden purgar inmediatamente. por lo tanto, si tiene un tamaño de caché pequeño como 2mb y un ttl de 0, esto haría que el apc fuera inútil, porque los datos en la caché siempre se sobrescriben.

Reducir los medios ttl solo que la caché no puede llenarse, solo con elementos que no se pueden reemplazar.

Así que tienes que elegir un buen equilibrio entre ttl y tamaño de caché.

En mi caso tenía un tamaño de caché de 1 gb, por lo que era más que suficiente para mí.

Editar end

Tuvo el mismo problema en centos 5 con php 5.2.17 y notó que si el el tamaño de la caché es pequeño y el parámetro ttl es "alto" (como 7200) mientras tener una gran cantidad de archivos php para almacenar en caché, entonces la caché se llena bastante rápida y apc no encuentra nada que pueda eliminar porque todos los archivos en el caché todavía cabía en el ttl.

Aumentar el tamaño de la memoria es solo una solución de parte, todavía se ejecuta en este error si la caché se llena y todos los archivos están dentro del ttl.

Así que mi solución fue establecer el ttl a 0, por lo que apc llena la caché un siempre existe la posibilidad de que apc limpie algo de memoria para nuevos datos.

Esperanza que ayuda

Editar: véase también: http://pecl.php.net/bugs/bug.php?id=16966

Descargar http://pecl.php.net/get/APC extrae y ejecuta el apc.php, ahí tienes un buen diagrama cómo se ve tu uso de caché

Ejecutando el apc.el script php es clave para entender cuál es tu problema, IMO. Esto nos ayudó a dimensionar nuestra caché correctamente y por el momento, parece haber resuelto el problema.

Para los novatos como yo, estos recursos ayudaron:

Encontrar el apc.archivo ini para realizar los cambios recomendados por c33s anteriormente, y establecer las cantidades recomendadas: http://www.untwistedvortex.com/optimizing-tuning-apc-alternate-php-cache /

Entendiendo lo que apc.ttl es: http://www.php.net/manual/en/apc.configuration.php#ini.apc.ttl

Entendiendo lo que apc.shm_size ser: http://www.php.net/manual/en/apc.configuration.php#ini.apc.shm-size

Como Bokan ha mencionado, puede subir la memoria si está disponible, y tiene razón en lo contraproducente que es establecer TTL a 0.

NotA: Así es como solucioné este error para mi problema particular. Es un problema genérico que puede ser causado por la asignación de cosas, por lo que solo siga lo siguiente si obtiene el error y cree que es causado por archivos PHP duplicados que se cargan en APC.

El problema que estaba teniendo fue cuando publiqué una nueva versión de mi aplicación PHP. Ie reemplazó a todos mi .archivos php con otros nuevos APC cargaría ambas versiones en caché.

Debido a que no tenía suficiente memoria para dos versiones de los archivos php, APC se quedaría sin memoria.

Existe una opción llamada apc.stat para decirle a APC que verifique si un archivo en particular ha cambiado y si es así, reemplácelo, esto generalmente está bien para el desarrollo porque está haciendo cambios constantemente, sin embargo, en la producción generalmente está desactivado como lo estaba en mi caso - http://www.php.net/manual/en/apc.configuration.php#ini.apc.stat

Girando apc.stat on solucionaría este problema si estás de acuerdo con el golpe de rendimiento.

La solución que se me ocurrió para mi problema es comprobar si la versión del proyecto ha cambiado y si es así vaciar la caché y volver a cargar la página.

define('PROJECT_VERSION', '0.28'); 

if(apc_exists('MY_APP_VERSION') ){

    if(apc_fetch('MY_APP_VERSION') != PROJECT_VERSION){
        apc_clear_cache();
        apc_store ('MY_APP_VERSION', PROJECT_VERSION);
        header('Location: ' . 'http'.(empty($_SERVER['HTTPS'])?'':'s').'://'.$_SERVER['SERVER_NAME'].$_SERVER['REQUEST_URI']);
        exit;  
    }

}else{
    apc_store ('MY_APP_VERSION', PROJECT_VERSION);
}

Mirando los internets puede haber varias causas. En mi caso dejando todo por defecto excepto...

apc.shm_size = 64M

...despejó las innumerables advertencias que estaba recibiendo antes.

Recibí el error "No se puede asignar memoria para el grupo" después de mover una instalación de OpenCart a un servidor diferente. También traté de elevar el memory_limit.

El error se detuvo después de cambiar los permisos del archivo en el mensaje de error para tener acceso de escritura por el usuario que se ejecuta como apache (apache, www-data, etc.). En lugar de modificar /etc/group directamente (o chmod-ing los ficheros a 0777), utilicé usermod:

usermod -a -G vhost-user-group apache-user

Entonces tuve que reiniciar apache para que los cambios surtan efecto:

apachectl restart

O

sudo /etc/init.d/httpd restart

O lo que su sistema use para reiniciar apache.

Si el sitio está en alojamiento compartido, tal vez debe cambiar los permisos de archivo con un programa FTP, o ponerse en contacto con el proveedor de alojamiento?

Esto funcionó para nuestros chicos (ejecutando una gran cantidad de sitios de Wordpress en el mismo servidor).

Se ha cambiado la configuración de la memoria en /etc/php.d apc.archivo ini. Se estableció en 64M, por lo que lo duplicamos a 128M.

Apc.shm_size = 128M

Monitoree el Tamaño de sus archivos almacenados en caché (puede usar apc.php desde el paquete pecl de apc) y aumentar apc.shm_size según sus necesidades.

Esto resuelve el problema.

Para resolver este problema, establezca un valor para apc.shm_size como entero Localiza tu apc.archivo ini (En mi sistema apc.ubicación del archivo ini / etc / php5 / conf.d apc.ini) y set: apc.shm_size = 1000

En mi sistema tuve que insertar apc.shm_size = 64M en/usr/local/etc / php.ini (FreeBSD 9.1) luego, cuando miré apc.php (que copié de / usr / local/share/doc/APC / apc.php a/usr/local/www/apache24 / data) descubrí que el tamaño de la caché había aumentado desde el valor predeterminado de 32M a 64M y ya no estaba recibiendo un conteo completo de caché grande

Referencias: http://au1.php.net/manual/en/apc.configuration.php también lea los comentarios de Bokan, fueron muy útiles