php - should - xampp apc
¿Qué está causando "No se puede asignar memoria para el grupo" en PHP? (12)
De vez en cuando me encontré con el límite de asignación de memoria de un servidor, particularmente con una aplicación inflada como Wordpress, pero nunca encontré "No se puede asignar memoria para el grupo" y tuve problemas para rastrear cualquier información.
Alguien sabe que significa esto? Intenté aumentar el memory_limit sin éxito. Tampoco hice ningún cambio significativo en la aplicación. Un día no hubo ningún problema, al día siguiente llegué a este error.
solución para mí:
- apc.ttl = 0
- apc.shm_size = lo que quieras
editar inicio
¡advertencia!
@bokan me indicó que debería agregar una advertencia aquí.
si tiene un ttl de 0, esto significa que cada elemento en caché se puede purgar inmediatamente. así que si tiene un tamaño de caché pequeño como 2mb y un ttl de 0, esto haría que la APC sea inútil, porque los datos en la caché siempre se sobrescriben.
bajar el ttl significa solo que el caché no puede llenarse, solo con elementos que no pueden ser reemplazados.
por lo que debe elegir un buen equilibrio entre ttl y el tamaño de la 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 fin
tuvo el mismo problema en centos 5 con php 5.2.17 y notó que si el tamaño de la memoria caché es pequeño y el parámetro ttl es "alto" (como 7200) mientras tiene una gran cantidad de archivos php para caché, entonces la memoria caché se llena bastante rápido y la APC no encuentra nada que pueda eliminar porque todos los archivos en la memoria caché aún caben en el ttl.
aumentar el tamaño de la memoria es solo una solución parcial, aún ejecuta este error si la memoria caché se llena y todos los archivos están dentro del ttl.
así que mi solución fue establecer el ttl en 0, así que apc llena el caché y siempre existe la posibilidad de que la AP borre algo de memoria para nuevos datos.
Espero que ayude
editar: ver también: http://pecl.php.net/bugs/bug.php?id=16966
descargue http://pecl.php.net/get/APC extracto y ejecute el apc.php, allí tiene un bonito diagrama de cómo se ve el uso de su caché
Como ha mencionado Bokan, puede actualizar la memoria, si está disponible, y tiene razón sobre la contraproducente configuración de TTL a 0.
NotA: así es como arreglé este error para mi problema particular. Es un problema genérico que puede ser causado por un montón de cosas, así que solo sigue el siguiente si obtienes el error y piensas que es causado por archivos PHP duplicados que se cargan en APC.
El problema que estaba teniendo fue cuando lancé una nueva versión de mi aplicación PHP. Es decir, reemplazó todos mis archivos .php por otros nuevos. APC cargaría ambas versiones en la memoria caché.
Como no tenía suficiente memoria para dos versiones de los archivos php, APC se quedaría sin memoria.
Hay 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 está bien para el desarrollo porque usted está constantemente haciendo cambios; sin embargo, en la producción generalmente está apagado como estaba en mi case - http://www.php.net/manual/en/apc.configuration.php#ini.apc.stat
Activar apc.stat solucionaría este problema si estás de acuerdo con el rendimiento alcanzado.
La solución que surgió para mi problema es verificar 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);
}
Controle el tamaño de sus archivos en caché (puede usar apc.php desde el paquete apc pecl) y aumente el apc.shm_size según sus necesidades.
Esto resuelve el problema.
Ejecutar el script apc.php es clave para entender cuál es su problema, IMO. Esto nos ayudó a dimensionar nuestro caché correctamente y, por el momento, parece haber resuelto el problema.
En cuanto a los internets, puede haber varias causas. En mi caso, dejar todo predeterminado excepto ...
apc.shm_size = 64M
... borró las innumerables advertencias que recibía antes.
Esto funcionó para nuestros muchachos (ejecutando una gran cantidad de sitios de WordPress en el mismo servidor).
Cambió la configuración de memoria en el archivo /etc/php.d/apc.ini. Se estableció en 64M, por lo que lo duplicamos a 128M.
apc.shm_size = 128M
Para los novatos como yo, estos recursos ayudaron:
Encontrar el archivo apc.ini para realizar los cambios recomendados por c33s anteriores y establecer las cantidades recomendadas: http://www.untwistedvortex.com/optimizing-tuning-apc-alternate-php-cache/
Comprender qué es apc.ttl: http://www.php.net/manual/en/apc.configuration.php#ini.apc.ttl
Comprender qué es apc.shm_size: http://www.php.net/manual/en/apc.configuration.php#ini.apc.shm-size
Para resolver este problema, establezca el valor de apc.shm_size como entero. Ubique su archivo apc.ini (en mi ubicación del archivo apc.ini del sistema /etc/php5/conf.d/apc.ini) y configúrelo : apc.shm_size = 1000
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 intenté elevar el memory_limit.
El error se detuvo después de que cambié los permisos del archivo en el mensaje de error para tener acceso de escritura por el usuario que apache ejecuta como (apache, www-data, etc.). En lugar de modificar / etc / group directamente (o cambiar los archivos a 0777), utilicé usermod:
usermod -a -G vhost-user-group apache-user
Luego tuve que reiniciar Apache para que el cambio surta efecto:
apachectl restart
O
sudo /etc/init.d/httpd restart
O lo que sea que use su sistema para reiniciar apache.
Si el sitio está en alojamiento compartido, ¿quizás deba cambiar los permisos de archivo con un programa FTP o contactar al proveedor de hosting?
Usar un TTL de 0 significa que APC vaciará todo el 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 proporcionar suficiente memoria para que APC no necesite vaciar el caché.
Simplemente lea el manual para comprender 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 está compilado para usar la Memoria de segmento compartido, su sistema operativo lo limitará. Escriba este comando para ver el límite de su sistema para cada segmento:
sysctl -a | grep -E "shmall|shmmax"
Para asignar más memoria, deberá aumentar la cantidad de segmentos con el parámetro apc.shm_segments.
Si APC está utilizando la memoria mmap, entonces no tiene límite. La cantidad de memoria todavía está definida por la misma opción apc.shm_size.
Si no hay suficiente memoria en el servidor, utilice la opción de 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 verificar su configuración. Copie el archivo del paquete de la APC a una carpeta web y apúntelo al navegador. Verá lo que realmente se asigna y cómo se usa. Los gráficos deben permanecer estables después de las 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 que lo que APC realmente usa como margen de seguridad, y revíselo regularmente.
El valor predeterminado de permitir solo 32 MB es ridículamente bajo. PHP se diseñó cuando los servidores tenían 64 MB y la mayoría de los scripts usaban un archivo php por página. Hoy en día, las soluciones como Magento requieren más de 10k archivos (~ 60Mb en APC). Debe permitir suficiente memoria para que la mayoría de los archivos php estén siempre en la memoria caché. No es un desperdicio, es más eficiente mantener opcode en ram en lugar de tener el correspondiente php sin procesar en el caché de archivos. Hoy en día podemos encontrar servidores dedicados con 24 Gb de memoria por tan solo $ 80 / mes, así que no dude en permitir varios GB a APC. Puse 2GB de 24GB en un servidor que aloja 5 tiendas de Magento y ~ 40 sitios web de wordpress, APC usa 1.2GB. Cuente 64MB para la instalación de Magento, 40MB para Wordpress con algunos complementos.
Además, si tiene sitios web de desarrollo en el mismo servidor. Excluirlos de la memoria caché.
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) encontré que el tamaño de la memoria caché había aumentado del valor predeterminado de 32M a 64M y ya no obtenía un conteo completo de caché grande
referencias: http://au1.php.net/manual/en/apc.configuration.php también leyeron los comentarios de Bokan, fueron muy útiles
Probablemente esté relacionado con APC.
Para las personas que tienen este problema, por favor especifique su configuración .ini. Específicamente, su configuración de apc.mmap_file_mask.
Para mmap respaldado por archivos, debe establecerse de la siguiente manera:
apc.mmap_file_mask=/tmp/apc.XXXXXX
Para mapear directamente desde / dev / zero, use:
apc.mmap_file_mask=/dev/zero
Para mmap con respaldo de memoria compartida compatible con POSIX, use:
apc.mmap_file_mask=/apc.shm.XXXXXX