De vez en cuando me encuentro 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 tengo problemas para rastrear cualquier información.
Alguien sabe que significa esto? He intentado aumentar memory_limitsin éxito. Tampoco he realizado cambios significativos en la aplicación. Un día no hubo ningún problema, al día siguiente llegué a este error.
Respuestas:
Probablemente esté relacionado con APC.
Para las personas que tienen este problema, especifique su configuración .ini. Específicamente su configuración apc.mmap_file_mask.
Para mmap respaldado por archivos, debe establecerse en algo como:
apc.mmap_file_mask=/tmp/apc.XXXXXXPara mmap directamente desde / dev / zero, use:
apc.mmap_file_mask=/dev/zeroPara mmap con respaldo de memoria compartida compatible con POSIX, use:
apc.mmap_file_mask=/apc.shm.XXXXXXfile_maskno es uno de estos valores? Si tengo uno de estos valores y obtengo el error, ¿debo cambiarlo por uno diferente? ¿Cúal?
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 a las que se accede más no caduquen. Lo mejor es proporcionar suficiente memoria para que APC no necesite vaciar la 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 apc.shm_size.
Si APC se compila 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 localizar más memoria, deberá aumentar el número 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 aún está definida por la misma opción apc.shm_size.
Si no hay suficiente memoria en el servidor, use 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 apc a una carpeta web y señale el navegador. Verá qué se asigna realmente y cómo se usa. Los gráficos deben permanecer estables después de las horas, si cambian completamente en cada actualización, significa que su configuración es incorrecta (APC está descargando todo). Asigne un 20% más de RAM que lo que APC realmente usa como margen de seguridad, y verifíquelo regularmente.
El valor predeterminado de permitir solo 32 MB es ridículamente bajo. PHP fue diseñado 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 siempre estén en caché. No es un desperdicio, es más eficiente mantener el código de operación en RAM en lugar de tener el php sin procesar correspondiente en la 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 tiendas 5Magento y ~ 40 sitios web de WordPress, APC usa 1.2GB. Cuente 64 MB para la instalación de Magento, 40 MB para Wordpress con algunos complementos.
Además, si tiene sitios web de desarrollo en el mismo servidor. Excluirlos del caché.
editar inicio
@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. así que si tiene un tamaño de caché pequeño como 2mb y un ttl de 0, esto haría que la APC no sirviera, 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 se pueden reemplazar.
por lo que debe elegir un buen equilibrio entre ttl y el tamaño de la memoria caché.
en mi caso tenía un tamaño de caché de 1 gb, así que fue 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 caché es pequeño y el parámetro ttl es "alto" (como 7200) mientras que tiene muchos archivos php para almacenar en caché, entonces la caché se llena bastante rápido y apc no encuentra nada que pueda eliminar porque todos los archivos en la memoria caché todavía caben en el ttl.
aumentar el tamaño de la memoria es solo una solución parcial, aún se 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, de modo que apc llena el caché y siempre hay la posibilidad de que apc 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 extract y ejecute apc.php, allí tiene un buen diagrama sobre cómo se ve su uso de caché
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.
Para los novatos como yo, estos recursos ayudaron:
Encontrar el archivo apc.ini para realizar los cambios recomendados por c33s arriba 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
Como Bokan ha mencionado, puede aumentar la memoria si está disponible, y él tiene razón sobre cuán contraproducente es establecer el TTL en 0.
NotA: Así es como solucioné este error para mi problema particular. Es un problema genérico que puede ser causado por muchas cosas, así 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 tenía era cuando lancé una nueva versión de mi aplicación PHP. Es decir, reemplacé todos mis archivos .php por otros nuevos. APC cargaría ambas versiones en 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 normalmente está bien para el desarrollo porque constantemente está haciendo cambios, sin embargo, en la producción, generalmente está desactivado 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á de acuerdo con el impacto en el rendimiento.
La solución que se me ocurrió para mi problema es verificar si la versión del proyecto ha cambiado y, de ser así, vaciar el 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);
}Esto funcionó para nuestros muchachos (ejecutando una gran cantidad de sitios de Wordpress en el mismo servidor).
Se modificó la configuración de memoria en el archivo /etc/php.d/apc.ini. Estaba configurado en 64M, por lo que lo duplicamos a 128M.
apc.shm_size = 128M
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 límite de memoria.
El error se detuvo después de cambiar los permisos del archivo en el mensaje de error para que el usuario tenga acceso de escritura que apache ejecuta como (apache, www-data, etc.). En lugar de modificar / etc / group directamente (o modificar los archivos a 0777), utilicé usermod:
usermod -a -G vhost-user-group apache-userLuego tuve que reiniciar Apache para que el cambio surta efecto:
apachectl restartO
sudo /etc/init.d/httpd restartO lo que sea que use su sistema para reiniciar apache.
Si el sitio está en un alojamiento compartido, ¿tal vez deba cambiar los permisos del archivo con un programa FTP o ponerse en contacto con el proveedor de alojamiento?
en mi sistema tuve que insertar apc.shm_size = 64M en /usr/local/etc/php.ini (FreeBSD 9.1) y luego cuando miré a 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 memoria caché había aumentado del valor predeterminado de 32M a 64M y ya no obtenía un conteo completo de memoria caché grande
referencias: http://au1.php.net/manual/en/apc.configuration.php también leyeron los comentarios de Bokan, fueron muy útiles