Je me suis parfois heurté à la limite d'allocation de mémoire d'un serveur, en particulier avec une application saturée comme Wordpress, mais je n'ai jamais rencontré "Impossible d'attribuer de la mémoire pour un pool" et j'ai du mal à retrouver les informations.
Est-ce que quelqu'un sait ce que cela signifie? J'ai essayé d'augmenter le memory_limit
sans succès. Je n'ai également apporté aucun changement significatif à la demande. Un jour, il n'y avait pas de problème, le lendemain, j'ai frappé cette erreur.
Pour les personnes ayant ce problème, veuillez spécifier vos paramètres .ini. Spécifiquement votre paramètre apc.mmap_file_mask.
Pour mmap sauvegardé sur fichier, il devrait être défini sur quelque chose comme:
apc.mmap_file_mask=/tmp/apc.XXXXXX
Pour mmap directement à partir de/dev/zero, utilisez:
apc.mmap_file_mask=/dev/zero
Pour les mmap sauvegardées en mémoire partagée compatibles POSIX, utilisez:
apc.mmap_file_mask=/apc.shm.XXXXXX
L'utilisation d'un TTL de 0 signifie qu'APC videra tout le cache lorsqu'il manquera de mémoire. L'erreur n'apparaît plus, mais APC est beaucoup moins efficace. C'est une décision sans risque, sans problème, "je ne veux pas faire mon travail". APC n'est pas conçu pour être utilisé de cette façon. Vous devez choisir un TTL suffisamment élevé pour que les pages les plus consultées n'expirent pas. Le mieux est de laisser suffisamment de mémoire pour que APC n'ait pas besoin de vider le cache.
Il suffit de lire le manuel pour comprendre comment ttl est utilisé: http://www.php.net/manual/fr/apc.configuration.php#ini.apc.ttl
La solution consiste à augmenter la mémoire allouée à APC . Pour ce faire, augmentez apc.shm_size.
Si APC est compilé pour utiliser la mémoire de segment partagée, vous serez limité par votre système d'exploitation. Tapez cette commande pour voir la limite de votre système pour chaque segment:
sysctl -a | grep -E "shmall|shmmax"
Pour allouer plus de mémoire, vous devez augmenter le nombre de segments avec le paramètre apc.shm_segments.
Si APC utilise mmap memory, vous n’avez aucune limite. La quantité de mémoire est toujours définie par la même option apc.shm_size.
S'il n'y a pas assez de mémoire sur le serveur, utilisez l'option des filtres pour empêcher la mise en cache des fichiers php moins fréquemment utilisés.
Mais n'utilisez jamais un TTL de 0.
Comme c33s l'a dit, utilisez apc.php pour vérifier votre configuration. Copiez le fichier du paquet apc dans un dossier Web et pointez le navigateur vers celui-ci. Vous verrez ce qui est réellement alloué et comment il est utilisé. Les graphiques doivent rester stables après les heures de travail. S'ils changent complètement à chaque actualisation, cela signifie que votre configuration est incorrecte (APC purge tout). Allouez 20% de RAM supplémentaire par rapport à ce que APC utilise réellement comme marge de sécurité et vérifiez-le régulièrement.
Le défaut de n'autoriser que 32 Mo est ridiculement bas. PHP a été conçu lorsque les serveurs faisaient 64 Mo et que la plupart des scripts utilisaient un fichier php par page. De nos jours, des solutions telles que Magento nécessitent plus de 10 000 fichiers (~ 60 Mo dans APC). Vous devez laisser assez de mémoire pour que la plupart des fichiers php soient toujours mis en cache. Ce n'est pas un gaspillage, il est plus efficace de conserver l'opcode dans le ram plutôt que d'avoir le php brut correspondant dans le cache de fichiers . De nos jours, nous pouvons trouver des serveurs dédiés avec 24 Go de mémoire pour aussi peu que 80 $/mois, alors n'hésitez pas pour permettre plusieurs Go à APC. Je mets 2 Go sur 24 Go sur un serveur hébergeant des magasins 5Magento et un site Web ~ 40 wordpress, APC utilise 1,2 Go. Comptez 64 Mo pour l’installation de Magento, 40 Mo pour un Wordpress avec quelques plugins.
Aussi, si vous avez des sites de développement sur le même serveur. Excluez-les du cache.
edit start
@bokan m'a indiqué que je devrais ajouter un avertissement ici.
si vous avez un ttl de 0, cela signifie que chaque élément mis en cache peut être purgé immédiatement. Donc, si vous avez une petite taille de cache telle que 2 Mo et un ttl de 0, cela rendrait l'APC inutile, car les données dans le cache sont toujours écrasées.
abaisser le ttl signifie seulement que le cache ne peut pas devenir plein, uniquement avec des éléments qui ne peuvent pas être remplacés.
vous devez donc choisir un bon équilibre entre ttl et la taille du cache.
dans mon cas, j'avais une taille de cache de 1 Go, ce qui était donc largement suffisant pour moi.
modifier fin
avait le même problème sur centos 5 avec php 5.2.17 et a remarqué que si la taille du cache .__ est petite et que le paramètre ttl est "élevé" (comme 7200) alors que ayant beaucoup de fichiers php à mettre en cache, alors le cache se remplit assez rapidement .__ et apc ne trouve rien qu’il puisse supprimer car tous les fichiers de le cache tient toujours dans le ttl.
l'augmentation de la taille de la mémoire n'est qu'une solution partielle, vous devez toujours exécuter cette erreur si le cache est plein et que tous les fichiers se trouvent dans le fichier ttl.
ma solution a donc été de régler le ttl sur 0, de sorte que apc remplisse le cache et il est toujours possible pour apc de vider la mémoire pour de nouveaux.
j'espère que cela pourra aider
edit: voir aussi: http://pecl.php.net/bugs/bug.php?id=16966
download http://pecl.php.net/get/APC extract et lancez le fichier apc.php, vous avez ici un diagramme de Nice montrant l’utilisation de votre cache
L'exécution du script apc.php est essentielle pour comprendre votre problème, OMI. Cela nous a aidé à dimensionner correctement notre cache et, pour le moment, semble avoir résolu le problème.
Pour les débutants comme moi, ces ressources ont aidé:
Trouver le fichier apc.ini pour effectuer les modifications recommandées par c33s ci-dessus et définir les montants recommandés: http://www.untwistedvortex.com/optimizing-tuning-apc-alternate-php-cache/
Comprendre ce qu'est apc.ttl: http://www.php.net/manual/fr/apc.configuration.php#ini.apc.ttl
Comprendre ce qu'est apc.shm_size: http://www.php.net/manual/fr/apc.configuration.php#ini.apc.shm-size
Comme Bokan l’a mentionné, vous pouvez augmenter la mémoire, le cas échéant, et il a raison de dire que le réglage contre-productif de TTL à 0 est correct.
NotE: Voici comment j'ai corrigé cette erreur pour mon problème particulier. C’est un problème générique qui peut être causé par une foule de choses. Ne suivez donc la procédure ci-dessous que si vous obtenez l’erreur et pensez que cela est dû à des fichiers en double PHP chargés dans APC.
Le problème que je rencontrais était lorsque j'ai publié une nouvelle version de mon application PHP. C'est-à-dire que tous mes fichiers .php ont été remplacés par de nouveaux. APC chargerait les deux versions en cache.
Parce que je n'avais pas assez de mémoire pour deux versions des fichiers php, APC serait à court de mémoire.
Il existe une option appelée apc.stat qui permet à APC de vérifier si un fichier particulier a été modifié. Si c'est le cas, remplacez-le. Cela convient généralement au développement, car vous apportez constamment des modifications, mais la production est généralement désactivée. case - http://www.php.net/manual/fr/apc.configuration.php#ini.apc.stat
Activer apc.stat résoudrait ce problème si les performances étaient acceptables.
La solution que j'ai trouvée pour mon problème est de vérifier si la version du projet a changé et si c'est le cas, vider le cache et recharger la page.
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);
}
Cela a fonctionné pour nos gars (exécuter une multitude de sites Wordpress sur le même serveur).
Modification des paramètres de mémoire dans le fichier /etc/php.d/apc.ini. Il était réglé à 64M, nous l'avons donc doublé à 128M.
apc.shm_size = 128M
sur mon système, je devais insérer apc.shm_size = 64M dans /usr/local/etc/php.iniFreeBSD 9.1) puis, lorsque j’ai regardé apc.php (lequel copié de /usr/local/share/doc/APC/apc.php vers /usr/local/www/Apache24/data)i a constaté que la taille du cache était passée de la taille par défaut de 32 Mo à 64 Mo et que je n'étais plus obtenir un grand nombre de cache
références: http://au1.php.net/manual/fr/apc.configuration.php Lisez également les commentaires de Bokan, ils ont été très utiles.
Pour résoudre ce problème, définissez la valeur d'apc.shm_size sous la forme d'un entier Localisez votre fichier apc.ini (dans l'emplacement système du fichier apc.ini /etc/php5/conf.d/apc.ini) et définissez:.apc.shm_size = 1000
En regardant les internets, il peut y avoir diverses causes . Dans mon cas, tout est laissé en défaut sauf ...
apc.shm_size = 64M
... effacé les innombrables avertissements que je recevais plus tôt.
J'ai reçu l'erreur "Impossible d'allouer de la mémoire au pool" après avoir déplacé une installation OpenCart sur un autre serveur. J'ai aussi essayé d'augmenter le memory_limit.
L'erreur s'est arrêtée après que j'ai modifié les autorisations du fichier dans le message d'erreur afin que l'utilisateur sous lequel Apache s'exécute ait accès en écriture (Apache, www-data, etc.). Au lieu de modifier directement/etc/group (ou de modifier les fichiers en 0777), j'ai utilisé usermod:
usermod -a -G vhost-user-group Apache-user
Ensuite, j'ai dû redémarrer Apache pour que la modification soit prise en compte:
apachectl restart
Ou
Sudo /etc/init.d/httpd restart
Ou ce que votre système utilise pour redémarrer Apache.
Si le site est sur un hébergement partagé, vous devez peut-être modifier les autorisations de fichiers avec un programme FTP ou contacter le fournisseur d'hébergement?
Surveillez la taille de vos fichiers en cache (vous pouvez utiliser apc.php à partir du paquet apc pecl) et augmentez Apc.shm_size selon vos besoins.
Cela résout le problème.